RFC 7911 - Advertisement of Multiple Paths in BGP 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7911
タイトル : RFC 7911 - BGPでの複数のパスのアドバタイズ
翻訳編集 : 自動生成

[要約] RFC 7911は、BGPで複数のパスを広告するための方法を提案している。その目的は、ネットワークの冗長性を向上させ、トラフィックの負荷分散を実現することである。

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.

これはInternet Standards Trackドキュメントです。

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（Internet Engineering Task Force）の製品です。これは、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で入手できます。

著作権表示

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）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

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

1. はじめに

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を持つルートは、以前のアドバタイズを暗黙的に置き換えます。

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]。また、潜在的な代替パスまたはバックアップパスをそれぞれ提供することにより、ネットワークでの最適なルーティングとルーティングの収束に役立ちます。

1.1. Specification of Requirements

1.1. 要件の仕様

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

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

2. How to Identify a Path

2. パスを識別する方法

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]で定義されているように、パスは、UPDATEメッセージのPath Attributeフィールドで報告される情報を指します。 [RFC4271]で指定されている手順では、特定のアドレスプレフィックスの1つのパスのアドバタイズのみが許可されるため、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スピーカーは、識別子が特定のセマンティクスを持っていると想定しないでください。

3. Extended NLRI Encodings

3. 拡張NLRIエンコーディング

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.

UPDATEメッセージでパス識別子を運ぶために、4つのオクテットであるパス識別子フィールドを前に付けることにより、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)              |
                  +--------------------------------+

The usage of the extended NLRI encodings is specified in Section 5.

拡張NLRIエンコーディングの使用法は、セクション5で指定されています。

4. ADD-PATH Capability

4. ADD-PATH機能

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:

ADD-PATH機能は、BGP機能[RFC5492]で、機能コード69を備えています。この機能の機能長フィールドは可変です。「機能値」フィールドは、以下の1つ以上のタプルで構成されています。

                +------------------------------------------------+
                | 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）両方（値3） <AFI、SAFI>。

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スピーカーは、ADD-PATH機能の単一のインスタンスに情報を含めることにより、そのようにする必要があります。

5. Operation

5. 操作

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

セクション3で指定されたパス識別子を使用すると、同じアドレスプレフィックスの複数のパスをアドバタイズできますが、以前のアドバタイズを置き換えるアドバタイズはありません。これが可能になったという事実を除けば、[RFC4271]のルート通知ルールは変更されません。特に、特定のアドレスプレフィックスと特定のパス識別子の新しいアドバタイズは、同じアドレスプレフィックスとパス識別子の以前のアドバタイズを置き換えます。 BGPスピーカーが、以前に見られなかったパス識別子を持つプレフィックスを撤回するメッセージを受信した場合、それを黙って無視する必要があります（SHOULD）。

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に設定してADD-PATH機能をアドバタイズし、ピアからADD-PATH機能を受信する必要があります。送信/受信フィールドは、対応する<AFI、SAFI>の1または3に設定されます。

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スピーカーは、[RFC4271]で定義されている手順に従う必要があります。ただし、ピアに特定の<AFI、SAFI>のUPDATEメッセージを生成する場合は、BGPスピーカーがADD-PATH機能をピアにアドバタイズして、複数のパスを送信する機能を通知しない限り、 <AFI、SAFI>、および<AFI、SAFI>の複数のパスを受信する能力を示すADD-PATH機能をピアから受信します。この場合、スピーカーは<AFI、SAFI>ベースのルート更新を生成する必要がありますアドレスプレフィックスとパス識別子の組み合わせで、このドキュメントで指定されている拡張NLRIエンコーディングを使用します。ピアは、特定の<AFI、SAFI>に関連するUPDATEメッセージの処理に応じて動作する必要があります（SHALL）。

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]を含める必要があります（SHOULD）。

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スピーカーのコントロールプレーンの再起動後も持続する場合としない場合があるため、[RFC4724]で説明されている「受信スピーカー」の基礎となる転送プレーンがBGPセッションの正常な再起動中は影響を受けません。

6. Deployment Considerations

6. 導入に関する考慮事項

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スピーカーは通常、ネットワーク内の内部ネイバーに最大1つのパスをアドバタイズします。スピーカーが内部ネイバーに複数のパスをアドバタイズするように構成されており、アプリケーションに追加情報が必要な場合、スピーカーはEdge_Discriminator属性[FAST]などの属性を使用できます。そのタイプの追加情報の使用は、このドキュメントの範囲外です。

7. IANA Considerations

7. IANAに関する考慮事項

IANA has assigned the value 69 for the ADD-PATH Capability described in this document. This registration is in the "Capability Codes" registry.

IANAは、このドキュメントで説明されているADD-PATH機能に値69を割り当てています。この登録は「機能コード」レジストリにあります。

8. Security Considerations

8. セキュリティに関する考慮事項

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

ADD-PATH機能の使用は、たとえば、MULTI_EXIT_DISC（MED）属性[STOP-OSC]によって引き起こされたルートの振動を排除することに関連する特定のニーズに対処することを目的としています。 ADD-PATH機能のアプリケーションの説明はこのドキュメントの範囲外ですが、ユーザーは[ADDPATH]で説明されているベストプラクティスを研究することにより、その動作と潜在的な影響を調べることをお勧めします。

Security concerns in the base operation of BGP [RFC4271] also apply.

BGP [RFC4271]の基本操作におけるセキュリティの懸念も適用されます。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[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。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 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]ベイツ、T。、チャンドラ、R。、カッツ、D。、およびY.レクター、「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>。

9.2. Informative References

9.2. 参考引用

[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-paths-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 Add-pathを使用した高速接続復元」、作業中、draft-pmohapat-idr-fast-conn-restore- 2013年1月3日。

[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、「Border Gateway Protocol（BGP）Persistent Route Oscillation Condition」、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 Security Vulnerabilities Analysis」、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 Persistent Route Oscillation Solutions」、Work in Progress、draft-ietf-idr-route-oscillation-stop-03 、2016年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.

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、およびCathleen 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、CA 94041アメリカ合衆国

   Email: dwalton@cumulusnetworks.com

Alvaro Retana Cisco Systems, Inc. Kit Creek Rd. Research Triangle Park, NC 27709 United States of America

Alvaro Retana Cisco Systems、Inc. Kit Creek Rd。 Research Triangle Park、NC 27709アメリカ合衆国

   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 Dr. San Jose、CA 95134アメリカ合衆国

   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、CA 94089アメリカ合衆国

   Email: jgs@juniper.net