[要約] RFC 7309は、異なるドメイン間のVPLSサービスにおける冗長性メカニズムについての要約です。その目的は、VPLSサービスの信頼性と可用性を向上させるために、冗長性の実装方法を提案することです。
Internet Engineering Task Force (IETF) Z. Liu
Request for Comments: 7309 China Telecom
Category: Standards Track L. Jin
ISSN: 2070-1721
R. Chen
ZTE Corporation
D. Cai
S. Salam
Cisco
July 2014
Redundancy Mechanism for Inter-domain VPLS Service
ドメイン間VPLSサービスの冗長メカニズム
Abstract
概要
In many existing Virtual Private LAN Service (VPLS) inter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no Provider Edge (PE) node redundancy, or offers PE node redundancy with only a single domain. This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PE node redundancy. This document describes an inter-domain VPLS solution that provides PE node redundancy across domains.
多くの既存の仮想プライベートLANサービス（VPLS）ドメイン間展開（RFC 4762に基づく）では、疑似配線（PW）接続はプロバイダーエッジ（PE）ノードの冗長性を提供しないか、単一ドメインのみでPEノードの冗長性を提供します。この展開アプローチでは、少なくとも1つのドメインがPEノードの冗長性を提供しないため、サービス中断のリスクが高くなります。このドキュメントでは、ドメイン間でPEノードの冗長性を提供するドメイン間VPLSソリューションについて説明します。
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/rfc7309.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7309で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Network Use Case . . . . . . . . . . . . . . . . . . . . . . 4
5. PW Redundancy Application Procedure for Inter-domain
Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. ICCP Switchover Condition . . . . . . . . . . . . . . . . 6
5.1.1. Inter-domain PW Failure . . . . . . . . . . . . . . . 6
5.1.2. PE Node Isolation . . . . . . . . . . . . . . . . . . 6
5.1.3. PE Node Failure . . . . . . . . . . . . . . . . . . . 6
5.2. Inter-domain Redundancy with Two PWs . . . . . . . . . . 6
5.3. Inter-domain Redundancy with Four PWs . . . . . . . . . . 7
6. Management Considerations . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative references . . . . . . . . . . . . . . . . . . 10
10.2. Informative references . . . . . . . . . . . . . . . . . 10
In many existing Virtual Private LAN Service (VPLS) deployments based on [RFC4762], pseudowire (PW) connectivity offers no Provider Edge (PE) node redundancy, or offers PE node redundancy with only a single domain. This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PE node redundancy. This document describes an inter-domain VPLS solution that provides PE node redundancy across domains. The redundancy mechanism will provide PE node redundancy and link redundancy in both domains. The PE throughout the document refers to a routing and bridging capable PE defined in [RFC4762], Section 10. The domain in this document refers to an autonomous system (AS), or other administrative domains.
[RFC4762]に基づく多くの既存の仮想プライベートLANサービス（VPLS）展開では、疑似配線（PW）接続はプロバイダーエッジ（PE）ノードの冗長性を提供しないか、単一ドメインのみでPEノードの冗長性を提供します。この展開アプローチでは、少なくとも1つのドメインがPEノードの冗長性を提供しないため、サービス中断のリスクが高くなります。このドキュメントでは、ドメイン間でPEノードの冗長性を提供するドメイン間VPLSソリューションについて説明します。冗長メカニズムは、両方のドメインでPEノードの冗長性とリンクの冗長性を提供します。ドキュメント全体のPEは、[RFC4762]、セクション10で定義されたルーティングおよびブリッジング対応PEを指します。このドキュメントのドメインは、自律システム（AS）、またはその他の管理ドメインを指します。
The solution relies on the use of the Inter-Chassis Communication Protocol (ICCP) [RFC7275] to coordinate between the two redundant edge nodes, and use of PW Preferential Forwarding Status Bit [RFC6870] to negotiate the PW status. There is no change to any protocol message formats and no new protocol options are introduced. This solution is a description of reusing existing protocol building blocks to achieve the desired function, but also defines implementation behavior necessary for the function to work.
ソリューションは、シャーシ間通信プロトコル（ICCP）[RFC7275]を使用して2つの冗長エッジノード間を調整し、PW優先転送ステータスビット[RFC6870]を使用してPWステータスをネゴシエートします。プロトコルメッセージの形式に変更はなく、新しいプロトコルオプションは導入されていません。このソリューションは、既存のプロトコルビルディングブロックを再利用して目的の機能を実現するための説明ですが、機能が機能するために必要な実装動作も定義しています。
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]で説明されているように解釈されます。
Inter-AS VPLS offerings are widely deployed in service provider networks today. Typically, the Autonomous System Border Router (ASBR) and associated physical links that connect the domains carry a multitude of services. As such, it is important to provide PE node and link redundancy, to ensure high service availability and meet the end customer service level agreements (SLAs).
Inter-AS VPLSオファリングは、今日のサービスプロバイダーネットワークに広く導入されています。通常、自律システム境界ルーター（ASBR）と、ドメインを接続する関連する物理リンクは、多数のサービスを提供します。そのため、PEノードとリンクの冗長性を提供し、高いサービスアベイラビリティを確保し、エンドカスタマーのサービスレベル契約（SLA）を満たすことが重要です。
Several current deployments of inter-AS VPLS are implemented like inter-AS option A as described in [RFC4364], Section 10, where the Virtual Local Area Network (VLAN) is used to hand-off the services between two domains. In these deployments, PE node/link redundancy is achieved using Multi-Chassis Link Aggregation (MC-LAG) and ICCP [RFC7275]. This, however, places two restrictions on the interconnection: the two domains must be interconnected using Ethernet links, and the links must be homogeneous, i.e., of the same speed, in order to be aggregated. These two conditions cannot always be guaranteed in live deployments. For instance, there are many scenarios where the interconnection between the domains uses packet over Synchronous Optical Networking (SONET) / Synchronous Digital Hierarchy (SDH), thereby ruling out the applicability of MC-LAG as a redundancy mechanism. As such, from a technical point of view, it is desirable to use PWs to interconnect the VPLS domains, and to offer resiliency using PW redundancy mechanisms.
[RFC4364]のセクション10で説明されているように、AS間VPLSの現在のいくつかの導入はAS間オプションAのように実装されており、仮想ローカルエリアネットワーク（VLAN）を使用して2つのドメイン間でサービスをハンドオフします。これらの展開では、PEノード/リンクの冗長性は、マルチシャーシリンク集約（MC-LAG）およびICCP [RFC7275]を使用して実現されます。ただし、これにより、相互接続に2つの制限が課せられます。2つのドメインはイーサネットリンクを使用して相互接続する必要があり、集約するためにはリンクが同種、つまり同じ速度である必要があります。これら2つの条件は、ライブ展開で常に保証されるわけではありません。たとえば、ドメイン間の相互接続でパケットオーバーシンクロナスオプティカルネットワーキング（SONET）/シンクロナスデジタルヒエラルキー（SDH）を使用し、MC-LAGの冗長性メカニズムとしての適用性を排除するシナリオが多数あります。したがって、技術的な観点から、VPLSドメインを相互接続するためにPWを使用し、PW冗長メカニズムを使用して回復力を提供することが望ましいです。
Multiprotocol Border Gateway Protocol (MP-BGP) can be used for VPLS inter-domain protection, as described in [RFC6074], using either option B or option C inter-AS models. However, with this solution, the protection time relies on BGP control-plane convergence. In certain deployments, with tight SLA requirements on availability, this mechanism may not provide the desired failover time characteristics. Furthermore, in certain situations MP-BGP is not deployed for VPLS. The redundancy solution described in this document reuses ICCP [RFC7275] and PW redundancy [RFC6718] to provide fast convergence.
マルチプロトコルボーダーゲートウェイプロトコル（MP-BGP）は、[RFC6074]で説明されているように、オプションBまたはオプションCのAS間モデルを使用して、VPLSドメイン間保護に使用できます。ただし、このソリューションでは、保護時間はBGPコントロールプレーンの収束に依存します。特定の展開では、可用性に関する厳しいSLA要件があるため、このメカニズムでは目的のフェイルオーバー時間特性を提供できない場合があります。さらに、特定の状況では、MP-BGPはVPLSに展開されません。このドキュメントで説明する冗長性ソリューションは、ICCP [RFC7275]とPW冗長性[RFC6718]を再利用して高速コンバージェンスを提供します。
Furthermore, in the case where label switched multicast is not used for VPLS multicast [RFC7117], the solution described here provides a better behavior compared to inter-AS option B: with option B, each PE must perform ingress replication to all other PEs in its local as well as the remote domain. Whereas, with the ICCP solution, the PE only replicates to local PEs and to the ASBR. The ASBR then sends traffic point to point to the remote ASBR, and the remote ASBR replicates to its local PEs. As a result, the load of replication is distributed and is more efficient than option B.
さらに、ラベルスイッチドマルチキャストがVPLSマルチキャストに使用されない場合[RFC7117]、ここで説明するソリューションは、AS間オプションBに比べて優れた動作を提供します。オプションBでは、各PEは、他のすべてのPEへの入力レプリケーションを実行する必要があります。ローカルドメインとリモートドメイン。一方、ICCPソリューションでは、PEはローカルPEとASBRにのみ複製されます。次に、ASBRはトラフィックをポイントツーポイントでリモートASBRに送信し、リモートASBRはそのローカルPEに複製します。その結果、レプリケーションの負荷が分散され、オプションBよりも効率的になります。
Two PW redundancy modes defined in [RFC6718], namely independent mode and master/slave mode, are applicable in this solution. In order to maintain control-plane separation between two domains, the independent mode is preferred by operators. The master/slave mode provides some enhanced capabilities and, hence, is included in this document.
[RFC6718]で定義されている2つのPW冗長モード、つまり独立モードとマスター/スレーブモードは、このソリューションに適用できます。 2つのドメイン間のコントロールプレーンの分離を維持するために、オペレーターは独立モードを推奨します。マスター/スレーブモードはいくつかの拡張機能を提供するため、このドキュメントに含まれています。
There are two network use cases for VPLS inter-domain redundancy: two-PWs redundancy case, and four-PWs redundancy case.
VPLSドメイン間冗長性には、2つのPW冗長性の場合と4つのPW冗長性の場合の2つのネットワーク使用例があります。
Figure 1 presents an example use case with two inter-domain PWs. PE3/PE4/PE5/PE6 may be ASBRs of their respective AS, or VPLS PEs within its own AS. PE3 and PE4 belong to one redundancy group (RG), and PE5 and PE6 belong to another RG. A deployment example of this use case is where there are only two physical links between two domains and PE3 is physically connected with PE5, and PE4 is physically connected with PE6.
図1は、2つのドメイン間PWの使用例を示しています。 PE3 / PE4 / PE5 / PE6は、それぞれのASのASBR、またはそれ自体のAS内のVPLS PEです。 PE3とPE4は1つの冗長グループ（RG）に属し、PE5とPE6は別のRGに属しています。このユースケースの展開例は、2つのドメイン間に物理リンクが2つしかなく、PE3がPE5に物理的に接続され、PE4がPE6に物理的に接続されている場合です。
+---------+ +---------+
+---+ | +-----+ | active PW1 | +-----+| +---+
|PE1|---|-| PE3 |-|-----------------|--| PE5 ||----|PE7|
+---+\ |/+-----+ | | +-----+\ /+---+
| \ / | * | | * | |\ / |
| \| | |ICCP| |ICCP| | | \ |
| / \ | * | | * | |/ \ |
+---+/ |\+-----+ | | +-----+/ \+---+
|PE2|---|-| PE4 |-|-----------------|--| PE6 ||----|PE8|
+---+ | +-----+ | standby PW2 | +-----+| +---+
| | | |
| | | |
| RG1 | | RG2 |
+---------+ +---------+
operator A network operator B network
Figure 1
図1
Figure 2 presents a four-PWs inter-domain VPLS redundancy use case. PE3/PE4/PE5/PE6 may be ASBRs of their respective AS, or VPLS PEs within its own AS. A deployment example of this use case is where there are four physical links between two domains and four PEs are physically connected with each other with four links.
図2は、4 PWのドメイン間VPLS冗長性の使用例を示しています。 PE3 / PE4 / PE5 / PE6は、それぞれのASのASBR、またはそれ自体のAS内のVPLS PEです。この使用例の展開例は、2つのドメイン間に4つの物理リンクがあり、4つのPEが4つのリンクで互いに物理的に接続されている場合です。
+---------+ +---------+
+---+ | +-----+ | | +-----+| +---+
|PE1|---|-| PE3 |-|--------PW1------|--| PE5 ||----|PE7|
| | | | |-|-PW3\ /------|--| || | |
+---+\ |/+-----+ | \ / | +-----+\ /+---+
| \ / | * | \ / | * | |\ / |
| \| | |ICCP| X |ICCP| | | \ |
| / \ | * | / \ | * | |/ \ |
+---+/ |\+-----+ | / \ | +-----+/ \+---+
| | | | |-|-PW4/ \------|--| || | |
|PE2|---|-| PE4 |-|----PW2----------|--| PE6 ||----|PE8|
+---+ | +-----+ | | +-----+| +---+
| | | |
| | | |
| RG1 | | RG2 |
+---------+ +---------+
operator A network operator B network
Figure 2
図2
PW redundancy application procedures are described in Section 9.1 of [RFC7275]. When a PE node encounters a failure, the other PE takes over. This document reuses the PW redundancy mechanism defined in [RFC7275], with new ICCP switchover conditions as specified in following section.
PW冗長性の適用手順は、[RFC7275]のセクション9.1で説明されています。 PEノードに障害が発生すると、他のPEが引き継ぎます。このドキュメントでは、[RFC7275]で定義されているPW冗長メカニズムを再利用し、次のセクションで指定されている新しいICCPスイッチオーバー条件を使用しています。
There are two PW redundancy modes defined in [RFC6870]: Independent mode and Master/Slave mode. For the inter-domain four-PW scenario, it is required that PEs ensure that the same mode be supported on the two ICCP peers in the same RG. This can be achieved using manual configuration at the ICCP peers. Other methods for ensuring consistency are out of the scope of this document.
[RFC6870]で定義されている2つのPW冗長モードがあります：独立モードとマスター/スレーブモード。ドメイン間4 PWシナリオの場合、PEは、同じRG内の2つのICCPピアで同じモードがサポートされるようにする必要があります。これはICCPピアで手動設定を使用して実現できます。一貫性を確保するための他の方法は、このドキュメントの範囲外です。
When a PE receives advertisements from the active PE, in the same RG, indicating that all the inter-domain PW status has changed to DOWN/ STANDBY, then if it has the highest priority (after the advertising PE), it SHOULD advertise active state for all of its associated inter-domain PWs.
PEが同じRGでアクティブPEからアドバタイズを受信すると、すべてのドメイン間PWステータスがDOWN / STANDBYに変更されたことを示し、優先度が最も高い場合（アドバタイズPEの後）、アクティブステートをアドバタイズする必要があります（SHOULD）関連するすべてのドメイン間PWに対して。
When a PE detects failure of all PWs to the local domain, it SHOULD advertise standby state for all its inter-domain PWs to trigger remote PE to switchover.
PEがローカルドメインへのすべてのPWの障害を検出すると、すべてのドメイン間PWがスタンバイ状態をアドバタイズして、リモートPEのスイッチオーバーをトリガーする必要があります。
When a PE node detects that the active PE, that is a member of the same RG, has gone down, if the local PE has redundant PWs for the affected services and has the highest priority (after the failed PE), it SHOULD advertise the active state for all associated inter-domain PWs.
PEノードが同じRGのメンバーであるアクティブなPEがダウンしたことを検出した場合、ローカルPEに影響を受けるサービスの冗長PWがあり、（障害が発生したPEの後に）最も高い優先度がある場合、それを通知する必要があります（SHOULD）関連するすべてのドメイン間PWのアクティブ状態。
In this use case, it is recommended that the operation be as follows:
この使用例では、操作を次のようにすることをお勧めします。
o ICCP deployment option: ICCP is deployed on VPLS edge nodes in both domains;
o ICCP展開オプション：ICCPは、両方のドメインのVPLSエッジノードに展開されます。
o PW redundancy mode: independent mode only;
o PW冗長モード：独立モードのみ。
o Protection architectures: 1:1 (1 standby, 1 active).
o 保護アーキテクチャ：1：1（1スタンバイ、1アクティブ）。
The switchover rules described in Section 5.1 apply. Before deploying this inter-domain VPLS, the operators should negotiate to configure the same PW high/low priority at two PW endpoints. The inter-domain VPLS relationship normally involves a contractual process between operators, and the configuration of PW roles forms part of this process. For example, in Figure 1, PE3 and PE5 must both have higher/lower priority than PE4 and PE6; otherwise, both PW1 and PW2 will be in standby state.
セクション5.1で説明されている切り替え規則が適用されます。このドメイン間VPLSを展開する前に、オペレーターは2つのPWエンドポイントで同じPW高/低優先度を構成するように交渉する必要があります。ドメイン間のVPLS関係には通常、オペレーター間の契約プロセスが含まれ、PWロールの構成はこのプロセスの一部を形成します。たとえば、図1では、PE3とPE5はどちらもPE4とPE6よりも優先度が高い/低い必要があります。そうでない場合、PW1とPW2の両方がスタンバイ状態になります。
In this use case, there are two options to provide protection: 1:1 and 3:1 protection. The inter-domain PWs that connect to the same PE should have proper PW priority to advertise the same active/standby state. For example, in Figure 2, both PW1 and PW3 are connected to PE3 and should advertise active/standby state.
この使用例では、保護を提供する2つのオプションがあります。1：1と3：1の保護です。同じPEに接続するドメイン間PWは、同じアクティブ/スタンバイ状態をアドバタイズするために適切なPWプライオリティを持つ必要があります。たとえば、図2では、PW1とPW3の両方がPE3に接続されており、アクティブ/スタンバイ状態を通知する必要があります。
For the 1:1 protection model, the operation would be as follows:
1：1保護モデルの場合、操作は次のようになります。
o ICCP deployment option: ICCP is deployed on VPLS edge nodes in both domains;
o ICCP展開オプション：ICCPは、両方のドメインのVPLSエッジノードに展開されます。
o PW redundancy mode: independent mode only;
o PW冗長モード：独立モードのみ。
o Protection architectures: 1:1 (1 standby, 1 active).
o 保護アーキテクチャ：1：1（1スタンバイ、1アクティブ）。
The switchover rules described in Section 5.1 apply. In this case, the operators do not need to do any coordination of the inter-domain PW priority. The PE detecting one PW DOWN SHOULD set the other PW to STANDBY if available, and then synchronize the updated state to its ICCP peer. When a PE detects that the PWs from the ICCP peer PE are DOWN or STANDBY, it SHOULD switchover as described in Section 5.1.1.
セクション5.1で説明されている切り替え規則が適用されます。この場合、オペレーターはドメイン間のPW優先順位の調整を行う必要はありません。 1つのPWダウンを検出したPEは、他のPWをSTANDBYに設定し（可能な場合）、更新された状態をそのICCPピアに同期させます。 PEがICCPピアPEからのPWがDOWNまたはSTANDBYであることを検出すると、セクション5.1.1で説明されているように、スイッチオーバーする必要があります。
There are two variants of the 3:1 protection model. We will refer to them as options A and B. The implementation MUST support option A and MAY support option B. Option B will be useful when the two legacy PEs in one domain do not support the function in this document. The two legacy PEs still need to support PW redundancy defined in [RFC6870] and be configured as slave node.
3：1保護モデルには2つのバリアントがあります。それらをオプションAおよびBと呼びます。実装はオプションAをサポートする必要があり、オプションBをサポートする場合があります。1つのドメイン内の2つのレガシーPEがこのドキュメントの機能をサポートしない場合、オプションBが役立ちます。 2つのレガシーPEは、[RFC6870]で定義されたPW冗長性をサポートし、スレーブノードとして構成する必要があります。
For option A of the 3:1 protection model, the support of the Request Switchover status bit [RFC6870] is required. The operation is as follows:
3：1保護モデルのオプションAでは、スイッチオーバー要求ステータスビット[RFC6870]のサポートが必要です。操作は次のとおりです。
o ICCP deployment option: ICCP is deployed on VPLS edge nodes in both domains;
o ICCP展開オプション：ICCPは、両方のドメインのVPLSエッジノードに展開されます。
o PW redundancy mode: Independent mode with 'request switchover' bit support;
o PW冗長モード：「リクエストスイッチオーバー」ビットをサポートする独立モード。
o Protection architectures: 3:1 (3 standby, 1 active).
o 保護アーキテクチャ：3：1（スタンバイ3、アクティブ1）。
In this case, the procedure on the PE for the PW failure is per Section 6.3 of [RFC6870] and with the following additions:
この場合、PW障害に対するPEでの手順は、[RFC6870]のセクション6.3に基づいており、以下が追加されています。
o When the PE detects failure of the active inter-domain PW, it SHOULD switch to the other local standby inter-domain PW if available, and send an updated LDP PW status message with the 'request switchover' bit set on that local standby inter-domain PW to the remote PE;
o PEがアクティブなドメイン間PWの障害を検出すると、利用可能な場合は他のローカルスタンバイドメイン間PWに切り替えて、そのローカルスタンバイ間で「スイッチオーバー要求」ビットが設定された更新済みLDP PWステータスメッセージを送信する必要があります（SHOULD）。リモートPEへのドメインPW。
o Local and remote PE SHOULD also update the new PW status to their ICCP peers, respectively, in Application Data Messages with the PW-RED Synchronization Request TLV for corresponding service, so as to synchronize the latest PW status on both PE sides.
o ローカルおよびリモートPEは、対応するサービスのPW-RED同期要求TLVを使用して、アプリケーションデータメッセージ内のそれぞれのICCPピアに新しいPWステータスを更新し、両方のPE側で最新のPWステータスを同期する必要もあります。
o While waiting for the acknowledgement, the PE that sends the 'request switchover' bit may receive a switchover request from its ICCP peer's PW remote endpoint by virtue of the ICCP synchronization. The PE MUST compare IP addresses with that PW remote peer. The PE with a higher IP address SHOULD ignore the request and continue to wait for the acknowledgement from its peer in the remote domain. The PE with the lower IP address SHOULD clear the 'request switchover' bit and set the 'Preferential Forwarding' local status bit, and update the PW status to ICCP peer.
o 確認応答を待機している間、「スイッチオーバー要求」ビットを送信するPEは、ICCP同期により、そのICCPピアのPWリモートエンドポイントからスイッチオーバー要求を受信する場合があります。 PEはIPアドレスをそのPWリモートピアと比較する必要があります。より高いIPアドレスを持つPEは、リクエストを無視して、リモートドメインのピアからの確認応答を待ち続ける必要があります（SHOULD）。より低いIPアドレスを持つPEは、「スイッチオーバー要求」ビットをクリアし、「優先転送」ローカルステータスビットを設定して、PWステータスをICCPピアに更新する必要があります（SHOULD）。
o The remote PE receiving the 'request switchover' bit SHOULD acknowledge the request and activate the PW only when it is ready to take over as described in Section 5.1; otherwise, it SHOULD ignore the request.
o 「リクエストスイッチオーバー」ビットを受信したリモートPEは、セクション5.1で説明されているように、引き継ぎの準備ができたときにのみ、リクエストを確認してPWをアクティブにする必要があります。それ以外の場合は、リクエストを無視する必要があります。
The PE node isolation failure and PE node failure is described in Section 5.1.
PEノード分離障害およびPEノード障害については、セクション5.1で説明します。
For option B of the 3:1 protection model, master/slave mode support is required and should be as follows:
3：1保護モデルのオプションBの場合、マスター/スレーブモードのサポートが必要であり、次のようにする必要があります。
o ICCP deployment option: ICCP is deployed on VPLS edge nodes in only one domain;
o ICCP展開オプション：ICCPは、1つのドメインのみのVPLSエッジノードに展開されます。
o PW redundancy mode: master/slave only;
o PW冗長モード：マスター/スレーブのみ。
o Protection architectures: 3:1 (3 standby, 1 active).
o 保護アーキテクチャ：3：1（スタンバイ3、アクティブ1）。
When master/slave PW redundancy mode is employed, the network operators of two domains must agree on which domain PEs will be master, and configure the devices accordingly. The inter-domain PWs that connect to one PE should have higher PW priority than the PWs on the other PE in the same RG. The procedure on the PE for PW failure is as follows:
マスター/スレーブPW冗長モードが採用されている場合、2つのドメインのネットワークオペレーターは、どのドメインPEがマスターになるかについて合意し、それに応じてデバイスを構成する必要があります。 1つのPEに接続するドメイン間PWは、同じRG内の他のPE上のPWよりも高いPW優先度を持つ必要があります。 PW障害のPEでの手順は次のとおりです。
o The PE with higher PW priority should only enable one PW active, and the other PWs should be in the standby state.
o より高いPWプライオリティを持つPEは、1つのPWのみを有効にし、他のPWはスタンバイ状態にする必要があります。
o When the PE detects an active PW DOWN, it SHOULD enable the other local standby PW to be active with preference. Only when two inter-domain PWs connected to the PE are DOWN, the ICCP peer PE in the same RG SHOULD switchover as described in Section 5.1.
o PEがアクティブなPW DOWNを検出すると、他のローカルスタンバイPWが優先的にアクティブになるようにする必要があります（SHOULD）。 PEに接続されている2つのドメイン間PWがダウンしている場合にのみ、5.1で説明されているように、同じRG内のICCPピアPEがスイッチオーバーする必要があります。
The PE node isolation failure and PE node failure are described in Section 5.1.
PEノード分離障害とPEノード障害については、セクション5.1で説明します。
When deploying the inter-domain redundancy mechanism described in this document, consistent provisioning is required for proper operation. The two domains must both use the same use case (Section 5.2 or Section 5.3). Within each section, all of the described modes and options must be provisioned identically both within each RG and between the RGs. Additionally, for the two-PWs redundancy options defined in Section 5.2, the two operators must also negotiate to configure same high/low PW priority at the two PW endpoints. If the provisioning is inconsistent, then the inter-domain redundancy mechanism may not work properly.
このドキュメントで説明されているドメイン間冗長メカニズムを展開する場合、適切な操作のために一貫したプロビジョニングが必要です。 2つのドメインは両方とも同じユースケースを使用する必要があります（セクション5.2またはセクション5.3）。各セクション内では、説明されているすべてのモードとオプションを、各RG内とRG間で同じようにプロビジョニングする必要があります。さらに、セクション5.2で定義されている2つのPWの冗長性オプションの場合、2つのオペレーターは、2つのPWエンドポイントで同じ高/低PW優先度を構成するようにネゴシエートする必要があります。プロビジョニングに一貫性がない場合、ドメイン間の冗長メカニズムが適切に機能しない可能性があります。
Besides the security properties of [RFC7275] for the ICCP control plane, and [RFC4762] and [RFC6870] for the PW control plane, this document has additional security considerations for the ICCP control plane.
ICCPコントロールプレーンの[RFC7275]、およびPWコントロールプレーンの[RFC4762]および[RFC6870]のセキュリティプロパティに加えて、このドキュメントではICCPコントロールプレーンのセキュリティに関する追加の考慮事項があります。
In this document, ICCP is deployed between two PEs or ASBRs. The two PEs or ASBRs should only be connected by a network that is well managed and whose service levels and availability are highly monitored. This should be ensured by the operator.
このドキュメントでは、ICCPは2つのPEまたはASBRの間に配置されています。 2つのPEまたはASBRは、適切に管理され、サービスレベルと可用性が高度に監視されているネットワークによってのみ接続される必要があります。これは、オペレーターが保証する必要があります。
The state flapping on the inter-domain and intra-domain PW may cause security threats or be exploited to create denial-of-service attacks. For example, excessive PW state flapping (e.g., by malicious peer PE's implementation) may lead to excessive ICCP exchanges. Implementations SHOULD provide mechanisms to perform control-plane policing and mitigate such types of attacks.
ドメイン間およびドメイン内のPWで状態がフラッピングすると、セキュリティ上の脅威が発生したり、サービス拒否攻撃を引き起こすために悪用される可能性があります。たとえば、過度のPW状態のフラッピング（たとえば、悪意のあるピアPEの実装による）は、過度のICCP交換を引き起こす可能性があります。実装は、コントロールプレーンポリシングを実行し、そのようなタイプの攻撃を軽減するメカニズムを提供する必要があります（SHOULD）。
The authors would like to thank Sami Boutros, Giles Heron, Adrian Farrel, Andrew G. Malis, and Stephen Kent for their valuable comments.
著者は、貴重なコメントを提供してくれたSami Boutros、Giles Heron、Adrian Farrel、Andrew G. Malis、Stephen Kentに感謝します。
Daniel Cohn Email:daniel.cohn.ietf@gmail.com
ダニエルコーンメール：daniel.cohn.ietf@gmail.com
Yubao Wang ZTE Corporation
Y U Bao Wang ZT E Corporation
Nanjing, China Email: wang.yubao@zte.com.cn
中国南京メール：wang.yubao@zte.com.cn
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC6870] Muley, P. and M. Aissaoui, "Pseudowire Preferential Forwarding Status Bit", RFC 6870, February 2013.
[RFC6870] Muley、P。およびM. Aissaoui、「Pseudowire Preferential Forwarding Status Bit」、RFC 6870、2013年2月。
[RFC7275] Martini, L., Salam, S., Sajassi, A., Bocci, M., Matsushima, S., and T. Nadeau, "Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy", RFC 7275, June 2014.
[RFC7275] Martini、L.、Salam、S.、Sajassi、A.、Bocci、M.、Matsushima、S。、およびT. Nadeau、「レイヤー2仮想プライベートネットワーク（L2VPN）プロバイダーエッジのシャーシ間通信プロトコル」 （PE）Redundancy」、RFC 7275、2014年6月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、2006年2月。
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.
[RFC4762] Lasserre、M。およびV. Kompella、「Label Distribution Protocol（LDP）Signalingを使用したVirtual Private LAN Service（VPLS）」、RFC 4762、2007年1月。
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011.
[RFC6074]ローゼン、E。、デイビー、B。、ラドアカ、V。、およびW.ルオ、「プロビジョニング、自動検出、およびレイヤー2仮想プライベートネットワーク（L2VPN）でのシグナリング」、RFC 6074、2011年1月。
[RFC6718] Muley, P., Aissaoui, M., and M. Bocci, "Pseudowire Redundancy", RFC 6718, August 2012.
[RFC6718] Muley、P.、Aissaoui、M。、およびM. Bocci、「Pseudowire Redundancy」、RFC 6718、2012年8月。
[RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, February 2014.
[RFC7117] Aggarwal、R.、Kamite、Y.、Fang、L.、Rekhter、Y。、およびC. Kodeboniya、「Multicast in Virtual Private LAN Service（VPLS）」、RFC 7117、2014年2月。
Authors' Addresses
著者のアドレス
Zhihua Liu China Telecom 109 Zhongshan Ave. Guangzhou 510630 P.R.China
Z Hi Flower l IU China Telecom 109 Z bombing Nave。Guangzhou 510630 P.R. China
EMail: zhliu@gsta.com
Lizhong Jin Shanghai P.R.China
l一種のジンShanghai P.R. China
EMail: lizho.jin@gmail.com
Ran Chen ZTE Corporation NO.19 East Huayuan Road Haidian District Beijing 100191 P.R.China
走った陳ZT E株式会社no.19東hu中庭道路Hショートポイント地区北京100191 P.R.中国
EMail: chen.ran@zte.com.cn
Dennis Cai Cisco 3750 Cisco Way, San Jose, California 95134 USA
Dennis Cai Cisco 3750 Cisco Way、San Jose、California 95134 USA
EMail: dcai@cisco.com
Samer Salam Cisco 595 Burrard Street, Suite:2123 Vancouver, BC V7X 1J1 Canada
Samer Salam Cisco 595 Burrard Street、Suite：2123 Vancouver、BC V7X 1J1 Canada
EMail: ssalam@cisco.com