Internet Engineering Task Force (IETF) D. Walton
Request for Comments: 7911 Cumulus Networks
Category: Standards Track A. Retana
ISSN: 2070-1721 E. Chen
Cisco Systems, Inc.
J. Scudder
Juniper Networks
July 2016
Internet Engineering Task Force (IETF) D. Walton
Request for Comments: 7911 Cumulus Networks
Category: Standards Track A. Retana
ISSN: 2070-1721 E. Chen
Cisco Systems, Inc.
J. Scudder
Juniper Networks
July 2016
Advertisement of Multiple Paths in BGP
BGP中的多路径广告
Abstract
摘要
This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a Path Identifier in addition to the address prefix.
本文档定义了一个BGP扩展，该扩展允许为同一地址前缀播发多个路径，而无需隐式替换任何以前的路径。扩展的本质是，除了地址前缀之外，每个路径都由路径标识符标识。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7911.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7911.
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. Specification of Requirements . . . . . . . . . . . . . . 2
2. How to Identify a Path . . . . . . . . . . . . . . . . . . . 3
3. Extended NLRI Encodings . . . . . . . . . . . . . . . . . . . 3
4. ADD-PATH Capability . . . . . . . . . . . . . . . . . . . . . 4
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements . . . . . . . . . . . . . . 2
2. How to Identify a Path . . . . . . . . . . . . . . . . . . . 3
3. Extended NLRI Encodings . . . . . . . . . . . . . . . . . . . 3
4. ADD-PATH Capability . . . . . . . . . . . . . . . . . . . . . 4
5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
The BGP specification [RFC4271] defines an Update-Send Process to advertise the routes chosen by the Decision Process to other BGP speakers. No provisions are made to allow the advertisement of multiple paths for the same address prefix or Network Layer Reachability Information (NLRI). In fact, a route with the same NLRI as a previously advertised route implicitly replaces the previous advertisement.
BGP规范[RFC4271]定义了一个更新发送过程，用于向其他BGP演讲者公布决策过程选择的路由。没有规定允许为同一地址前缀或网络层可达性信息（NLRI）发布多条路径。事实上，与先前公布的路由具有相同NLRI的路由隐式替换先前公布的路由。
This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a Path Identifier in addition to the address prefix.
本文档定义了一个BGP扩展，该扩展允许为同一地址前缀播发多个路径，而无需隐式替换任何以前的路径。扩展的本质是，除了地址前缀之外，每个路径都由路径标识符标识。
The availability of the additional paths can help reduce or eliminate persistent route oscillations [RFC3345]. It can also help with optimal routing and routing convergence in a network by providing potential alternate or backup paths, respectively.
附加路径的可用性有助于减少或消除持续的路由振荡[RFC3345]。它还可以通过分别提供潜在的备用路径或备份路径，帮助实现网络中的最佳路由和路由收敛。
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]中所述进行解释。
As defined in [RFC4271], a path refers to the information reported in the Path Attribute field of an UPDATE message. As the procedures specified in [RFC4271] allow only the advertisement of one path for a particular address prefix, a path for an address prefix from a BGP peer can be keyed on the address prefix.
如[RFC4271]中所定义，路径指更新消息的路径属性字段中报告的信息。由于[RFC4271]中规定的程序仅允许公布特定地址前缀的一条路径，因此可以在地址前缀上键入来自BGP对等方的地址前缀路径。
In order for a BGP speaker to advertise multiple paths for the same address prefix, a new identifier (termed "Path Identifier" hereafter) needs to be introduced so that a particular path for an address prefix can be identified by the combination of the address prefix and the Path Identifier.
为了使BGP说话者为同一地址前缀播发多条路径，需要引入新的标识符（下文称为“路径标识符”），以便通过地址前缀和路径标识符的组合来识别地址前缀的特定路径。
The assignment of the Path Identifier for a path by a BGP speaker is purely a local matter. However, the Path Identifier MUST be assigned in such a way that the BGP speaker is able to use the (Prefix, Path Identifier) to uniquely identify a path advertised to a neighbor. A BGP speaker that re-advertises a route MUST generate its own Path Identifier to be associated with the re-advertised route. A BGP speaker that receives a route should not assume that the identifier carries any particular semantics.
BGP说话人为路径分配路径标识符纯粹是本地事务。然而，必须以这样的方式分配路径标识符，即BGP说话人能够使用（前缀，路径标识符）来唯一地标识通告给邻居的路径。重新播发路由的BGP扬声器必须生成自己的路径标识符，以便与重新播发的路由相关联。接收路由的BGP说话者不应假定标识符具有任何特定语义。
In order to carry the Path Identifier in an UPDATE message, the NLRI encoding MUST be extended by prepending the Path Identifier field, which is of four octets.
为了在更新消息中携带路径标识符，NLRI编码必须通过在路径标识符字段前加前缀来扩展，该字段由四个八位字节组成。
For example, the NLRI encoding specified in [RFC4271] is extended as the following:
例如，[RFC4271]中指定的NLRI编码扩展如下：
+--------------------------------+
| Path Identifier (4 octets) |
+--------------------------------+
| Length (1 octet) |
+--------------------------------+
| Prefix (variable) |
+--------------------------------+
+--------------------------------+
| Path Identifier (4 octets) |
+--------------------------------+
| Length (1 octet) |
+--------------------------------+
| Prefix (variable) |
+--------------------------------+
The usage of the extended NLRI encodings is specified in Section 5.
第5节规定了扩展NLRI编码的使用。
The ADD-PATH Capability is a BGP capability [RFC5492], with Capability Code 69. The Capability Length field of this capability is variable. The Capability Value field consists of one or more of the following tuples:
添加路径功能是BGP功能[RFC5492]，功能代码为69。此功能的“功能长度”字段是可变的。“能力值”字段由以下一个或多个元组组成：
+------------------------------------------------+
| Address Family Identifier (2 octets) |
+------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+------------------------------------------------+
| Send/Receive (1 octet) |
+------------------------------------------------+
+------------------------------------------------+
| Address Family Identifier (2 octets) |
+------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+------------------------------------------------+
| Send/Receive (1 octet) |
+------------------------------------------------+
The meaning and use of the fields are as follows:
字段的含义和用途如下：
Address Family Identifier (AFI):
地址族标识符（AFI）：
This field is the same as the one used in [RFC4760].
此字段与[RFC4760]中使用的字段相同。
Subsequent Address Family Identifier (SAFI):
后续地址系列标识符（SAFI）：
This field is the same as the one used in [RFC4760].
此字段与[RFC4760]中使用的字段相同。
Send/Receive:
发送/接收：
This field indicates whether the sender is (a) able to receive multiple paths from its peer (value 1), (b) able to send multiple paths to its peer (value 2), or (c) both (value 3) for the <AFI, SAFI>.
此字段指示发送方是否（a）能够从其对等方接收多条路径（值1），（b）能够向其对等方发送多条路径（值2），或者（c）对于<AFI，SAFI>，两者都是（值3）。
If any other value is received, then the capability SHOULD be treated as not understood and ignored [RFC5492].
如果收到任何其他值，则应将该能力视为未理解和忽略[RFC5492]。
A BGP speaker that wishes to indicate support for multiple AFI/SAFIs MUST do so by including the information in a single instance of the ADD-PATH Capability.
希望表示支持多个AFI/SAFI的BGP演讲者必须将信息包含在添加路径功能的单个实例中。
The Path Identifier specified in Section 3 can be used to advertise multiple paths for the same address prefix without subsequent advertisements replacing the previous ones. Apart from the fact that this is now possible, the route advertisement rules of [RFC4271] are not changed. In particular, a new advertisement for a given address prefix and a given Path Identifier replaces a previous advertisement
第3节中指定的路径标识符可用于为同一地址前缀播发多个路径，而无需后续播发替换先前的播发。除了现在可以这样做之外，[RFC4271]的路线广告规则没有改变。具体地，针对给定地址前缀和给定路径标识符的新公告替换先前的公告
for the same address prefix and Path Identifier. If a BGP speaker receives a message to withdraw a prefix with a Path Identifier not seen before, it SHOULD silently ignore it.
用于相同的地址前缀和路径标识符。如果BGP说话者收到一条消息，要撤回一个路径标识符为前所未见的前缀，它应该默默地忽略它。
For a BGP speaker to be able to send multiple paths to its peer, that BGP speaker MUST advertise the ADD-PATH Capability with the Send/ Receive field set to either 2 or 3, and MUST receive from its peer the ADD-PATH Capability with the Send/Receive field set to either 1 or 3, for the corresponding <AFI, SAFI>.
为了使BGP演讲者能够向其对等方发送多条路径，该BGP演讲者必须公布添加路径功能，发送/接收字段设置为2或3，并且必须从其对等方接收添加路径功能，发送/接收字段设置为1或3，用于相应的<AFI，SAFI>。
A BGP speaker MUST follow the procedures defined in [RFC4271] when generating an UPDATE message for a particular <AFI, SAFI> to a peer unless the BGP speaker advertises the ADD-PATH Capability to the peer indicating its ability to send multiple paths for the <AFI, SAFI>, and also receives the ADD-PATH Capability from the peer indicating its ability to receive multiple paths for the <AFI, SAFI>, in which case the speaker MUST generate a route update for the <AFI, SAFI> based on the combination of the address prefix and the Path Identifier, and use the extended NLRI encodings specified in this document. The peer SHALL act accordingly in processing an UPDATE message related to a particular <AFI, SAFI>.
BGP演讲者在向对等方生成特定<AFI，SAFI>的更新消息时，必须遵循[RFC4271]中定义的程序，除非BGP演讲者向对等方宣传添加路径功能，表明其能够为<AFI，SAFI>发送多条路径，并且还从对等方接收添加路径能力，指示其能够接收<AFI，SAFI>的多条路径，在这种情况下，演讲者必须基于地址前缀和路径标识符的组合为<AFI，SAFI>生成路由更新，并使用本文档中指定的扩展NLRI编码。对等方应相应地处理与特定<AFI，SAFI>相关的更新消息。
A BGP speaker SHOULD include the best route [RFC4271] when more than one path is advertised to a neighbor, unless it is a path received from that neighbor.
当向邻居播发多条路径时，BGP扬声器应包括最佳路由[RFC4271]，除非它是从该邻居接收到的路径。
As the Path Identifiers are locally assigned, and may or may not be persistent across a control plane restart of a BGP speaker, an implementation SHOULD take special care so that the underlying forwarding plane of a "Receiving Speaker" as described in [RFC4724] is not affected during the graceful restart of a BGP session.
由于路径标识符是本地分配的，并且可能在BGP扬声器的控制平面重启期间是持久的，也可能不是持久的，因此实现应特别小心，以便在BGP会话的正常重启期间，[RFC4724]中描述的“接收扬声器”的底层转发平面不受影响。
The extension proposed in this document provides a mechanism for a BGP speaker to advertise multiple paths over a BGP session. Care needs to be taken in its deployment to ensure consistent routing and forwarding in a network [ADDPATH].
本文中提出的扩展为BGP演讲者提供了一种在BGP会话上公布多条路径的机制。在部署时需要小心，以确保网络[ADDPATH]中的路由和转发一致。
The only explicit indication that the encoding described in Section 3 is in use in a particular BGP session is the exchange of Capabilities described in Section 4. If the exchange is successful [RFC5492], then the BGP speakers will be able to process all BGP UPDATES properly, as described in Section 5. However, if, for example, a packet analyzer is used on the wire to examine an active BGP session, it may not be able to properly decode the BGP UPDATES because it lacks prior knowledge of the exchanged Capabilities.
第3节中描述的编码在特定BGP会话中使用的唯一明确指示是第4节中描述的功能交换。如果交换成功[RFC5492]，则BGP扬声器将能够正确处理所有BGP更新，如第5节所述。然而，例如，如果在线路上使用数据包分析器来检查活动的BGP会话，它可能无法正确解码BGP更新，因为它缺乏交换能力的先验知识。
When deployed as a provider edge router or a peering router that interacts with external neighbors, a BGP speaker usually advertises at most one path to the internal neighbors in a network. In the case where the speaker is configured to advertise multiple paths to the internal neighbors, and additional information is needed for the application, the speaker could use attributes such as the Edge_Discriminator attribute [FAST]. The use of that type of additional information is outside the scope of this document.
当部署为与外部邻居交互的提供商边缘路由器或对等路由器时，BGP扬声器通常最多向网络中的内部邻居广播一条路径。在扬声器被配置为向内部邻居播发多条路径，并且应用程序需要附加信息的情况下，扬声器可以使用诸如边缘鉴别器属性[FAST]之类的属性。此类附加信息的使用不在本文件范围内。
IANA has assigned the value 69 for the ADD-PATH Capability described in this document. This registration is in the "Capability Codes" registry.
IANA已为本文档中描述的添加路径功能分配了值69。此注册在“能力代码”注册表中。
This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. As a result, multiple paths for a large number of prefixes may be received by a BGP speaker, potentially depleting memory resources or even causing network-wide instability, which can be considered a denial-of-service attack. Note that this is not a new vulnerability, but one that is present in the base BGP specification [RFC4272].
本文档定义了一个BGP扩展，该扩展允许为同一地址前缀播发多个路径，而无需隐式替换任何以前的路径。因此，BGP扬声器可能会接收到大量前缀的多条路径，这可能会耗尽内存资源，甚至导致网络范围的不稳定，这可被视为拒绝服务攻击。请注意，这不是新的漏洞，而是基本BGP规范[RFC4272]中存在的漏洞。
The use of the ADD-PATH Capability is intended to address specific needs related to, for example, eliminating route oscillations that were induced by the MULTI_EXIT_DISC (MED) attribute [STOP-OSC]. While describing the applications for the ADD-PATH Capability is outside the scope of this document, users are encouraged to examine their behavior and potential impact by studying the best practices described in [ADDPATH].
添加路径功能的使用旨在解决与消除多出口盘（MED）属性[STOP-OSC]引起的路由振荡相关的特定需求。虽然描述添加路径功能的应用程序超出了本文档的范围，但鼓励用户通过研究[ADDPATH]中描述的最佳实践来检查其行为和潜在影响。
Security concerns in the base operation of BGP [RFC4271] also apply.
BGP[RFC4271]的基本操作中的安全问题也适用。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 4271，DOI 10.17487/RFC4271，2006年1月<http://www.rfc-editor.org/info/rfc4271>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <http://www.rfc-editor.org/info/rfc4760>.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，DOI 10.17487/RFC4760，2007年1月<http://www.rfc-editor.org/info/rfc4760>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, <http://www.rfc-editor.org/info/rfc5492>.
[RFC5492]Scudder，J.和R.Chandra，“BGP-4的能力广告”，RFC 5492，DOI 10.17487/RFC5492，2009年2月<http://www.rfc-editor.org/info/rfc5492>.
[ADDPATH] Uttaro, J., Francois, P., Patel, K., Haas, J., Simpson, A., and R. Fragassi, "Best Practices for Advertisement of Multiple Paths in IBGP", Work in Progress, draft-ietf-idr-add-paths-guidelines-08, April 2016.
[ADDPATH]Uttaro，J.，Francois，P.，Patel，K.，Haas，J.，Simpson，A.，和R.Fragassi，“IBGP中多路径广告的最佳实践”，正在进行的工作，草稿-ietf-idr-add-Path-guidelines-08，2016年4月。
[FAST] Mohapatra, P., Fernando, R., Filsfils, C., and R. Raszuk, "Fast Connectivity Restoration Using BGP Add-path", Work in Progress, draft-pmohapat-idr-fast-conn-restore-03, January 2013.
[FAST]Mohapatra，P.，Fernando，R.，Filsfils，C.，和R.Raszuk，“使用BGP添加路径进行快速连接恢复”，正在进行的工作，草稿-pmohapat-idr-FAST-conn-restore-032013年1月。
[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, DOI 10.17487/RFC3345, August 2002, <http://www.rfc-editor.org/info/rfc3345>.
[RFC3345]McPherson，D.，Gill，V.，Walton，D.，和A.Retana，“边界网关协议（BGP）持续路由振荡条件”，RFC 3345，DOI 10.17487/RFC3345，2002年8月<http://www.rfc-editor.org/info/rfc3345>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>.
[RFC4272]Murphy，S.，“BGP安全漏洞分析”，RFC 4272，DOI 10.17487/RFC4272，2006年1月<http://www.rfc-editor.org/info/rfc4272>.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, <http://www.rfc-editor.org/info/rfc4724>.
[RFC4724]Sangli，S.，Chen，E.，Fernando，R.，Scudder，J.，和Y.Rekhter，“BGP的优雅重启机制”，RFC 4724，DOI 10.17487/RFC4724，2007年1月<http://www.rfc-editor.org/info/rfc4724>.
[STOP-OSC] Walton, D., Retana, A., Chen, E., and J. Scudder, "BGP Persistent Route Oscillation Solutions", Work in Progress, draft-ietf-idr-route-oscillation-stop-03, April 2016.
[STOP-OSC]Walton，D.，Retana，A.，Chen，E.，和J.Scudder，“BGP持续路由振荡解决方案”，正在进行的工作，草稿-ietf-idr-Route-Oscillation-STOP-032016年4月。
Acknowledgments
致谢
We would like to thank David Cook and Naiming Shen for their contributions to the design and development of the extension.
我们要感谢David Cook和Naiming Shen为扩展的设计和开发所做的贡献。
Many people have made valuable comments and suggestions, including Rex Fernando, Eugene Kim, Danny McPherson, Dave Meyer, Pradosh Mohapatra, Keyur Patel, Robert Raszuk, Eric Rosen, Srihari Sangli, Dan Tappan, Mark Turner, Jeff Haas, Jay Borkenhagen, Mach Chen, Denis Ovsienko, Carlos Pignataro, Meral Shirazipour, and Kathleen Moriarty.
许多人都提出了宝贵的意见和建议，包括雷克斯·费尔南多、尤金·金、丹尼·麦克弗森、戴夫·迈耶、普拉多什·莫哈帕特拉、科乌尔·帕特尔、罗伯特·拉祖克、埃里克·罗森、斯利哈里·桑利、丹·塔潘、马克·特纳、杰夫·哈斯、杰伊·博肯哈根、马赫·陈、丹尼斯·奥文科、卡洛斯·皮格纳塔罗、梅拉尔·西拉齐普尔和凯瑟琳·莫里亚蒂。
Authors' Addresses
作者地址
Daniel Walton Cumulus Networks 185 E. Dana Street Mountain View, CA 94041 United States of America
Daniel Walton Cumulus Networks 185 E.Dana Street Mountain View美国加利福尼亚州94041
Email: dwalton@cumulusnetworks.com
Email: dwalton@cumulusnetworks.com
Alvaro Retana Cisco Systems, Inc. Kit Creek Rd. Research Triangle Park, NC 27709 United States of America
美国北卡罗来纳州三角研究公园Kit Creek路Alvaro Retana思科系统公司，邮编：27709
Email: aretana@cisco.com
Email: aretana@cisco.com
Enke Chen Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 United States of America
Enke Chen Cisco Systems，Inc.170 W.Tasman博士，加利福尼亚州圣何塞，美国95134
Email: enkechen@cisco.com
Email: enkechen@cisco.com
John Scudder Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 United States of America
John Scudder Juniper Networks 1194 N.Mathilda Ave Sunnyvale，加利福尼亚州，美利坚合众国，邮编94089
Email: jgs@juniper.net
Email: jgs@juniper.net