[要約] RFC 7611は、BGP ACCEPT_OWNコミュニティ属性の仕様を定義しています。この属性は、BGPルータが自身の経路を受け入れるかどうかを制御するために使用されます。目的は、ネットワークオペレータが経路の制御をより柔軟に行えるようにすることです。
Internet Engineering Task Force (IETF) J. Uttaro
Request for Comments: 7611 AT&T
Category: Standards Track P. Mohapatra
ISSN: 2070-1721 Sproute Networks
D. Smith
Cisco Systems
R. Raszuk
Mirantis Inc.
J. Scudder
Juniper Networks
August 2015
BGP ACCEPT_OWN Community Attribute
BGP ACCEPT_OWNコミュニティ属性
Abstract
概要
Under certain conditions, it is desirable for a Border Gateway Protocol (BGP) route reflector to be able to modify the Route Target (RT) list of a Virtual Private Network (VPN) route that the route reflector distributes, enabling the route reflector to control how a route originated within one VPN Routing and Forwarding table (VRF) is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same Provider Edge (PE) router as the VRF(s) that imports the route. However, due to the constraints of BGP, it does not work if the two are on the same PE. This document describes a modification to BGP allowing this technique to work when the VRFs are on the same PE and to be used in a standard manner throughout an autonomous system.
特定の条件下では、ボーダーゲートウェイプロトコル（BGP）ルートリフレクターが、ルートリフレクターが配布する仮想プライベートネットワーク（VPN）ルートのルートターゲット（RT）リストを変更できるようにして、ルートリフレクターが制御できるようにすることが望ましい1つのVPNルーティングおよび転送テーブル（VRF）内で発生したルートが他のVRFにインポートされる方法。ルートをエクスポートするVRFが、ルートをインポートするVRFと同じプロバイダーエッジ（PE）ルーター上にない限り、この手法は効果的に機能します。ただし、BGPの制約により、2つが同じPE上にある場合は機能しません。このドキュメントでは、VRFが同じPE上にある場合にこの手法が機能し、自律システム全体で標準的な方法で使用できるようにする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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc7611.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7611で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. ACCEPT_OWN Community . . . . . . . . . . . . . . . . . . . . 3
2.1. Route Acceptance . . . . . . . . . . . . . . . . . . . . 3
2.2. Propagating ACCEPT_OWN between Address Families . . . . . 4
2.3. Configuration Control . . . . . . . . . . . . . . . . . . 4
3. Decision Process . . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
5. Other Applications . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Local Extranet Application (Non-normative) . . . . . 7
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
In certain scenarios, a BGP speaker may maintain multiple VRFs [RFC4364]. Under certain conditions, it is desirable for a route reflector to be able to modify the RT list of a VPN route that the route reflector distributes, enabling the route reflector to control how a route originated within one VRF is imported into other VRFs. Though it is possible to perform such control directly on the originator, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies.
特定のシナリオでは、BGPスピーカーが複数のVRFを維持する場合があります[RFC4364]。特定の状況下では、ルートリフレクタが配布するVPNルートのRTリストをルートリフレクタが変更できることが望ましいため、ルートリフレクタは、1つのVRF内で発生したルートを他のVRFにインポートする方法を制御できます。そのような制御を発信元で直接実行することは可能ですが、複雑なBGPポリシーを持つ多数の境界ルーターを備えた自律システムでは、操作上面倒な場合があります。
The technique of the route reflector modifying the RT list works effectively as long as the VRF that exports the route is not on the same PE as the VRF(s) that imports the route. However, due to constraints of BGP, it does not work if the two are on the same PE. This is because, per the BGP specification [RFC4271], a BGP speaker rejects received prefix advertisements that were originated by itself. In an autonomous system with route reflectors, the route reflector attaches the ORIGINATOR_ID attribute to the UPDATE messages so that if such prefix advertisements reach the originator, the originator can reject them by simply checking the ORIGINATOR_ID attribute. The BGP specification also mandates that a route should not be accepted from a peer when the NEXT_HOP attribute matches the receiver's own IP address.
ルートリストを変更するルートリフレクタの手法は、ルートをエクスポートするVRFが、ルートをインポートするVRFと同じPE上にない限り、効果的に機能します。ただし、BGPの制約により、2つが同じPE上にある場合は機能しません。これは、BGP仕様[RFC4271]により、BGPスピーカーが、自身が発信した受信プレフィックスアドバタイズを拒否するためです。ルートリフレクターを備えた自律システムでは、ルートリフレクターはORIGINATOR_ID属性をUPDATEメッセージに添付するため、このようなプレフィックスアドバタイズメントが発信者に到達した場合、発信者は単にORIGINATOR_ID属性を確認するだけで拒否できます。 BGP仕様では、NEXT_HOP属性が受信者自身のIPアドレスと一致する場合、ピアからのルートを受け入れないように規定しています。
This document proposes a modification to BGP's behavior by defining a new community [RFC1997] value, in order to allow the technique of RT list modification by the route reflector to be used in a standard manner throughout an autonomous system, irrespective of whether or not the VRFs are on the same or different PEs.
このドキュメントは、ルートリフレクタによるRTリスト変更の手法を自律システム全体で標準的な方法で使用できるようにするために、新しいコミュニティ[RFC1997]の値を定義することにより、BGPの動作の変更を提案します。 VRFは同じまたは異なる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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
This memo defines ACCEPT_OWN, a new well-known BGP community in the First Come First Served [RFC5226] range, whose value as assigned by IANA is 0xFFFF0001. Processing of the ACCEPT_OWN community SHOULD be controlled by configuration. The functionality SHOULD default to being disabled, as further specified in Section 2.3.
このメモはACCEPT_OWNを定義します。これは、先着順[RFC5226]の範囲の新しい有名なBGPコミュニティで、IANAによって割り当てられた値は0xFFFF0001です。 ACCEPT_OWNコミュニティの処理は、構成によって制御する必要があります（SHOULD）。セクション2.3でさらに指定されているように、この機能はデフォルトで無効になっている必要があります（SHOULD）。
A router MAY accept a route whose ORIGINATOR_ID or NEXT_HOP value matches that of the receiving speaker if all of the following are true:
次のすべてが当てはまる場合、ルーターはORIGINATOR_IDまたはNEXT_HOPの値が受信側スピーカーの値と一致するルートを受け入れてもよい（MAY）。
o Processing of the ACCEPT_OWN community is enabled by configuration.
o ACCEPT_OWNコミュニティの処理は、構成によって有効になります。
o The route in question carries the ACCEPT_OWN community.
o 問題のルートにはACCEPT_OWNコミュニティが含まれています。
o The route in question originated from a source VRF on the router. The source VRF is a VRF on the router whose configured Route Distinguisher is equal to the Route Distinguisher carried in the route.
o 問題のルートは、ルータの送信元VRFから発信されました。ソースVRFは、構成済みのルート識別子がルートで伝送されるルート識別子と等しい、ルーター上のVRFです。
o The route in question is targeted to one or more destination VRFs on the router (as determined by inspecting the Route Target(s)).
o 問題のルートは、ルータ上の1つ以上の宛先VRFをターゲットとしています（ルートターゲットを検査することにより決定）。
o At least one destination VRF is different from the source VRF.
o 少なくとも1つの宛先VRFがソースVRFと異なります。
A route MUST NOT ever be accepted back into its source VRF, even if it carries one or more RTs that match that VRF.
ルートがそのVRFに一致する1つ以上のRTを伝送する場合でも、ルートがそのソースVRFに受け入れられてはなりません。
The ACCEPT_OWN community controls propagation of routes that can be associated with a source VRF by inspection of their Route Distinguisher and with a target VRF by inspection of their Route Target list (for example, VPN routes with a Subsequent Address Family Identifier (SAFI) of 128). As such, it SHOULD NOT be attached to any routes that cannot be associated with a source VRF. This implies that when propagating routes into a VRF, the ACCEPT_OWN community SHOULD NOT be propagated. Likewise, if a route carrying the ACCEPT_OWN community is received in an address family that does not allow the source VRF to be looked up, the ACCEPT_OWN community MUST be discarded. An OPTIONAL message may be logged in this case.
ACCEPT_OWNコミュニティは、ルート識別子の検査によってソースVRFに関連付けられ、ルートターゲットリストの検査によってターゲットVRFに関連付けられる可能性があるルートの伝播を制御します（たとえば、128の後続アドレスファミリ識別子（SAFI）を持つVPNルート） ）。そのため、ソースVRFに関連付けることができないルートには接続しないでください。これは、ルートをVRFに伝播するときに、ACCEPT_OWNコミュニティが伝播されるべきではないことを意味します。同様に、ソースVRFのルックアップを許可しないアドレスファミリでACCEPT_OWNコミュニティを伝送するルートを受信した場合、ACCEPT_OWNコミュニティを破棄する必要があります。この場合、OPTIONALメッセージが記録されることがあります。
ACCEPT_OWN handling SHOULD be controlled by configuration, and if controlled by configuration, it MUST default to being disabled. When ACCEPT_OWN is disabled by configuration (either explicitly or by default), the router MUST NOT apply the special route acceptance rules detailed in Section 2.1. The router SHOULD still apply the propagation rules detailed in Section 2.2.
ACCEPT_OWNの処理は、構成によって制御する必要があります（SHOULD）。構成によって制御する場合は、デフォルトで無効にする必要があります。 ACCEPT_OWNが構成によって（明示的またはデフォルトで）無効にされている場合、ルーターはセクション2.1で詳述されている特別なルート受け入れルールを適用してはなりません（MUST NOT）。ルータは、セクション2.2で詳述されている伝播ルールを適用する必要があります（SHOULD）。
If a BGP speaker supports ACCEPT_OWN and is configured for the extensions defined in this document, the following step is inserted after the LOCAL_PREF comparison step in the BGP decision process:
BGPスピーカーがACCEPT_OWNをサポートし、このドキュメントで定義されている拡張機能用に構成されている場合、BGP決定プロセスのLOCAL_PREF比較ステップの後に次のステップが挿入されます。
When comparing a pair of routes for a BGP destination, the route with the ACCEPT_OWN community attached is preferred over the route that does not have the community.
BGP宛先のルートのペアを比較する場合、ACCEPT_OWNコミュニティが接続されているルートが、コミュニティがないルートよりも優先されます。
In all other respects, the decision process remains unchanged. This extra step MUST only be invoked during the best path selection process of VPN-IP routes [RFC4364] (i.e., it MUST NOT be invoked for the best path selection of imported IP routes in a VRF). The purpose of this extra step is to allow the paths advertised by the route reflector with ACCEPT_OWN community to be selected as best over other paths that the BGP speaker may have received, hence enabling the applications ACCEPT_OWN is designed for.
他のすべての点では、決定プロセスは変更されません。この追加のステップは、VPN-IPルート[RFC4364]の最適パス選択プロセス中にのみ呼び出す必要があります（つまり、VRFにインポートされたIPルートの最適パス選択に対して呼び出してはなりません）。この追加手順の目的は、ACCEPT_OWNコミュニティを使用してルートリフレクタによってアドバタイズされたパスを、BGPスピーカーが受信した可能性のある他のパスよりも最適に選択できるようにすることです。これにより、アプリケーションACCEPT_OWNが有効になります。
The ACCEPT_OWN community as described in this document is useful within a single autonomous system that uses a single layer of route reflectors. Its use with hierarchical route reflectors would require further specification and is out of the scope of this document. Likewise, its use across multiple autonomous systems is out of the scope of this document.
このドキュメントで説明されているACCEPT_OWNコミュニティは、ルートリフレクタの単一層を使用する単一の自律システム内で役立ちます。階層型ルートリフレクタと一緒に使用するには、さらに仕様が必要になるため、このドキュメントの範囲外です。同様に、複数の自律システムでの使用は、このドキュメントの範囲外です。
This approach may also be relevant in other scenarios where a BGP speaker maintains multiple routing contexts using an approach different from that of [RFC4364], as long as the specific approach in use has the property that the BGP speaker originates and receives routes within a particular context. In such a case, "VRF" in this document should be understood to mean whatever construct provides a routing context in the specific technology under consideration. Likewise, "Route Distinguisher" should be understood to mean whatever construct allows a route's originator to associate that route with its source context, and "Route Target" should be understood to mean whatever construct allows a route to be targeted for import into a context other than its source.
このアプローチは、[GPC4364]とは異なるアプローチを使用してBGPスピーカーが複数のルーティングコンテキストを維持する他のシナリオにも関連する場合があります。ただし、使用中の特定のアプローチに、BGPスピーカーが特定のルートを発信および受信するプロパティがある場合に限ります。環境。このような場合、このドキュメントの「VRF」は、検討中の特定のテクノロジーでルーティングコンテキストを提供する構成が何であるかを意味すると理解されるべきです。同様に、「Route Distinguisher」は、ルートの発信者がそのルートをそのソースコンテキストに関連付けることを許可するすべての構成を意味すると理解されるべきであり、「Route Target」は、ルートが他のコンテキストへのインポートのターゲットになることを許可するすべての構成を意味すると理解されるべきですそのソースより。
ACCEPT_OWN as described in this document permits a router's own route prefix to be advertised to a different VRF on that router. In this respect, such a route is similar to any other BGP route and shares the same set of security vulnerabilities and concerns. This extension does not change the underlying security issues inherent in BGP VPN [RFC4364].
このドキュメントで説明されているACCEPT_OWNを使用すると、ルータ自体のルートプレフィックスをそのルータ上の別のVRFにアドバタイズできます。この点で、このようなルートは他のBGPルートと似ており、同じ一連のセキュリティの脆弱性と懸念事項を共有しています。この拡張機能は、BGP VPN [RFC4364]に固有の根本的なセキュリティ問題を変更しません。
IANA has assigned the value 0xFFFF0001 in the "BGP Well-known Communities" registry for the ACCEPT_OWN community.
IANAは、ACCEPT_OWNコミュニティの「BGP Well-known Communities」レジストリで値0xFFFF0001を割り当てました。
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <http://www.rfc-editor.org/info/rfc1997>.
[RFC1997] Chandra、R.、Traina、P。、およびT. Li、「BGP Communities Attribute」、RFC 1997、DOI 10.17487 / RFC1997、August 1996、<http://www.rfc-editor.org/info/ rfc1997>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y。、編、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>。
[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]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<http://www.rfc-editor.org/info / rfc4364>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
Appendix A. Local Extranet Application (Non-normative)
付録A.ローカルエクストラネットアプリケーション（非規範的）
One of the applications for the BGP well-known community described in this document is auto-configuration of extranets within MPLS VPN networks. Consider the following topology:
このドキュメントで説明されているBGPのよく知られたコミュニティのアプリケーションの1つは、MPLS VPNネットワーク内のエクストラネットの自動構成です。次のトポロジを検討してください。
CE1 --------+
|
(VRF 1, RD 1, RT 1)
PE1 ................... RR
(VRF 2, RD 2, RT 2)
|
CE2 --------+
Figure 1: Extranet Application
図1：エクストラネットアプリケーション
Within this topology, PE1 receives a prefix X from CE1. Prefix X is installed in VRF 1 and is advertised to the route reflector (RR) with Route Distinguisher (RD) 1 and Route Target (RT) 1 as configured on PE1. The requirement is to import prefix X into VRF 2 and advertise it to CE2 in support of extranet VPN connectivity between CE1/VRF1 and CE2/VRF2. Current BGP mechanisms for MPLS VPNs [RFC4364] require changing the import RT value and/or import policy for VRF 2 on PE1. This is operationally cumbersome in a network with a large number of border routers having complex BGP policies.
このトポロジ内で、PE1はCE1からプレフィックスXを受信します。プレフィックスXはVRF 1にインストールされ、PE1で設定されたルート識別子（RD）1およびルートターゲット（RT）1を使用してルートリフレクター（RR）にアドバタイズされます。要件は、プレフィックスXをVRF 2にインポートし、CE1 / VRF1とCE2 / VRF2の間のエクストラネットVPN接続をサポートするCE2にアドバタイズすることです。 MPLS VPN [RFC4364]の現在のBGPメカニズムでは、PE1のVRF 2のインポートRT値やインポートポリシーを変更する必要があります。これは、複雑なBGPポリシーを持つ多数の境界ルーターが存在するネットワークでは、操作上厄介です。
Alternatively, using the new ACCEPT_OWN community value, the route reflector can simply re-advertise prefix X back to PE1 with RT 2 appended. In this way, PE1 will accept prefix X despite its ORIGINATOR_ID or NEXT_HOP value, import it into VRF 2 as a result of the presence of RT 2 in the route's Extended Community path attribute, and then determine the correct adjacency rewrite within VRF 1 based on the RD value and the prefix. Note that the presence of RT 1 in the route's Extended Community path attribute will simply be ignored since RT 1 is associated with the source VRF 1. The same operation also needs to happen in the reverse direction (VRF 1 learning a route from VRF 2) to achieve establishment of an extranet VPN strictly via the route reflector without changing the BGP policy of PE1 in any way.
または、新しいACCEPT_OWNコミュニティ値を使用して、ルートリフレクターは接頭辞XをRT 2を追加したPE1に再アドバタイズするだけです。このようにして、PE1はORIGINATOR_IDまたはNEXT_HOP値にもかかわらずプレフィックスXを受け入れ、ルートの拡張コミュニティパス属性にRT 2が存在する結果としてそれをVRF 2にインポートし、次に基づいてVRF 1内の正しい隣接書き換えを決定しますRD値とプレフィックス。 RT 1はソースVRF 1に関連付けられているため、ルートの拡張コミュニティパス属性にRT 1が存在しても無視されることに注意してください。同じ操作を逆方向でも行う必要があります（VRF 1がVRF 2からルートを学習） PE1のBGPポリシーを変更することなく、ルートリフレクタを介してエクストラネットVPNを厳密に確立するため。
A router performing such an extranet application can accept a route with its own ORIGINATOR_ID or NEXT_HOP value only if the VRF in which the router originated the route is different from the VRF in which the router accepts the re-advertised route.
このようなエクストラネットアプリケーションを実行するルーターは、ルーターがルートを発信したVRFが、再アドバタイズされたルートを受け入れるVRFと異なる場合にのみ、独自のORIGINATOR_IDまたはNEXT_HOP値を持つルートを受け入れることができます。
Acknowledgments
謝辞
The authors would like to thank Yakov Rekhter, Jim Guichard, Clarence Filsfils, John Mullooly, Jeff Haas, Pranav Mehta, and Tamas Mondal for their valuable comments and suggestions. The decision process changes were suggested by Pranav Mehta to solve the remote extranet problem.
著者は、貴重なコメントと提案を提供してくれたYakov Rekhter、Jim Guichard、Clarence Filsfils、John Mullooly、Jeff Haas、Pranav Mehta、およびTamas Mondalに感謝します。決定プロセスの変更は、リモートエクストラネットの問題を解決するためにPranav Mehtaによって提案されました。
Authors' Addresses
著者のアドレス
James Uttaro AT&T 200 S. Laurel Avenue Middletown, NJ 07748 United States Email: uttaro@att.com
James Uttaro AT＆T 200 S. Laurel Avenue Middletown、NJ 07748 United States Email：uttaro@att.com
Pradosh Mohapatra Sproute Networks Email: mpradosh@yahoo.com
Pradosh Mohpatra Sprout Networksメール：mpradosh：yahoo.com
David J. Smith Cisco Systems 111 Wood Avenue South Iselin, NJ 08830 United States Email: djsmith@cisco.com
David J. Smith Cisco Systems 111 Wood Avenue South Iselin、NJ 08830 United States Email：djsmith@cisco.com
Robert Raszuk Mirantis Inc. 615 National Ave. #100 Mountain View, CA 94043 United States Email: robert@raszuk.net
Robert Raszuk Mirantis Inc. 615 National Ave.＃100 Mountain View、CA 94043 United States Email：robert@raszuk.net
John Scudder Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States Email: jgs@juniper.net
John Scudder Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089 United States Email：jgs@juniper.net