[要約] RFC 7361は、階層型仮想プライベートLANサービス（H-VPLS）における最適化されたMACアドレスの撤回のためのLDP拡張についての規格です。このRFCの目的は、H-VPLSネットワークでのMACアドレスの効率的な管理と撤回を実現することです。
Internet Engineering Task Force (IETF) P. Dutta
Request for Comments: 7361 F. Balus
Category: Standards Track Alcatel-Lucent
ISSN: 2070-1721 O. Stokes
Extreme Networks
G. Calvignac
Orange
D. Fedyk
Hewlett-Packard
September 2014
LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS)
階層型仮想プライベートLANサービス（H-VPLS）での最適化されたMACアドレスの引き出しのためのLDP拡張
Abstract
概要
RFC 4762 describes a mechanism to remove or unlearn Media Access Control (MAC) addresses that have been dynamically learned in a Virtual Private LAN Service (VPLS) instance for faster convergence on topology changes. The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology changes. This document defines an enhancement to the MAC address withdraw procedure with an empty MAC list (RFC 4762); this enhancement enables a Provider Edge (PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to RFC 4762 MAC withdraw procedures are specified to provide an optimized MAC flushing for the Provider Backbone Bridging (PBB) VPLS specified in RFC 7041.
RFC 4762は、トポロジ変更の収束を高速化するために、仮想プライベートLANサービス（VPLS）インスタンスで動的に学習されたメディアアクセス制御（MAC）アドレスを削除または学習解除するメカニズムについて説明しています。この手順では、このようなトポロジ変更のために再学習を必要としないVPLSのMACアドレスも削除します。このドキュメントでは、空のMACリスト（RFC 4762）を使用したMACアドレスの引き出し手順の拡張を定義しています。この拡張により、プロバイダーエッジ（PE）デバイスは、再学習が必要なMACアドレスのみを削除できます。 RFC 4762に追加されたMAC取り消し手順は、RFC 7041で指定されているプロバイダーバックボーンブリッジング（PBB）VPLSに最適化されたMACフラッシュを提供するために指定されています。
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/rfc7361.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7361で入手できます。
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 ....................................................4
2. Terminology .....................................................6
2.1. Requirements Language ......................................6
3. Overview ........................................................6
3.1. MAC Flushing on Activation of Backup Spoke PW ..............8
3.1.1. MAC Flushing Initiated by PE-rs .....................8
3.1.2. MAC Flushing Initiated by MTU-s .....................8
3.2. MAC Flushing on Failure ....................................9
3.3. MAC Flushing in PBB-VPLS ..................................10
4. Problem Description ............................................10
4.1. MAC Flushing Optimization in VPLS Resiliency ..............10
4.1.1. MAC Flushing Optimization for Regular H-VPLS .......11
4.1.2. MAC Flushing Optimization for Native Ethernet
Access .............................................13
4.2. Black-Holing Issue in PBB-VPLS ............................13
5. Solution Description ...........................................14
5.1. MAC Flushing Optimization for VPLS Resiliency .............14
5.1.1. MAC Flush Parameters TLV ...........................15
5.1.2. Application of the MAC Flush TLV in
Optimized MAC Flushing .............................16
5.1.3. MAC Flush TLV Processing Rules for Regular VPLS ....17
5.1.4. Optimized MAC Flush Procedures .....................18
5.2. LDP MAC Flush Extensions for PBB-VPLS .....................19
5.2.1. MAC Flush TLV Processing Rules for PBB-VPLS ........20
5.2.2. Applicability of the MAC Flush Parameters TLV ......22
6. Operational Considerations .....................................23
7. IANA Considerations ............................................24
7.1. New LDP TLV ...............................................24
7.2. New Registry for MAC Flush Flags ..........................24
8. Security Considerations ........................................24
9. Contributing Author ............................................25
10. Acknowledgements ..............................................25
11. References ....................................................25
11.1. Normative References .....................................25
11.2. Informative References ...................................25
A method of Virtual Private LAN Service (VPLS), also known as Transparent LAN Services (TLS), is described in [RFC4762]. A VPLS is created using a collection of one or more point-to-point pseudowires (PWs) [RFC4664] configured in a flat, full-mesh topology. The mesh topology provides a LAN segment or broadcast domain that is fully capable of learning and forwarding on Ethernet Media Access Control (MAC) addresses at the Provider Edge (PE) devices.
仮想プライベートLANサービス（VPLS）の方法は、透過的LANサービス（TLS）とも呼ばれ、[RFC4762]で説明されています。 VPLSは、フラットなフルメッシュトポロジで構成された1つ以上のポイントツーポイント疑似配線（PW）[RFC4664]のコレクションを使用して作成されます。メッシュトポロジは、プロバイダーエッジ（PE）デバイスのイーサネットメディアアクセス制御（MAC）アドレスで完全に学習および転送できるLANセグメントまたはブロードキャストドメインを提供します。
This VPLS full-mesh core configuration can be augmented with additional non-meshed spoke nodes to provide a Hierarchical VPLS (H-VPLS) service [RFC4762]. Throughout this document, this configuration is referred to as "regular" H-VPLS.
このVPLSフルメッシュコア構成は、追加の非メッシュスポークノードで拡張して、階層VPLS（H-VPLS）サービスを提供できます[RFC4762]。このドキュメント全体を通して、この構成は「通常の」H-VPLSと呼ばれます。
[RFC7041] describes how Provider Backbone Bridging (PBB) can be integrated with VPLS to allow for useful PBB capabilities while continuing to avoid the use of the Multiple Spanning Tree Protocol (MSTP) in the backbone. The combined solution, referred to as "PBB-VPLS", results in better scalability in terms of number of service instances, PWs, and C-MAC (Customer MAC) addresses that need to be handled in the VPLS PEs, depending on the location of the I-component in the PBB-VPLS topology.
[RFC7041]は、プロバイダーバックボーンブリッジング（PBB）をVPLSと統合して、バックボーンでのマルチスパニングツリープロトコル（MSTP）の使用を回避しながら、有用なPBB機能を可能にする方法を説明しています。 「PBB-VPLS」と呼ばれる統合ソリューションは、場所に応じて、VPLS PEで処理する必要があるサービスインスタンス、PW、およびC-MAC（カスタマーMAC）アドレスの数の点でより優れたスケーラビリティをもたらしますPBB-VPLSトポロジーのIコンポーネントの。
A MAC address withdrawal mechanism for VPLS is described in [RFC4762] to remove or unlearn MAC addresses for faster convergence on topology changes in resilient H-VPLS topologies. Note that the H-VPLS topology discussed in [RFC4762] describes the two-tier hierarchy in VPLS as the basic building block of H-VPLS, but it is possible to have a multi-tier hierarchy in an H-VPLS.
VPLSのMACアドレスの引き出しメカニズムは、[RFC4762]で説明されており、MACアドレスを削除または学習解除して、復元力のあるH-VPLSトポロジでのトポロジ変更の収束を高速化します。 [RFC4762]で説明されているH-VPLSトポロジは、VPLSの2層階層をH-VPLSの基本的なビルディングブロックとして説明していますが、H-VPLSに多層階層を含めることもできます。
Figure 1 is reproduced from [RFC4762] and illustrates dual-homing in H-VPLS.
図1は[RFC4762]から複製され、H-VPLSのデュアルホーミングを示しています。
PE2-rs
+--------+
| |
| -- |
| / \ |
CE-1 | \S / |
\ | -- |
\ +--------+
\ MTU-s PE1-rs / |
+--------+ +--------+ / |
| | | | / |
| -- | Primary PW | -- |---/ |
| / \ |- - - - - - - - - - - | / \ | |
| \S / | | \S / | |
| -- | | -- |---\ |
+--------+ +--------+ \ |
/ \ \ |
/ \ +--------+
/ \ | |
CE-2 \ | -- |
\ Secondary PW | / \ |
- - - - - - - - - - - - - - - - - | \S / |
| -- |
+--------+
PE3-rs
Figure 1: An Example of a Dual-Homed MTU-s
図1：デュアルホームMTU-sの例
An example usage of the MAC flushing mechanism is the dual-homed H-VPLS where an edge device called the Multi-Tenant Unit switch (MTU-s) [RFC4762] is connected to two PE devices via a primary spoke PW and backup spoke PW, respectively. Such redundancy is designed to protect against the failure of the primary spoke PW or primary PE device. There could be multiple methods of dual-homing in H-VPLS that are not described in [RFC4762]. For example, note the following statement from Section 10.2.1 of [RFC4762].
MACフラッシュメカニズムの使用例は、マルチテナントユニットスイッチ（MTU-s）[RFC4762]と呼ばれるエッジデバイスがプライマリスポークPWおよびバックアップスポークPWを介して2つのPEデバイスに接続されているデュアルホームH-VPLSです。 、それぞれ。このような冗長性は、プライマリスポークPWまたはプライマリPEデバイスの障害から保護するように設計されています。 [RFC4762]で説明されていないH-VPLSのデュアルホーミングの複数の方法が存在する可能性があります。たとえば、[RFC4762]のセクション10.2.1の次のステートメントに注意してください。
How a spoke is designated primary or secondary is outside the scope of this document. For example, a spanning tree instance running between only the MTU-s and the two PE-rs nodes is one possible method. Another method could be configuration.
スポークをプライマリまたはセカンダリに指定する方法は、このドキュメントの範囲外です。たとえば、MTU-sと2つのPE-rsノード間のみで実行されるスパニングツリーインスタンスは、1つの可能な方法です。別の方法として、構成があります。
This document intends to clarify several H-VPLS dual-homing models that are deployed in practice and various use cases of LDP-based MAC flushing in these models.
このドキュメントでは、実際に展開されているいくつかのH-VPLSデュアルホーミングモデルと、これらのモデルでのLDPベースのMACフラッシュのさまざまな使用例を明確にすることを目的としています。
This document uses the terminology defined in [RFC7041], [RFC5036], [RFC4447], and [RFC4762].
このドキュメントでは、[RFC7041]、[RFC5036]、[RFC4447]、および[RFC4762]で定義されている用語を使用しています。
Throughout this document, "Virtual Private LAN Service" (VPLS) refers to the emulated bridged LAN service offered to a customer. "H-VPLS" refers to the hierarchical connectivity or layout of the MTU-s and the Provider Edge routing- and switching-capable (PE-rs) devices offering the VPLS [RFC4762].
このドキュメント全体を通して、「仮想プライベートLANサービス（VPLS）」は、顧客に提供されるエミュレートされたブリッジLANサービスを指します。 「H-VPLS」は、VPLS [RFC4762]を提供するMTU-sとプロバイダーエッジルーティングおよびスイッチング対応（PE-rs）デバイスの階層接続またはレイアウトを指します。
The terms "spoke node" and "MTU-s" in H-VPLS are used interchangeably.
H-VPLSの「スポークノード」と「MTU-s」という用語は、同じ意味で使用されています。
"Spoke PW" refers to the Pseudowire (PW) that provides connectivity between MTU-s and PE-rs nodes.
「スポークPW」は、MTU-sノードとPE-rsノード間の接続を提供する疑似配線（PW）を指します。
"Mesh PW" refers to the PW that provides connectivity between PE-rs nodes in a VPLS full-mesh core.
「メッシュPW」とは、VPLSフルメッシュコアのPE-rsノード間の接続を提供するPWを指します。
"MAC flush message" refers to a Label Distribution Protocol (LDP) address withdraw message without a MAC List TLV.
「MACフラッシュメッセージ」は、MACリストTLVのないラベル配布プロトコル（LDP）アドレス撤回メッセージを指します。
A MAC flush message "in the context of a PW" refers to the message that has been received over the LDP session that is used to set up the PW used to provide connectivity in VPLS. The MAC flush message carries the context of the PW in terms of the Forwarding Equivalence Class (FEC) TLV associated with the PW [RFC4762] [RFC4447].
「PWのコンテキストで」のMACフラッシュメッセージは、VPLSで接続を提供するために使用されるPWをセットアップするために使用されるLDPセッションを介して受信されたメッセージを指します。 MACフラッシュメッセージは、PW [RFC4762] [RFC4447]に関連付けられた転送等価クラス（FEC）TLVに関してPWのコンテキストを伝達します。
In general, "MAC flushing" refers to the method of initiating and processing MAC flush messages across a VPLS instance.
一般に、「MACフラッシュ」とは、VPLSインスタンス全体でMACフラッシュメッセージを開始および処理する方法を指します。
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]で説明されているように解釈されます。
When the MTU-s switches over to the backup PW, the requirement is to flush the MAC addresses learned in the corresponding Virtual Switch Instance (VSI) in peer PE devices participating in the full mesh, to avoid the black-holing of frames to those addresses. This is accomplished by sending an LDP address withdraw message -- a new message defined in this document -- from the PE that is no longer connected to the MTU-s with the primary PW. The new message contains a list of MAC addresses to be removed and is sent to all other PEs over the corresponding LDP sessions.
MTU-sがバックアップPWに切り替わるときの要件は、フルメッシュに参加しているピアPEデバイスの対応する仮想スイッチインスタンス（VSI）で学習したMACアドレスをフラッシュして、フレームのブラックホール化を回避することです。アドレス。これは、プライマリPWでMTU-sに接続されなくなったPEから、LDPアドレスウィズドローメッセージ（このドキュメントで定義されている新しいメッセージ）を送信することで実現されます。新しいメッセージには、削除するMACアドレスのリストが含まれており、対応するLDPセッションを介して他のすべてのPEに送信されます。
In order to minimize the impact on LDP convergence time and scalability when a MAC List TLV contains a large number of MAC addresses, many implementations use an LDP address withdraw message with an empty MAC list. When a PE-rs switch in the full mesh of H-VPLS receives this message, it also flushes MAC addresses that are not affected due to the topology change, thus leading to unnecessary flooding and relearning. Throughout this document, the term "MAC flush message" is used to specify an LDP address withdraw message with an empty MAC list as described in [RFC4762]. The solutions described in this document are applicable only to LDP address withdraw messages with empty MAC lists.
MACリストTLVに多数のMACアドレスが含まれている場合のLDPコンバージェンス時間とスケーラビリティへの影響を最小限に抑えるために、多くの実装では、空のMACリストを持つLDPアドレスウィズドローメッセージを使用します。 H-VPLSのフルメッシュ内のPE-rsスイッチがこのメッセージを受信すると、トポロジ変更のために影響を受けないMACアドレスもフラッシュされるため、不要なフラッディングと再学習が発生します。このドキュメント全体を通して、「MACフラッシュメッセージ」という用語は、[RFC4762]で説明されているように、空のMACリストを持つLDPアドレス撤回メッセージを指定するために使用されます。このドキュメントで説明されているソリューションは、MACリストが空のLDPアドレス撤回メッセージにのみ適用できます。
In a VPLS topology, the core PWs remain active and learning happens on the PE-rs nodes. However, when the VPLS topology changes, the PE-rs must relearn using MAC address withdrawal or flushing. As per the MAC address withdrawal processing rules in [RFC4762], a PE device, on receiving a MAC flush message, removes all MAC addresses associated with the specified VPLS instance (as indicated in the FEC TLV) except the MAC addresses learned over the PW associated with this signaling session over which the message was received. Throughout this document, we use the terminology "positive" MAC flushing or "flush-all-but-mine" for this type of MAC flush message and its actions.
VPLSトポロジでは、コアPWはアクティブのままで、学習はPE-rsノードで行われます。ただし、VPLSトポロジが変更されると、PE-rsはMACアドレスの引き出しまたはフラッシュを使用して再学習する必要があります。 [RFC4762]のMACアドレス撤回処理ルールに従って、PEデバイスはMACフラッシュメッセージを受信すると、PWで学習したMACアドレスを除く、指定されたVPLSインスタンスに関連付けられたすべてのMACアドレスを削除します（FEC TLVに示されています）。メッセージが受信されたこのシグナリングセッションに関連付けられています。このドキュメントでは、このタイプのMACフラッシュメッセージとそのアクションに「ポジティブ」MACフラッシュまたは「flush-all-but-mine」という用語を使用しています。
This document introduces an optimized "negative" MAC flush message, described in Section 3.2, that can be configured to improve the response to topology changes in a number of Ethernet topologies where the Service Level Agreement (SLA) is dependent on minimal disruption and fast restoration of affected traffic. This new message is used in the case of Provider Backbone Bridging (PBB) topologies to restrict the flushing to a set of service instances (I-SIDs). It is also important to note that the MAC flush message described in [RFC4762], which is called "a positive MAC flush message" in this document, MUST always be handled for Backbone MACs (B-MACs) in cases where the core nodes change or fail. In dual-homed or multi-homed edge topologies, the procedures in this document augment [RFC4762] messages and provide less disruption for those cases.
このドキュメントでは、セクション3.2で説明されている、サービスレベルアグリーメント（SLA）が最小限の中断と高速な復元に依存しているイーサネットトポロジのトポロジ変更に対する応答を改善するように構成できる、最適化された「ネガティブ」MACフラッシュメッセージを紹介します。影響を受けるトラフィックの。この新しいメッセージは、プロバイダーバックボーンブリッジング（PBB）トポロジの場合に、フラッシュを一連のサービスインスタンス（I-SID）に制限するために使用されます。 [RFC4762]で説明されているMACフラッシュメッセージは、このドキュメントでは「ポジティブMACフラッシュメッセージ」と呼ばれ、コアノードが変更された場合は常にバックボーンMAC（B-MAC）で処理する必要があることに注意することも重要です。または失敗します。デュアルホームエッジトポロジまたはマルチホームエッジトポロジでは、このドキュメントの手順により[RFC4762]メッセージが拡張され、これらの場合の混乱が少なくなります。
This section describes scenarios where MAC flush withdrawal is initiated on activation of a backup PW in H-VPLS.
このセクションでは、H-VPLSでのバックアップPWのアクティブ化時にMACフラッシュの引き出しが開始されるシナリオについて説明します。
[RFC4762] specifies that on failure of the primary PW it is PE3-rs (Figure 1) that initiates MAC flushing towards the core. However, note that PE3-rs can initiate MAC flushing only when PE3-rs is dual-homing "aware" -- that is, there is some redundancy management protocol running between the MTU-s and its host PE-rs devices. The scope of this document is applicable to several dual-homing or multi-homing protocols. This document illustrates that multi-homing can be improved with negative MAC flushing. One example is BGP-based multi-homing in LDP-based VPLS, which uses the procedures defined in [VPLS-MH]. In this method of dual-homing, PE3-rs would neither forward any traffic to the MTU-s nor receive any traffic from the MTU-s while PE1-rs is acting as a primary (or designated forwarder).
[RFC4762]は、コアへのMACフラッシュを開始するのは、プライマリPWの障害時にPE3-rs（図1）であることを指定しています。ただし、PE3-rsがMACフラッシュを開始できるのは、PE3-rsがデュアルホーミングを「認識」している場合のみです。つまり、MTU-sとそのホストPE-rsデバイスの間で実行されている冗長管理プロトコルがあります。このドキュメントの範囲は、いくつかのデュアルホーミングまたはマルチホーミングプロトコルに適用できます。このドキュメントでは、ネガティブMACフラッシュを使用してマルチホーミングを改善できることを示しています。 1つの例は、[VPLS-MH]で定義された手順を使用する、LDPベースのVPLSでのBGPベースのマルチホーミングです。このデュアルホーミングの方法では、PE1-rsがプライマリ（または指定されたフォワーダー）として機能している間、PE3-rsはMTU-sにトラフィックを転送したり、MTU-sからトラフィックを受信したりしません。
When dual-homing is achieved by manual configuration in the MTU-s, the hosting PE-rs devices are dual-homing "agnostic", and PE3-rs cannot initiate MAC flush messages. PE3-rs can send or receive traffic over the backup PW, since the dual-homing control is with the MTU-s only. When the backup PW is made active by the MTU-s, the MTU-s triggers a MAC flush message. The message is sent over the LDP session associated with the newly activated PW. On receiving the MAC flush message from the MTU-s, PE3-rs (the PE-rs device with a now-active PW) would flush all the MAC addresses it has learned, except the ones learned over the newly activated spoke PW. PE3-rs further initiates a MAC flush message to all other PE devices in the core. Note that a forced switchover to the backup PW can also be invoked by the MTU-s due to maintenance or administrative activities on the former primary spoke PW.
デュアルホーミングがMTU-sの手動構成によって実現される場合、ホストしているPE-rsデバイスはデュアルホーミング「不可知論」であり、PE3-rsはMACフラッシュメッセージを開始できません。デュアルホーミング制御はMTU-sのみを使用するため、PE3-rsはバックアップPWを介してトラフィックを送受信できます。 MTU-sによってバックアップPWがアクティブになると、MTU-sがMACフラッシュメッセージをトリガーします。メッセージは、新しくアクティブ化されたPWに関連付けられたLDPセッションを介して送信されます。 MTU-sからMACフラッシュメッセージを受信すると、PE3-rs（現在アクティブなPWを持つPE-rsデバイス）は、新しくアクティブになったスポークPWで学習したものを除いて、学習したすべてのMACアドレスをフラッシュします。 PE3-rsはさらに、コア内の他のすべてのPEデバイスに対してMACフラッシュメッセージを開始します。以前のプライマリスポークPWでのメンテナンスまたは管理アクティビティが原因で、バックアップPWへの強制スイッチオーバーがMTU-sによって呼び出されることもあります。
The method of MAC flushing initiated by the MTU-s is modeled after Topology Change Notification (TCN) in the Rapid Spanning Tree Protocol (RSTP) [IEEE.802.1Q-2011]. When a bridge switches from a failed link to the backup link, the bridge sends out a TCN message over the newly activated link. Upon receiving this message, the upstream bridge flushes its entire list of MAC addresses, except the ones received over this link. The upstream bridge then sends the TCN message out of its other ports in that spanning tree instance. The message is further relayed along the spanning tree by the other bridges.
MTU-sによって開始されるMACフラッシュの方法は、高速スパニングツリープロトコル（RSTP）のトポロジ変更通知（TCN）をモデルにしています[IEEE.802.1Q-2011]。ブリッジが故障したリンクからバックアップリンクに切り替えると、ブリッジは新しくアクティブになったリンクを介してTCNメッセージを送信します。このメッセージを受信すると、アップストリームブリッジは、このリンクを介して受信したものを除いて、MACアドレスのリスト全体をフラッシュします。次に、アップストリームブリッジは、そのスパニングツリーインスタンスの他のポートからTCNメッセージを送信します。メッセージはさらに、他のブリッジによってスパニングツリーに沿って中継されます。
The MAC flushing information is propagated in the control plane. The control-plane message propagation is associated with the data path and hence follows propagation rules similar to those used for forwarding in the LDP data plane. For example, PE-rs nodes follow the data-plane "split-horizon" forwarding rules in H-VPLS (refer to Section 4.4 of [RFC4762]). Therefore, a MAC flush message is propagated in the context of mesh PW(s) when it is received in the context of a spoke PW. When a PE-rs node receives a MAC flush message in the context of a mesh PW, then it is not propagated to other mesh PWs.
MACフラッシュ情報は、コントロールプレーンに伝播されます。コントロールプレーンメッセージの伝播はデータパスに関連付けられているため、LDPデータプレーンでの転送に使用されるものと同様の伝播ルールに従います。たとえば、PE-rsノードは、H-VPLSのデータプレーン「split-horizon」転送ルールに従います（[RFC4762]のセクション4.4を参照）。したがって、MACフラッシュメッセージは、スポークPWのコンテキストで受信されると、メッシュPWのコンテキストで伝播されます。 PE-rsノードがメッシュPWのコンテキストでMACフラッシュメッセージを受信しても、他のメッシュPWには伝達されません。
MAC flushing on failure, or "negative" MAC flushing, is introduced in this document. Negative MAC flushing is an improvement on the current practice of sending a MAC flush message with an empty MAC list as described in Section 3.1.1. We use the term "negative" MAC flushing or "flush-all-from-me" for this kind of flushing action as opposed to the "positive" MAC flush action in [RFC4762]. In negative MAC flushing, the MAC flushing is initiated by PE1-rs (Figure 1) on detection of failure of the primary spoke PW. The MAC flush message is sent to all participating PE-rs devices in the VPLS full mesh. PE1-rs should initiate MAC flushing only if PE1-rs is dual-homing aware. (If PE1-rs is dual-homing agnostic, the policy is to not initiate MAC flushing on failure, since that could cause unnecessary flushing in the case of a single-homed MTU-s.) The specific dual-homing protocols for this scenario are outside the scope of this document, but the operator can choose to use the optimized MAC flushing described in this document or the [RFC4762] procedures.
障害時のMACフラッシュ、つまり「負の」MACフラッシュは、このドキュメントで紹介されています。負のMACフラッシュは、セクション3.1.1で説明されているように、MACフラッシュメッセージを空のMACリストで送信する現在の方法を改善したものです。 [RFC4762]の「正の」MACフラッシュアクションとは対照的に、この種のフラッシュアクションには「負の」MACフラッシュまたは「flush-all-from-me」という用語を使用します。負のMACフラッシュでは、プライマリスポークPWの障害が検出されると、PE1-rs（図1）によってMACフラッシュが開始されます。 MACフラッシュメッセージは、VPLSフルメッシュ内のすべての参加PE-rsデバイスに送信されます。 PE1-rsは、PE1-rsがデュアルホーミングに対応している場合にのみ、MACフラッシュを開始する必要があります。 （PE1-rsがデュアルホーミングにとらわれない場合、シングルホームのMTU-sの場合に不要なフラッシュを引き起こす可能性があるため、ポリシーは障害時にMACフラッシュを開始しないことです。）このシナリオの特定のデュアルホーミングプロトコルこのドキュメントの範囲外ですが、オペレーターは、このドキュメントまたは[RFC4762]の手順で説明されている最適化されたMACフラッシュを使用することを選択できます。
The procedure for negative MAC flushing is beneficial and results in less disruption than the [RFC4762] procedures, including when the MTU-s is dual-homed with a variety of Ethernet technologies, not just LDP. The negative MAC flush message is a more targeted MAC flush, and the other PE-rs nodes will flush only the specified MACs. This targeted MAC flush cannot be achieved with the MAC address withdraw message defined in [RFC4762]. Negative MAC flushing typically results in a smaller set of MACs to be flushed and results in less disruption for these topologies.
ネガティブMACフラッシュの手順は有益であり、MTU-sがLDPだけでなくさまざまなイーサネットテクノロジーでデュアルホーム化されている場合を含め、[RFC4762]手順よりも混乱が少なくなります。負のMACフラッシュメッセージは、よりターゲットを絞ったMACフラッシュであり、他のPE-rsノードは指定されたMACのみをフラッシュします。このターゲットMACフラッシュは、[RFC4762]で定義されているMACアドレス撤回メッセージでは達成できません。負のMACフラッシュでは、通常、フラッシュされるMACのセットが少なくなり、これらのトポロジの中断が少なくなります。
Note that in the case of negative MAC flushing the list SHOULD be only the MACs for the affected MTU-s. If the list is empty, then the negative MAC flush procedures will result in flushing and relearning all attached MTU-s devices for the originating PE-rs.
否定的なMACフラッシュの場合、リストは影響を受けるMTU-sのMACのみであるべきであることに注意してください。リストが空の場合、ネガティブMACフラッシュ手順により、元のPE-rsに接続されているすべてのMTU-sデバイスがフラッシュおよび再学習されます。
[RFC7041] describes how PBB can be integrated with VPLS to allow for useful PBB capabilities while continuing to avoid the use of MSTP in the backbone. The combined solution, referred to as "PBB-VPLS", results in better scalability in terms of the number of service instances, PWs, and C-MACs that need to be handled in the VPLS PE-rs devices. This document describes extensions to LDP MAC flushing procedures described in [RFC4762] that are required to build desirable capabilities for the PBB-VPLS solution.
[RFC7041]は、PBBをVPLSと統合して、バックボーンでのMSTPの使用を回避しながら、有用なPBB機能を可能にする方法を説明しています。 「PBB-VPLS」と呼ばれる統合ソリューションは、VPLS PE-rsデバイスで処理する必要のあるサービスインスタンス、PW、およびC-MACの数の点でより優れたスケーラビリティをもたらします。このドキュメントでは、PBB-VPLSソリューションの望ましい機能を構築するために必要な、[RFC4762]で説明されているLDP MACフラッシュ手順の拡張について説明します。
The solution proposed in this document is generic and is applicable when Multi-Segment Pseudowires (MS-PWs) [RFC6073] are used in interconnecting PE devices in H-VPLS. There could be other H-VPLS models not defined in this document where the solution may be applicable.
このドキュメントで提案されているソリューションは一般的なものであり、H-VPLSでPEデバイスを相互接続する際にマルチセグメント疑似配線（MS-PW）[RFC6073]が使用されている場合に適用できます。このドキュメントで定義されていない他のH-VPLSモデルが存在し、ソリューションが適用される場合があります。
This section describes the problems in detail with respect to various MAC flushing actions described in Section 3.
このセクションでは、セクション3で説明したさまざまなMACフラッシュアクションに関して問題を詳しく説明します。
This section describes the optimizations required in MAC flushing procedures when H-VPLS resiliency is provided by primary and backup spoke PWs.
このセクションでは、H-VPLSの復元力がプライマリおよびバックアップのスポークPWによって提供される場合のMACフラッシュ手順で必要な最適化について説明します。
Figure 2 shows a dual-homed H-VPLS scenario for a VPLS instance, where the problem with the existing MAC flushing method is as explained in Section 3.
図2は、VPLSインスタンスのデュアルホームH-VPLSシナリオを示しています。既存のMACフラッシュ方法の問題は、セクション3で説明されています。
PE1-rs PE3-rs
+--------+ +--------+
| | | |
| -- | | -- |
Customer Site 1 | / \ |------------------| / \ |->Z
X->CE-1 /-----| \s / | | \s / |
\ primary spoke PW | -- | /------| -- |
\ / +--------+ / +--------+
\ (MTU-s)/ | \ / |
+--------+/ | \ / |
| | | \ / |
| -- | | \ / |
| / \ | | H-VPLS Full-Mesh Core|
| \s / | | / \ |
| -- | | / \ |
/+--------+\ | / \ |
/ backup spoke PW | / \ |
/ \ +--------+ \--------+--------+
Y->CE-2 \ | | | |
Customer Site 2 \------| -- | | -- |
| / \ |------------------| / \ |->
| \s / | | \s / |
| -- | | -- |
+--------+ +--------+
PE2-rs PE4-rs
Figure 2: Dual-Homed MTU-s in Two-Tier Hierarchy H-VPLS
図2：2層階層H-VPLSのデュアルホームMTU-s
In Figure 2, the MTU-s is dual-homed to PE1-rs and PE2-rs. Only the primary spoke PW is active at the MTU-s; thus, PE1-rs is acting as the active device (designated forwarder) to reach the full mesh in the VPLS instance. The MAC addresses of nodes located at access sites (behind CE-1 and CE-2) are learned at PE1-rs over the primary spoke PW. Let's say X represents a set of such MAC addresses located behind CE-1. MAC Z represents one of a possible set of other destination MACs. As packets flow from X to other MACs in the VPLS network, PE2-rs, PE3-rs, and PE4-rs learn about X on their respective mesh PWs terminating at PE1-rs. When the MTU-s switches to the backup spoke PW and activates it, PE2-rs becomes the active device (designated forwarder) to reach the full-mesh core for the MTU-s. Traffic entering the H-VPLS from CE-1 and CE-2 is diverted by the MTU-s to the spoke PW to PE2-rs. Traffic destined from PE2-rs, PE3-rs, and PE4-rs to X will be black-holed until the MAC address aging timer expires (the default is 5 minutes) or a packet flows from X to other addresses through PE2-rs.
図2では、MTU-sはPE1-rsおよびPE2-rsにデュアルホーム接続されています。プライマリスポークPWのみがMTU-sでアクティブです。したがって、PE1-rsは、VPLSインスタンスのフルメッシュに到達するためのアクティブデバイス（指定されたフォワーダー）として機能しています。アクセスサイト（CE-1およびCE-2の背後）にあるノードのMACアドレスは、プライマリスポークPWを介してPE1-rsで学習されます。 XがCE-1の背後にあるそのようなMACアドレスのセットを表すとしましょう。 MAC Zは、他の宛先MACの可能なセットの1つを表します。パケットがXからVPLSネットワーク内の他のMACに流れると、PE2-rs、PE3-rs、およびPE4-rsは、PE1-rsで終了するそれぞれのメッシュPW上のXについて学習します。 MTU-sがバックアップスポークPWに切り替えてアクティブ化すると、PE2-rsがアクティブデバイス（指定されたフォワーダー）になり、MTU-sのフルメッシュコアに到達します。 CE-1およびCE-2からH-VPLSに入るトラフィックは、MTU-sによってスポークPWからPE2-rsに転送されます。 PE2-rs、PE3-rs、およびPE4-rsからXへのトラフィックは、MACアドレスのエージングタイマーが期限切れになるまで（デフォルトは5分）、パケットがXからPE2-rsを介して他のアドレスに流れるまでブラックホール化されます。
For example, if a packet flows from MAC Z to MAC X after the backup spoke PW is active, packets from MAC Z travel from PE3-rs to PE1-rs and are dropped. However, if a packet with MAC X as source and MAC Z as destination arrives at PE2-rs, PE2-rs will now learn that MAC X is on the backup spoke PW and will forward to MAC Z. At this point, traffic from PE3-rs to MAC X will go to PE2-rs, since PE3-rs has also learned about MAC X. Therefore, a mechanism is required to make this learning more timely in cases where traffic is not bidirectional.
たとえば、バックアップスポークPWがアクティブになった後にパケットがMAC ZからMAC Xに流れる場合、MAC ZからのパケットはPE3-rsからPE1-rsに移動してドロップされます。ただし、送信元がMAC X、宛先がMAC ZのパケットがPE2-rsに到着すると、PE2-rsはMAC XがバックアップスポークPWにあることを認識し、MAC Zに転送します。この時点で、PE3からのトラフィックPE3-rsもMAC Xについて学習したため、-rs to MAC XはPE2-rsに移動します。したがって、トラフィックが双方向でない場合に、この学習をよりタイムリーに行うためのメカニズムが必要です。
To avoid traffic black-holing, the MAC addresses that have been learned in the upstream VPLS full mesh through PE1-rs must be relearned or removed from the MAC Forwarding Information Bases (FIBs) in the VSIs at PE2-rs, PE3-rs, and PE4-rs. If PE1-rs and PE2-rs are dual-homing agnostic, then on activation of the standby PW from the MTU-s, a MAC flush message will be sent by the MTU-s to PE2-rs that will flush all the MAC addresses learned in the VPLS instance at PE2-rs from all other PWs except the PW connected to the MTU-s.
トラフィックのブラックホールを回避するには、PE1-rsを介してアップストリームVPLSフルメッシュで学習されたMACアドレスを再学習するか、PE2-rs、PE3-rs、VSIのMAC転送情報ベース（FIB）から削除する必要があります。およびPE4-rs。 PE1-rsおよびPE2-rsがデュアルホーミングに依存しない場合、MTU-sからのスタンバイPWのアクティブ化時に、MACフラッシュメッセージがMTU-sからPE2-rsに送信され、すべてのMACアドレスをフラッシュします。 MTU-sに接続されているPWを除く他のすべてのPWからPE2-rsのVPLSインスタンスで学習されます。
PE2-rs further relays the MAC flush messages to all other PE-rs devices in the full mesh. The same processing rule applies for all those PE-rs devices: all the MAC addresses are flushed except the ones learned on the PW connected to PE2-rs. For example, at PE3-rs all of the MAC addresses learned from the PWs connected to PE1-rs and PE4-rs are flushed and relearned subsequently. Before the relearning happens, flooding of unknown destination MAC addresses takes place throughout the network. As the number of PE-rs devices in the full mesh increases, the number of unaffected MAC addresses flushed in a VPLS instance also increases, thus leading to unnecessary flooding and relearning. With a large number of VPLS instances provisioned in the H-VPLS network topology, the amount of unnecessary flooding and relearning increases. An optimization, described below, is required that will flush only the MAC addresses learned from the respective PWs between PE1-rs and other PE devices in the full mesh, to minimize the relearning and flooding in the network. In the example above, only the MAC addresses in sets X and Y (shown in Figure 2) need to be flushed across the core.
PE2-rsはさらに、MACフラッシュメッセージをフルメッシュ内の他のすべてのPE-rsデバイスにリレーします。同じ処理ルールがそれらすべてのPE-rsデバイスに適用されます。PE2-rsに接続されたPWで学習されたものを除いて、すべてのMACアドレスがフラッシュされます。たとえば、PE3-rsでは、PE1-rsおよびPE4-rsに接続されたPWから学習したすべてのMACアドレスがフラッシュされ、その後再学習されます。再学習が発生する前に、不明な宛先MACアドレスのフラッディングがネットワーク全体で発生します。フルメッシュ内のPE-rsデバイスの数が増えると、VPLSインスタンスでフラッシュされる影響を受けないMACアドレスの数も増えるため、不要なフラッディングと再学習が発生します。 H-VPLSネットワークトポロジで多数のVPLSインスタンスがプロビジョニングされると、不必要なフラッディングと再学習の量が増加します。以下で説明する最適化は、ネットワーク内の再学習とフラッディングを最小限に抑えるために、フルメッシュのPE1-rsと他のPEデバイス間のそれぞれのPWから学習したMACアドレスのみをフラッシュする必要があります。上記の例では、XとYのセット（図2に示す）のMACアドレスのみをコア全体にフラッシュする必要があります。
The same case is applicable when PE1-rs and PE2-rs are dual-homing aware and participate in a designated forwarder election. When PE2-rs becomes the active device for the MTU-s, then PE2-rs MAY initiate MAC flushing towards the core. The receiving action of the MAC flush message in other PE-rs devices is the same as in MAC flushing initiated by the MTU-s. This is the behavior specified in [RFC4762].
PE1-rsおよびPE2-rsがデュアルホーミング対応であり、指定されたフォワーダー選挙に参加している場合も、同じケースが当てはまります。 PE2-rsがMTU-sのアクティブデバイスになると、PE2-rsはコアへのMACフラッシュを開始できます（MAY）。他のPE-rsデバイスでのMACフラッシュメッセージの受信アクションは、MTU-sによって開始されたMACフラッシュと同じです。これは、[RFC4762]で指定されている動作です。
The analysis in Section 4.1.1 applies also to the native Ethernet access into a VPLS. In such a scenario, one active endpoint and one or more standby endpoints terminate into two or more VPLS or H-VPLS PE-rs devices. Examples of this dual-homed access are ITU-T [ITU.G8032] access rings or any proprietary multi-chassis Link Aggregation Group (LAG) emulations. Upon failure of the active native Ethernet endpoint on PE1-rs, an optimized MAC flush message is required to be initiated by PE1-rs to ensure that on PE2-rs, PE3-rs, and PE4-rs only the MAC addresses learned from the respective PWs connected to PE1-rs are being flushed.
セクション4.1.1の分析は、VPLSへのネイティブイーサネットアクセスにも適用されます。このようなシナリオでは、1つのアクティブエンドポイントと1つ以上のスタンバイエンドポイントが2つ以上のVPLSまたはH-VPLS PE-rsデバイスで終端します。このデュアルホームアクセスの例は、ITU-T [ITU.G8032]アクセスリングまたは独自のマルチシャーシリンク集約グループ（LAG）エミュレーションです。 PE1-rsでアクティブなネイティブイーサネットエンドポイントに障害が発生した場合、PE2-rs、PE3-rs、およびPE4-rsでは、PE1-rsから学習したMACアドレスのみを確実にするために、最適化されたMACフラッシュメッセージをPE1-rsで開始する必要があります。 PE1-rsに接続されているそれぞれのPWがフラッシュされています。
In a PBB-VPLS deployment, a B-component VPLS (B-VPLS) may be used as infrastructure to support one or more I-component instances. The B-VPLS control plane (LDP Signaling) and learning of Backbone MACs (B-MACs) replace the I-component control plane and learning of Customer MACs (C-MACs) throughout the MPLS core. This raises an additional challenge related to black-hole avoidance in the I-component domain as described in this section. Figure 3 describes the case of a Customer Edge (CE) device (node A) dual-homed to two I-component instances located on two PBB-VPLS PEs (PE1-rs and PE2-rs).
PBB-VPLS展開では、BコンポーネントVPLS（B-VPLS）をインフラストラクチャとして使用して、1つ以上のIコンポーネントインスタンスをサポートできます。 B-VPLSコントロールプレーン（LDPシグナリング）とバックボーンMAC（B-MAC）の学習は、MPLSコア全体のIコンポーネントコントロールプレーンとカスタマーMAC（C-MAC）の学習を置き換えます。これにより、このセクションで説明するように、Iコンポーネントドメインでのブラックホール回避に関連する追加の課題が発生します。図3は、2つのPBB-VPLS PE（PE1-rsおよびPE2-rs）にある2つのIコンポーネントインスタンスにデュアルホーム接続されたカスタマーエッジ（CE）デバイス（ノードA）のケースを示しています。
IP/MPLS Core
+--------------+
|PE2-rs |
+----+ |
|PBB | |
|VPLS| +-+ |
|(B2)|---|P| |
Stby/+----+ /+-+\ |PE3-rs
/ +----+ / \+----+
+---+/ |PBB |/ +-+ |PBB | +---+
C-MAC X--|CE |---|VPLS|---|P|--|VPLS|---|CE |--C-MAC Y
| |Act|(B1)| +-+ | | | |
+---+ +----+ +----+ +---+
A |PE1-rs | B
| |
+--------------+
Figure 3: PBB Black-Holing Issue - CE Dual-Homing Use Case
図3：PBBブラックホーリングの問題-CEデュアルホーミングの使用例
The link between PE1-rs and CE-A is active (marked with A), while the link between CE-A and PE2-rs is in standby/blocked status. In the network diagram, C-MAC X is one of the MAC addresses located behind CE-A in the customer domain, C-MAC Y is behind CE-B, and the B-VPLS instances on PE1-rs are associated with B-MAC B1 and PE2-rs with B-MAC B2.
PE1-rsとCE-Aの間のリンクはアクティブであり（Aとマークされています）、CE-AとPE2-rsの間のリンクはスタンバイ/ブロックステータスです。ネットワークダイアグラムでは、C-MAC XはカスタマードメインのCE-Aの背後にあるMACアドレスの1つであり、C-MAC YはCE-Bの背後にあり、PE1-rsのB-VPLSインスタンスはB- B-MAC B2を備えたMAC B1およびPE2-rs。
As the packets flow from C-MAC X to C-MAC Y through PE1-rs with B-MAC B1, the remote PE-rs devices participating in the B-VPLS with the same I-SID (for example, PE3-rs) will learn the C-MAC X associated with B-MAC B1 on PE1-rs. Under a failure condition of the link between CE-A and PE1-rs and on activation of the link to PE2-rs, the remote PE-rs devices (for example, PE3-rs) will forward the traffic destined for C-MAC X to B-MAC B1, resulting in PE1-rs black-holing that traffic until the aging timer expires or a packet flows from X to Y through PE2-rs (B-MAC B2). This may take a long time (the default aging timer is 5 minutes) and may affect a large number of flows across multiple I-components.
パケットは、B-MAC B1のPE1-rsを介してC-MAC XからC-MAC Yに流れるため、同じI-SIDを持つB-VPLSに参加しているリモートPE-rsデバイス（たとえば、PE3-rs） PE1-rsのB-MAC B1に関連付けられたC-MAC Xを学習します。 CE-AとPE1-rsの間のリンクに障害が発生し、PE2-rsへのリンクがアクティブになると、リモートPE-rsデバイス（たとえば、PE3-rs）はC-MAC X宛てのトラフィックを転送しますエージングタイマーが期限切れになるか、パケットがXからYにPE2-rs（B-MAC B2）を通過するまで、トラフィックをB1-MAC B1にブラックホール化します。これには長い時間がかかり（デフォルトのエージングタイマーは5分です）、複数のIコンポーネントにまたがる多数のフローに影響を与える可能性があります。
A possible solution to this issue is to use the existing LDP MAC flushing method as specified in [RFC4762] to flush the B-MAC associated with the PE-rs in the B-VPLS domain where the failure occurred. This will automatically flush the C-MAC-to-B-MAC association in the remote PE-rs devices. This solution has the disadvantage of producing a lot of unnecessary MAC flushing in the B-VPLS domain as there was no failure or topology change affecting the Backbone domain.
この問題の可能な解決策は、[RFC4762]で指定されている既存のLDP MACフラッシュ方法を使用して、障害が発生したB-VPLSドメインのPE-rsに関連付けられているB-MACをフラッシュすることです。これにより、リモートPE-rsデバイスのC-MACからB-MACへの関連付けが自動的にフラッシュされます。このソリューションには、バックボーンドメインに影響を与える障害やトポロジの変更がないため、B-VPLSドメインで不要なMACフラッシュが大量に発生するという欠点があります。
A better solution -- one that would propagate the I-component events through the backbone infrastructure (B-VPLS) -- is required in order to flush only the C-MAC-to-B-MAC associations in the remote PBB-VPLS-capable PE-rs devices. Since there are no I-component control-plane exchanges across the PBB backbone, extensions to the B-VPLS control plane are required to propagate the I-component MAC flushing events across the B-VPLS.
リモートPBB-VPLSのC-MAC-to-B-MACアソシエーションのみをフラッシュするには、より良いソリューション（バックボーンインフラストラクチャ（B-VPLS）を介してIコンポーネントイベントを伝播するソリューション）が必要です。対応するPE-rsデバイス。 PBBバックボーン全体でIコンポーネントコントロールプレーン交換がないため、B-VPLS全体でIコンポーネントMACフラッシュイベントを伝播するには、B-VPLSコントロールプレーンの拡張が必要です。
This section describes the solution for the problem space described in Section 4.
このセクションでは、セクション4で説明した問題空間のソリューションについて説明します。
The basic principle of the optimized MAC flush mechanism is explained with reference to Figure 2. The optimization is achieved by initiating MAC flushing on failure as described in Section 3.2.
図2を参照して、最適化されたMACフラッシュメカニズムの基本原理を説明します。最適化は、セクション3.2で説明されているように、障害時にMACフラッシュを開始することによって実現されます。
PE1-rs would initiate MAC flushing towards the core on detection of failure of the primary spoke PW between the MTU-s and PE1-rs (or status change from active to standby [RFC6718]). This method is referred to as "MAC flushing on failure" throughout this document.
PE1-rsは、MTU-sとPE1-rs間のプライマリスポークPWの障害（またはアクティブからスタンバイへのステータス変更[RFC6718]）を検出すると、コアに向かってMACフラッシュを開始します。この方法は、このドキュメント全体で「障害時のMACフラッシュ」と呼ばれています。
The MAC flush message would indicate to receiving PE-rs devices to flush all MACs learned over the PW in the context of the VPLS for which the MAC flush message is received. Each PE-rs device in the full mesh that receives the message identifies the VPLS instance and its respective PW that terminates in PE1-rs from the FEC TLV received in the message and/or LDP session. Thus, the PE-rs device flushes only the MAC addresses learned from that PW connected to PE1-rs, minimizing the required relearning and the flooding throughout the VPLS domain.
MACフラッシュメッセージは、MACフラッシュメッセージが受信されたVPLSのコンテキストでPWを介して学習されたすべてのMACをフラッシュするように、受信PE-rsデバイスに指示します。メッセージを受信するフルメッシュ内の各PE-rsデバイスは、VPLSインスタンスと、メッセージまたはLDPセッションで受信されたFEC TLVからPE1-rsで終了するそれぞれのPWを識別します。したがって、PE-rsデバイスは、PE1-rsに接続されたPWから学習したMACアドレスのみをフラッシュし、VPLSドメイン全体で必要な再学習とフラッディングを最小限に抑えます。
This section defines a generic MAC Flush Parameters TLV for LDP [RFC5036]. Throughout this document, the MAC Flush Parameters TLV is also referred to as the "MAC Flush TLV". A MAC Flush TLV carries information on the desired action at the PE-rs device receiving the message and is used for optimized MAC flushing in VPLS. The MAC Flush TLV can also be used for the [RFC4762] style of MAC flushing as explained in Section 3.
このセクションでは、LDP [RFC5036]の一般的なMACフラッシュパラメータTLVを定義します。このドキュメント全体を通して、MACフラッシュパラメータTLVは「MACフラッシュTLV」とも呼ばれます。 MACフラッシュTLVは、メッセージを受信するPE-rsデバイスでの必要なアクションに関する情報を伝達し、VPLSでの最適化されたMACフラッシュに使用されます。 MACフラッシュTLVは、セクション3で説明するように、[RFC4762]スタイルのMACフラッシュにも使用できます。
The MAC Flush Parameters TLV is described below:
MACフラッシュパラメータTLVは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| MAC Flush TLV (0x0406) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Sub-TLV Type | Sub-TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLV Variable-Length Value |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The U-bit and F-bit [RFC5036] are set to forward if unknown so that potential intermediate VPLS PE-rs devices unaware of the new TLV can just propagate it transparently. In the case of a B-VPLS network that has PBB-VPLS in the core with no I-components attached, this message can still be useful to edge B-VPLS devices that do have the I-components with the I-SIDs and understand the message. The MAC Flush Parameters TLV type is 0x0406, as assigned by IANA. The encoding of the TLV follows the standard LDP TLV encoding described in [RFC5036].
UビットとFビット[RFC5036]は、未知の場合は転送するように設定されているため、新しいTLVを認識しない潜在的な中間VPLS PE-rsデバイスは、それを透過的に伝達することができます。コアにPBB-VPLSがあり、Iコンポーネントが接続されていないB-VPLSネットワークの場合、このメッセージは、IコンポーネントがI-SIDを持ち、理解しているエッジB-VPLSデバイスに役立ちます。メッセージ。 MACフラッシュパラメータのTLVタイプは0x0406で、IANAによって割り当てられています。 TLVのエンコーディングは、[RFC5036]で説明されている標準のLDP TLVエンコーディングに従います。
The TLV value field contains a 1-byte Flag field used as described below. Further, the TLV value MAY carry one or more sub-TLVs. Any sub-TLV definition for the above TLV MUST address the actions in combination with other existing sub-TLVs.
TLV値フィールドには、以下で説明するように使用される1バイトのフラグフィールドが含まれています。さらに、TLV値は1つ以上のサブTLVを運ぶことができます。上記のTLVのサブTLV定義は、他の既存のサブTLVと組み合わせてアクションに対処する必要があります。
The detailed format for the Flags bit vector is described below:
フラグビットベクトルの詳細な形式を以下に示します。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|N| MBZ | (MBZ = MUST Be Zero)
+-+-+-+-+-+-+-+-+
The 1-byte Flag field is mandatory. The following flags are defined:
1バイトのフラグフィールドは必須です。次のフラグが定義されています。
C-flag: Used to indicate the context of the PBB-VPLS component in which MAC flushing is required. For PBB-VPLS, there are two contexts of MAC flushing -- the Backbone VPLS (B-component VPLS) and the Customer VPLS (I-component VPLS). The C-flag MUST be ZERO (C = 0) when a MAC flush action for the B-VPLS is required and MUST be set (C = 1) when the MAC flush action for the I-component is required. In the regular H-VPLS case, the C-flag MUST be ZERO (C = 0) to indicate that the flush applies to the current VPLS context.
Cフラグ：MACフラッシュが必要なPBB-VPLSコンポーネントのコンテキストを示すために使用されます。 PBB-VPLSの場合、MACフラッシュには、バックボーンVPLS（BコンポーネントVPLS）とカスタマーVPLS（IコンポーネントVPLS）の2つのコンテキストがあります。 Cフラグは、B-VPLSのMACフラッシュアクションが必要な場合はゼロ（C = 0）である必要があり、IコンポーネントのMACフラッシュアクションが必要な場合は設定（C = 1）する必要があります。通常のH-VPLSの場合、フラッシュが現在のVPLSコンテキストに適用されることを示すために、Cフラグはゼロ（C = 0）でなければなりません。
N-flag: Used to indicate whether a positive (N = 0, flush-all-but-mine) or negative (N = 1, flush-all-from-me) MAC flush action is required. The source (mine/me) is defined as the PW associated with either the LDP session on which the LDP MAC withdraw was received or the B-MAC(s) listed in the B-MAC Sub-TLV. For the optimized MAC flush procedure described in this section, the flag MUST be set (N = 1).
Nフラグ：正（N = 0、すべてをフラッシュする）または負（N = 1、すべてフラッシュする）のMACフラッシュアクションが必要かどうかを示すために使用されます。ソース（mine / me）は、LDP MAC撤回が受信されたLDPセッション、またはB-MAC Sub-TLVにリストされているB-MACに関連付けられたPWとして定義されます。このセクションで説明する最適化されたMACフラッシュ手順では、フラグを設定する必要があります（N = 1）。
Detailed usage in the context of PBB-VPLS is explained in Section 5.2.
PBB-VPLSのコンテキストでの詳細な使用法は、セクション5.2で説明されています。
MBZ flags: The rest of the flags SHOULD be set to zero on transmission and ignored on reception.
MBZフラグ：残りのフラグは、送信時にゼロに設定し、受信時に無視する必要があります（SHOULD）。
The MAC Flush TLV SHOULD be placed after the existing TLVs in the [RFC4762] MAC flush message.
MACフラッシュTLVは、[RFC4762] MACフラッシュメッセージの既存のTLVの後に配置する必要があります。
When optimized MAC flushing is supported, the MAC Flush TLV MUST be sent in an existing LDP address withdraw message with an empty MAC list but from the core PE-rs on detection of failure of its local/primary spoke PW. The N-bit in the TLV MUST be set to 1 to indicate flush-all-from-me. If the optimized MAC flush procedure is used in a Backbone VPLS or regular VPLS/H-VPLS context, the C-bit MUST be ZERO (C = 0). If it is used in an I-component context, the C-bit MUST be set (C = 1). See Section 5.2 for details of its usage in the context of PBB-VPLS.
最適化されたMACフラッシュがサポートされている場合、MACフラッシュTLVは、空のMACリストを持つ既存のLDPアドレスウィズドローメッセージで送信する必要がありますが、ローカル/プライマリスポークPWの障害の検出時にコアPE-rsから送信する必要があります。 flush-all-from-meを示すには、TLVのNビットを1に設定する必要があります。最適化されたMACフラッシュ手順がバックボーンVPLSまたは通常のVPLS / H-VPLSコンテキストで使用される場合、Cビットはゼロ（C = 0）でなければなりません。 Iコンポーネントのコンテキストで使用する場合は、Cビットを設定する必要があります（C = 1）。 PBB-VPLSのコンテキストでの使用法の詳細については、セクション5.2を参照してください。
Note that the assumption is that the MAC Flush TLV is understood by all devices before it is turned on in any network. See Section 6 ("Operational Considerations").
MACフラッシュTLVは、ネットワークでオンになる前にすべてのデバイスによって認識されることが前提となっていることに注意してください。セクション6（「運用上の考慮事項」）を参照してください。
When optimized MAC flushing is not supported, the MAC withdraw procedures defined in [RFC4762], where either the MTU-s or PE2-rs sends the MAC withdraw message, SHOULD be used. This includes the case where the network is being changed to support optimized MAC flushing but not all devices are capable of understanding optimized MAC flush messages.
最適化されたMACフラッシュがサポートされていない場合、[RFC4762]で定義されているMAC撤回手順では、MTU-sまたはPE2-rsがMAC撤退メッセージを送信するため、SHOULDを使用する必要があります。これには、最適化されたMACフラッシュをサポートするようにネットワークが変更されているが、すべてのデバイスが最適化されたMACフラッシュメッセージを理解できるわけではない場合が含まれます。
In the case of B-VPLS devices, the optimized MAC flush message SHOULD be supported.
B-VPLSデバイスの場合、最適化されたMACフラッシュメッセージをサポートする必要があります（SHOULD）。
This section describes the processing rules of the MAC Flush TLV that MUST be followed in the context of optimized MAC flush procedures in VPLS.
このセクションでは、VPLSの最適化されたMACフラッシュ手順のコンテキストで従う必要があるMACフラッシュTLVの処理ルールについて説明します。
When optimized MAC flushing is supported, a multi-homing PE-rs initiates a MAC flush message towards the other related VPLS PE-rs devices when it detects a transition (failure or a change to standby) in its active spoke PW. In such a case the MAC Flush TLV MUST be sent with N = 1. A PE-rs device receiving the MAC Flush TLV SHOULD follow the same processing rules as those described in this section.
最適化されたMACフラッシュがサポートされている場合、マルチホーミングPE-rsは、アクティブなスポークPWで遷移（障害またはスタンバイへの変更）を検出すると、他の関連するVPLS PE-rsデバイスに向けてMACフラッシュメッセージを開始します。そのような場合、MACフラッシュTLVはN = 1で送信する必要があります。MACフラッシュTLVを受信するPE-rsデバイスは、このセクションで説明されているものと同じ処理ルールに従う必要があります。
Note that if a Multi-Segment Pseudowire (MS-PW) is used in VPLS, then a MAC flush message is processed only at the PW Terminating Provider Edge (T-PE) nodes, since PW Switching Provider Edge S-PE(s) traversed by the MS-PW propagates the MAC flush messages without any action. In this section, a PE-rs device signifies only a T-PE in the MS-PW case.
VPLSでマルチセグメント疑似配線（MS-PW）が使用されている場合、PWスイッチングプロバイダーエッジS-PEのため、MACフラッシュメッセージはPWターミネーションプロバイダーエッジ（T-PE）ノードでのみ処理されます。 MS-PWが通過したMACフラッシュメッセージは、何のアクションもなしに伝播します。このセクションでは、PE-rsデバイスはMS-PWの場合のT-PEのみを示します。
When a PE-rs device receives a MAC Flush TLV with N = 1, it SHOULD flush all the MAC addresses learned from the PW in the VPLS in the context on which the MAC flush message is received. It is assumed that when these procedures are used all nodes support the MAC flush message. See Section 6 ("Operational Considerations") for details.
PE-rsデバイスがN = 1のMACフラッシュTLVを受信すると、MACフラッシュメッセージが受信されたコンテキストで、VPLSのPWから学習したすべてのMACアドレスをフラッシュする必要があります（SHOULD）。これらの手順が使用される場合、すべてのノードがMACフラッシュメッセージをサポートすると想定されています。詳細については、セクション6（「運用上の考慮事項」）を参照してください。
When optimized MAC flushing is not supported, a MAC Flush TLV is received with N = 0 in the MAC flush message; in such a case, the receiving PE-rs SHOULD flush the MAC addresses learned from all PWs in the VPLS instance, except the ones learned over the PW on which the message is received.
最適化されたMACフラッシュがサポートされていない場合、MACフラッシュメッセージでN = 0のMACフラッシュTLVが受信されます。このような場合、受信PE-rsは、メッセージが受信されるPWで学習されたものを除いて、VPLSインスタンスのすべてのPWから学習されたMACアドレスをフラッシュする必要があります（SHOULD）。
Regardless of whether optimized MAC flushing is supported, if a PE-rs device receives a MAC flush message with a MAC Flush TLV option (N = 0 or N = 1) and a valid MAC address list, it SHOULD ignore the option and deal with MAC addresses explicitly as per [RFC4762].
最適化されたMACフラッシュがサポートされているかどうかに関係なく、PE-rsデバイスがMACフラッシュTLVオプション（N = 0またはN = 1）と有効なMACアドレスリストを含むMACフラッシュメッセージを受信した場合、オプションを無視して対処する必要があります（SHOULD）。 [RFC4762]による明示的なMACアドレス。
This section expands on the optimized MAC flush procedure in the scenario shown in Figure 2.
このセクションでは、図2に示すシナリオの最適化されたMACフラッシュ手順について詳しく説明します。
When optimized MAC flushing is being used, a PE-rs that is dual-homing aware SHOULD send MAC address messages with a MAC Flush TLV and N = 1, provided the other PEs understand the new messages. Upon receipt of the MAC flush message, PE2-rs identifies the VPLS instance that requires MAC flushing from the FEC element in the FEC TLV. On receiving N = 1, PE2-rs removes all MAC addresses learned from that PW over which the message is received. The same action is performed by PE3-rs and PE4-rs.
最適化されたMACフラッシュが使用されている場合、他のPEが新しいメッセージを理解していれば、デュアルホーミング対応のPE-rsはMACフラッシュTLVおよびN = 1でMACアドレスメッセージを送信する必要があります。 MACフラッシュメッセージを受信すると、PE2-rsは、FEC TLVのFEC要素からのMACフラッシュを必要とするVPLSインスタンスを識別します。 N = 1を受信すると、PE2-rsは、メッセージが受信されたPWから学習したすべてのMACアドレスを削除します。同じアクションがPE3-rsとPE4-rsによって実行されます。
Figure 4 shows another redundant H-VPLS topology to protect against failure of the MTU-s device. In this case, since there is more than a single MTU-S, a protocol such as provider RSTP [IEEE.802.1Q-2011] may be used as the selection algorithm for active and backup PWs in order to maintain the connectivity between MTU-s devices and PE-rs devices at the edge. It is assumed that PE-rs devices can detect failure on PWs in either direction through OAM mechanisms (for instance, Virtual Circuit Connectivity Verification (VCCV) procedures).
図4は、MTU-sデバイスの障害から保護するための別の冗長H-VPLSトポロジを示しています。この場合、複数のMTU-Sがあるため、MTU-S間の接続を維持するために、プロバイダーRSTP [IEEE.802.1Q-2011]などのプロトコルをアクティブおよびバックアップPWの選択アルゴリズムとして使用できます。エッジのデバイスとPE-rsデバイス。 PE-rsデバイスは、OAMメカニズム（たとえば、Virtual Circuit Connectivity Verification（VCCV）手順）を介して、いずれかの方向のPW上の障害を検出できると想定されています。
MTU-1================PE1-rs==============PE3-rs
|| || \ /||
|| Redundancy || \ / ||
|| Provider RSTP || Full Mesh . ||
|| || / \ ||
|| || / \||
MTU-2----------------PE2-rs==============PE4-rs
Backup PW
Figure 4: Redundancy with Provider RSTP
図4：プロバイダーRSTPによる冗長性
MTU-1, MTU-2, PE1-rs, and PE2-rs participate in provider RSTP. Configuration using RSTP ensures that the PW between MTU-1 and PE1-rs is active and the PW between MTU-2 and PE2-rs is blocked (made backup) at the MTU-2 end. When the active PW failure is detected by RSTP, it activates the PW between MTU-2 and PE2-rs. When PE1-rs detects the failing PW to MTU-1, it MAY trigger MAC flushing into the full mesh with a MAC Flush TLV that carries N = 1. Other PE-rs devices in the full mesh that receive the MAC flush message identify their respective PWs terminating on PE1-rs and flush all the MAC addresses learned from it.
MTU-1、MTU-2、PE1-rs、およびPE2-rsはプロバイダーRSTPに参加します。 RSTPを使用した構成により、MTU-1とPE1-rs間のPWがアクティブになり、MTU-2とPE2-rs間のPWがMTU-2側でブロック（バックアップ）されます。 RSTPによってアクティブなPW障害が検出されると、MTU-2とPE2-rs間のPWがアクティブになります。 PE1-rsがMTU-1への障害のあるPWを検出すると、N = 1を伝送するMACフラッシュTLVでフルメッシュへのMACフラッシュをトリガーできます（MAY）。MACフラッシュメッセージを受信するフルメッシュ内の他のPE-rsデバイスは、 PE1-rsで終了し、そこから学習したすべてのMACアドレスをフラッシュするそれぞれのPW
[RFC4762] describes a multi-domain VPLS service where fully meshed VPLS networks (domains) are connected together by a single spoke PW per VPLS service between the VPLS "border" PE-rs devices. To provide redundancy against failure of the inter-domain spoke, full mesh of inter-domain spokes can be set up between border PE-rs devices, and provider RSTP may be used for selection of the active inter-domain spoke. In the case of inter-domain spoke PW failure, MAC withdrawal initiated by PE-rs MAY be used for optimized MAC flush procedures within individual domains.
[RFC4762]は、完全にメッシュ化されたVPLSネットワーク（ドメイン）が、VPLS "境界" PE-rsデバイス間のVPLSサービスごとに単一のスポークPWによって接続されているマルチドメインVPLSサービスについて説明しています。ドメイン間スポークの障害に対する冗長性を提供するために、ボーダーPE-rsデバイス間にドメイン間スポークのフルメッシュをセットアップでき、プロバイダーRSTPを使用してアクティブなドメイン間スポークを選択できます。ドメイン間スポークPW障害の場合、PE-rsによって開始されたMACの引き出しは、個々のドメイン内の最適化されたMACフラッシュ手順に使用される場合があります。
Further, the procedures are applicable to any native Ethernet access topologies multi-homed to two or more VPLS PE-rs devices. The text in this section applies for the native Ethernet case where active/standby PWs are replaced with the active/standby Ethernet endpoints. An optimized MAC flush message can be generated by the VPLS PE-rs that detects the failure in the primary Ethernet access.
さらに、この手順は、2つ以上のVPLS PE-rsデバイスにマルチホームされたネイティブイーサネットアクセストポロジに適用できます。このセクションのテキストは、アクティブ/スタンバイPWがアクティブ/スタンバイイーサネットエンドポイントで置き換えられるネイティブイーサネットの場合に適用されます。最適化されたMACフラッシュメッセージは、プライマリイーサネットアクセスの障害を検出するVPLS PE-rsによって生成できます。
The use of an address withdraw message with a MAC List TLV is proposed in [RFC4762] as a way to expedite removal of MAC addresses as the result of a topology change (e.g., failure of a primary link of a VPLS PE-rs device and, implicitly, the activation of an alternate link in a dual-homing use case). These existing procedures apply individually to B-VPLS and I-component domains.
[RFC4762]では、トポロジーの変更（たとえば、VPLS PE-rsデバイスのプライマリリンクの障害、および、暗黙的に、デュアルホーミングユースケースでの代替リンクのアクティブ化）。これらの既存の手順は、B-VPLSおよびIコンポーネントドメインに個別に適用されます。
When it comes to reflecting topology changes in access networks connected to I-components across the B-VPLS domain, certain additions should be considered, as described below.
B-VPLSドメイン全体のIコンポーネントに接続されたアクセスネットワークのトポロジ変更を反映することになると、以下に説明するように、特定の追加を考慮する必要があります。
MAC switching in PBB is based on the mapping of Customer MACs (C-MACs) to one or more Backbone MACs (B-MACs). A topology change in the access (I-component domain) should just invoke the flushing of C-MAC entries in the PBB PEs' FIB(s) associated with the I-component(s) impacted by the failure. There is a need to indicate the PBB PE (B-MAC source) that originated the MAC flush message to selectively flush only the MACs that are affected.
PBBでのMACスイッチングは、1つ以上のバックボーンMAC（B-MAC）へのカスタマーMAC（C-MAC）のマッピングに基づいています。アクセスのトポロジ変更（Iコンポーネントドメイン）は、障害の影響を受けるIコンポーネントに関連付けられているPBB PEのFIBのC-MACエントリのフラッシュを呼び出すだけです。影響を受けるMACのみを選択的にフラッシュするには、MACフラッシュメッセージを発信したPBB PE（B-MACソース）を示す必要があります。
These goals can be achieved by including the MAC Flush Parameters TLV in the LDP address withdraw message to indicate the particular domain(s) requiring MAC flushing. On the other end, the receiving PEs SHOULD use the information from the new TLV to flush only the related FIB entry/entries in the I-component instance(s).
これらの目標は、MACフラッシュを必要とする特定のドメインを示すために、LDPアドレスウィズドロウメッセージにMACフラッシュパラメータTLVを含めることで達成できます。一方、受信側のPEは、新しいTLVからの情報を使用して、Iコンポーネントインスタンスの関連するFIBエントリのみをフラッシュする必要があります（SHOULD）。
At least one of the following sub-TLVs MUST be included in the MAC Flush Parameters TLV if the C-flag is set to 1:
Cフラグが1に設定されている場合、次のサブTLVの少なくとも1つをMACフラッシュパラメータTLVに含める必要があります。
o PBB B-MAC List Sub-TLV:
o PBB B-MACリストサブTLV：
Type: 0x0407
タイプ：0x0407
Length: Value length in octets. At least one B-MAC address MUST be present in the list.
長さ：オクテット単位の値の長さ。少なくとも1つのB-MACアドレスがリストに存在している必要があります。
Value: One or a list of 48-bit B-MAC addresses. These are the source B-MAC addresses associated with the B-VPLS instance that originated the MAC withdraw message. It will be used to identify the C-MAC(s) mapped to the B-MAC(s) listed in the sub-TLV.
値：48ビットのB-MACアドレスの1つまたはリスト。これらは、MAC取り消しメッセージを発信したB-VPLSインスタンスに関連付けられたソースB-MACアドレスです。これは、サブTLVにリストされているB-MACにマップされているC-MACを識別するために使用されます。
o PBB I-SID List Sub-TLV:
o PBB I-SIDリストサブTLV：
Type: 0x0408
タイプ：0x0408
Length: Value length in octets. Zero indicates an empty I-SID list. An empty I-SID list means that the flushing applies to all the I-SIDs mapped to the B-VPLS indicated by the FEC TLV.
長さ：オクテット単位の値の長さ。ゼロは空のI-SIDリストを示します。空のI-SIDリストは、フラッシュがFEC TLVによって示されるB-VPLSにマップされたすべてのI-SIDに適用されることを意味します。
Value: One or a list of 24-bit I-SIDs that represent the I-component FIB(s) where the MAC flushing needs to take place.
値：MACフラッシュを実行する必要があるIコンポーネントFIBを表す24ビットI-SIDの1つまたはリスト。
The following steps describe the details of the processing rules for the MAC Flush TLV in the context of PBB-VPLS. In general, these procedures are similar to the VPLS case but are tailored to PBB, which may have a large number of MAC addresses. In PBB, there are two sets of MAC addresses: Backbone (outer) MACs (B-MACs) and Customer (inner) MACs (C-MACs). C-MACs are associated to remote B-MACs by learning. There are also I-SIDs in PBB; I-SIDs are similar to VLANs for the purposes of the discussion in this section. In order to achieve behavior that is similar to the Regular VPLS case, there are some differences in the interpretation of the optimized MAC flush message.
次の手順では、PBB-VPLSのコンテキストでのMACフラッシュTLVの処理ルールの詳細について説明します。一般に、これらの手順はVPLSの場合と似ていますが、MACアドレスの数が多いPBBに合わせて調整されています。 PBBには、バックボーン（外部）MAC（B-MAC）とカスタマー（内部）MAC（C-MAC）の2セットのMACアドレスがあります。 C-MACは、学習によってリモートB-MACに関連付けられます。 PBBにはI-SIDもあります。 I-SIDは、このセクションでの説明の目的ではVLANに似ています。通常のVPLSの場合と同様の動作を実現するために、最適化されたMACフラッシュメッセージの解釈にはいくつかの違いがあります。
1. Positive flush of C-MACs. This is equivalent to [RFC4762] MAC flushing in a PBB context. In this case, the N-bit is set to 0; the C-bit is set to 1, and C-MACs are to be flushed. However, since C-MACs are related to B-MACs in an I-SID context, further refinement of the flushing scope is possible.
1. C-MACの確実なフラッシュ。これは、PBBコンテキストでの[RFC4762] MACフラッシュと同等です。この場合、Nビットは0に設定されます。 Cビットは1に設定され、C-MACはフラッシュされます。ただし、C-MACはI-SIDコンテキストのB-MACに関連しているため、フラッシングスコープをさらに絞り込むことができます。
- If an I-SID needs to be flushed (all C-MACs within that I-SID), then I-SIDs are listed in the appropriate TLV. If all I-SIDs are to have the C-MACs flushed, then the I-SID TLV can be empty. It is typical to flush a single I-SID only, since each I-SID is associated with one or more interfaces (typically one, in the case of dual-homing). In the PBB case, flushing the I-SID is equivalent to the empty MAC list discussed in [RFC4762].
- I-SIDをフラッシュする必要がある場合（そのI-SID内のすべてのC-MAC）、I-SIDは適切なTLVにリストされます。すべてのI-SIDでC-MACをフラッシュする場合は、I-SID TLVを空にすることができます。各I-SIDは1つ以上のインターフェイス（通常、デュアルホーミングの場合は1つ）に関連付けられているため、単一のI-SIDのみをフラッシュするのが一般的です。 PBBの場合、I-SIDをフラッシュすることは、[RFC4762]で説明されている空のMACリストと同等です。
- If only a set of B-MAC-to-C-MAC associations needs to be flushed, then a B-MAC list can be included to further refine the list. This can be the case if an I-SID component has more than one interface and a B-MAC is used to refine the granularity. Since this is a positive MAC flush message, the intended behavior is to flush all C-MACs except those that are associated with B-MACs in the list.
- B-MACからC-MACへの関連付けのセットのみをフラッシュする必要がある場合は、B-MACリストを含めてリストをさらに絞り込むことができます。これは、I-SIDコンポーネントに複数のインターフェースがあり、B-MACを使用して粒度を調整する場合に当てはまります。これは正のMACフラッシュメッセージであるため、意図された動作は、リスト内のB-MACに関連付けられているものを除くすべてのC-MACをフラッシュすることです。
Positive flush of B-MACs is also useful for propagating flush from other protocols such as RSTP.
B-MACの正のフラッシュは、RSTPなどの他のプロトコルからのフラッシュを伝播するのにも役立ちます。
2. Negative flush of C-MACs. This is equivalent to optimized MAC flushing. In this case, the N-bit is set to 1; the C-bit is set to 1, and a list of B-MACs is provided so that the respective C-MACs can be flushed.
2. C-MACの負のフラッシュ。これは、最適化されたMACフラッシュと同等です。この場合、Nビットは1に設定されます。 Cビットは1に設定され、B-MACのリストが提供されるため、それぞれのC-MACをフラッシュできます。
- The I-SID list SHOULD be specified. If it is absent, then all I-SIDs require that the C-MACs be flushed.
- I-SIDリストを指定する必要があります。それがない場合、すべてのI-SIDでC-MACをフラッシュする必要があります。
- A set of B-MACs SHOULD be listed, since B-MAC-to-C-MAC associations need to be flushed and listing B-MACs scopes the flush to just those B-MACs. Again, this is typical usage, because a PBB VPLS I-component interface will have one associated I-SID and typically one (but possibly more than one) B-MAC, each with multiple remotely learned C-MACs. The B-MAC list is included to further refine the list for the remote receiver. Since this is a negative MAC flush message, the intended behavior is to flush all remote C-MACs that are associated with any B-MACs in the list (in other words, from the affected interface).
- B-MACからC-MACへの関連付けをフラッシュする必要があるため、B-MACのセットをリストする必要があります。繰り返しますが、これは典型的な使用方法です。PBBVPLS Iコンポーネントインターフェイスには、関連付けられたI-SIDが1つと、通常1つ（ただし複数）のB-MACがあり、それぞれに複数のリモートで学習されたC-MACがあります。 B-MACリストは、リモートレシーバーのリストをさらに絞り込むために含まれています。これは否定的なMACフラッシュメッセージであるため、意図された動作は、リスト内のB-MACに関連付けられているすべてのリモートC-MACをフラッシュすることです（つまり、影響を受けるインターフェイスから）。
The processing rules on reception of the MAC flush message are:
MACフラッシュメッセージの受信に関する処理規則は次のとおりです。
- On Backbone Core Bridges (BCBs), if the C-bit is set to 1, then the PBB-VPLS SHOULD NOT flush their B-MAC FIBs. The B-VPLS control plane SHOULD propagate the MAC flush message following the data-plane split-horizon rules to the established B-VPLS topology.
- バックボーンコアブリッジ（BCB）で、Cビットが1に設定されている場合、PBB-VPLSはB-MAC FIBをフラッシュしないでください。 B-VPLSコントロールプレーンは、データプレーンスプリットホライズンルールに従って、確立されたB-VPLSトポロジにMACフラッシュメッセージを伝播する必要があります（SHOULD）。
- On Backbone Edge Bridges (BEBs), the following actions apply:
- バックボーンエッジブリッジ（BEB）では、次のアクションが適用されます。
- The PBB I-SID list is used to determine the particular I-SID FIBs (I-component) that need to be considered for flushing action. If the PBB I-SID List Sub-TLV is not included in a received message, then all the I-SID FIBs associated with the receiving B-VPLS SHOULD be considered for flushing action.
- PBB I-SIDリストは、フラッシュアクションで考慮する必要がある特定のI-SID FIB（Iコンポーネント）を決定するために使用されます。 PBB I-SID List Sub-TLVが受信メッセージに含まれていない場合、受信B-VPLSに関連付けられているすべてのI-SID FIBがフラッシュアクションと見なされる必要があります。
- The PBB B-MAC list is used to identify from the I-SID FIBs in the previous step to selectively flush B-MAC-to-C-MAC associations, depending on the N-flag specified below. If the PBB B-MAC List Sub-TLV is not included in a received message, then all B-MAC-to-C-MAC associations in all I-SID FIBs (I-component) as specified by the I-SID List are considered for required flushing action, again depending on the N-flag specified below.
- PBB B-MACリストを使用して、前の手順でI-SID FIBを識別し、以下で指定されたNフラグに応じて、B-MACからC-MACへの関連付けを選択的にフラッシュします。 PBB B-MACリストサブTLVが受信メッセージに含まれていない場合、I-SIDリストで指定されているすべてのI-SID FIB（Iコンポーネント）のすべてのB-MACからC-MACへの関連付けは以下で指定されているNフラグに応じて、必要なフラッシュアクションを検討します。
- Next, depending on the N-flag value, the following actions apply:
- 次に、Nフラグの値に応じて、次のアクションが適用されます。
- N = 0: all the C-MACs in the selected I-SID FIBs SHOULD be flushed, with the exception of the resultant C-MAC list from the B-MAC list mentioned in the message ("flush all but the C-MACs associated with the B-MAC(s) in the B-MAC List Sub-TLV from the FIBs associated with the I-SID list").
- N = 0：メッセージで言及されているB-MACリストからの結果のC-MACリストを除いて、選択されたI-SID FIBのすべてのC-MACをフラッシュする必要があります（「関連するC-MACを除くすべてをフラッシュI-SIDリストに関連付けられたFIBからのB-MACリストサブTLVのB-MACを使用します」）。
- N = 1: all the resultant C-MACs SHOULD be flushed ("flush all the C-MACs associated with the B-MAC(s) in the B-MAC List Sub-TLV from the FIBs associated with the I-SID list").
- N = 1：結果のすべてのC-MACをフラッシュする必要があります（「I-SIDリストに関連付けられているFIBからB-MACリストサブTLVのB-MACに関連付けられているすべてのC-MACをフラッシュする」 ）。
If the MAC Flush Parameters TLV is received by a Backbone Edge Bridge (BEB) in a PBB-VPLS that does not understand the TLV, then an undesirable MAC flushing action may result. It is RECOMMENDED that all PE-rs devices participating in PBB-VPLS support the MAC Flush Parameters TLV. If this is not possible, the MAC Flush Parameters TLV SHOULD be disabled, as mentioned in Section 6 ("Operational Considerations").
MACフラッシュパラメータTLVが、TLVを認識しないPBB-VPLSのバックボーンエッジブリッジ（BEB）によって受信されると、望ましくないMACフラッシュアクションが発生する可能性があります。 PBB-VPLSに参加しているすべてのPE-rsデバイスがMACフラッシュパラメータTLVをサポートすることが推奨されます。これが不可能な場合は、セクション6（「運用上の考慮事項」）で説明したように、MACフラッシュパラメーターTLVを無効にする必要があります（SHOULD）。
"Mac Flush TLV" and its formal name -- "MAC Flush Parameters TLV" -- are synonymous. The MAC Flush TLV is applicable to the regular VPLS context as well, as explained in Section 3.1.1. To achieve negative MAC flushing (flush-all-from-me) in a regular VPLS context, the MAC Flush Parameters TLV SHOULD be encoded with C = 0 and N = 1 without inclusion of any Sub-TLVs. A negative MAC flush message is highly desirable in scenarios where VPLS access redundancy is provided by Ethernet ring protection as specified in the ITU-T G.8032 [ITU.G8032] specification.
「Mac Flush TLV」とその正式な名前「MAC Flush Parameters TLV」は同義語です。 MACフラッシュTLVは、セクション3.1.1で説明されているように、通常のVPLSコンテキストにも適用できます。通常のVPLSコンテキストで負のMACフラッシュ（flush-all-from-me）を実現するには、サブTLVを含めずに、MACフラッシュパラメーターTLVをC = 0およびN = 1でエンコードする必要があります。 ITU-T G.8032 [ITU.G8032]仕様で指定されているイーサネットリング保護によってVPLSアクセス冗長性が提供されるシナリオでは、負のMACフラッシュメッセージが非常に望ましいです。
As mentioned earlier, if the MAC Flush Parameters TLV is not understood by a receiver, then an undesirable MAC flushing action would result. To avoid this, one possible solution is to develop an LDP-based capability negotiation mechanism to negotiate support of various MAC flushing capabilities between PE-rs devices in a VPLS instance. A negotiation mechanism was discussed previously and was considered outside the scope of this document. Negotiation is not required to deploy this optimized MAC flushing as described in this document.
前述のように、MACフラッシュパラメーターTLVがレシーバーによって理解されない場合、望ましくないMACフラッシュアクションが発生します。これを回避するための1つの可能な解決策は、VPLSインスタンス内のPE-rsデバイス間のさまざまなMACフラッシュ機能のサポートをネゴシエートするLDPベースの機能ネゴシエーションメカニズムを開発することです。交渉メカニズムは以前に議論され、このドキュメントの範囲外と見なされました。このドキュメントで説明されているように、この最適化されたMACフラッシュを展開するためにネゴシエーションは必要ありません。
VPLS may be used with or without the optimization. If an operator wants the optimization for VPLS, it is the operator's responsibility to make sure that the VPLS devices that are capable of supporting the optimization are properly configured. From an operational standpoint, it is RECOMMENDED that implementations of the solution provide administrative control to select the desired MAC flushing action towards a PE-rs device in the VPLS. Thus, in the topology described in Figure 2, an implementation could support PE1-rs, sending optimized MAC flush messages towards the PE-rs devices that support the solution and the PE2-rs device initiating the [RFC4762] style of MAC flush messages towards the PE-rs devices that do not support the optimized solution during upgrades. The PE-rs that supports the MAC Flush Parameters TLV MUST support the RFC 4762 MAC flushing procedures, since this document only augments them.
VPLSは、最適化の有無にかかわらず使用できます。オペレーターがVPLSの最適化を希望する場合、最適化をサポートできるVPLSデバイスが適切に構成されていることを確認するのはオペレーターの責任です。運用の観点からは、ソリューションの実装により、VPLS内のPE-rsデバイスに向けて必要なMACフラッシュアクションを選択するための管理制御を提供することが推奨されます。したがって、図2で説明されているトポロジでは、実装はPE1-rsをサポートし、ソリューションをサポートするPE-rsデバイスに向けて最適化されたMACフラッシュメッセージを送信し、PE2-rsデバイスは[RFC4762]スタイルのMACフラッシュメッセージを送信します。アップグレード中に最適化されたソリューションをサポートしないPE-rsデバイス。 MACフラッシュパラメータTLVをサポートするPE-rsは、RFC 4762 MACフラッシュプロシージャをサポートする必要があります。これは、このドキュメントがそれらを補足するだけであるためです。
In the case of PBB-VPLS, this operation is the only method supported for specifying I-SIDs, and the optimization is assumed to be supported or should be turned off, reverting to flushing using [RFC4762] at the Backbone MAC level.
PBB-VPLSの場合、この操作はI-SIDを指定するためにサポートされている唯一の方法であり、最適化はサポートされているか、またはオフにする必要があると想定され、バックボーンMACレベルで[RFC4762]を使用したフラッシュに戻ります。
IANA maintains a registry called "Label Distribution Protocol (LDP) Parameters" with a sub-registry called "TLV Type Name Space".
IANAは、「Label Distribution Protocol（LDP）Parameters」というレジストリと「TLV Type Name Space」というサブレジストリを維持しています。
IANA has allocated three new code points as follows:
IANAは、次の3つの新しいコードポイントを割り当てました。
Value | Description | Reference | Notes
-------+---------------------------+------------+-----------
0x0406 | MAC Flush Parameters TLV | [RFC7361] |
0x0407 | PBB B-MAC List Sub-TLV | [RFC7361] |
0x0408 | PBB I-SID List Sub-TLV | [RFC7361] |
IANA has created a new sub-registry under "Label Distribution Protocol (LDP) Parameters" called "MAC Flush Flags".
IANAは、「MAC Flush Flags」と呼ばれる「Label Distribution Protocol（LDP）Parameters」の下に新しいサブレジストリを作成しました。
IANA has populated the registry as follows:
IANAは次のようにレジストリにデータを入力しました。
Bit Number | Hex | Abbreviation | Description | Reference
-----------+------+--------------+-----------------------+-----------
0 | 0x80 | C | Context | [RFC7361]
1 | 0x40 | N | Negative MAC flushing | [RFC7361]
2-7 | | | Unassigned |
Other new bits are to be assigned by Standards Action [RFC5226].
その他の新しいビットは、標準アクション[RFC5226]によって割り当てられます。
Control-plane aspects:
コントロールプレーンの側面：
LDP security (authentication) methods as described in [RFC5036] are applicable here. Further, this document implements security considerations as discussed in [RFC4447] and [RFC4762]. The extensions defined here optimize the MAC flushing action, and so the risk of security attacks is reduced. However, in the event that the configuration of support for the new TLV can be spoofed, sub-optimal behavior will be seen.
[RFC5036]で説明されているLDPセキュリティ（認証）メソッドがここで適用されます。さらに、このドキュメントは、[RFC4447]および[RFC4762]で説明されているように、セキュリティに関する考慮事項を実装しています。ここで定義された拡張機能はMACフラッシュアクションを最適化するため、セキュリティ攻撃のリスクが軽減されます。ただし、新しいTLVのサポートの構成がスプーフィングされる可能性がある場合、次善の動作が見られます。
Data-plane aspects:
データプレーンの側面：
This specification does not have any impact on the VPLS forwarding plane but can improve MAC flushing behavior.
この仕様はVPLSフォワーディングプレーンに影響を与えませんが、MACフラッシュ動作を改善できます。
The authors would like to thank Marc Lasserre, who made a major contribution to the development of this document.
著者は、このドキュメントの開発に多大な貢献をしたMarc Lasserreに感謝します。
Marc Lasserre Alcatel-Lucent EMail: marc.lasserre@alcatel-lucent.com
Marc Lasserre Alcatel-Lucentメール：marc.lasserre@alcatel-lucent.com
The authors would like to thank the following people who have provided valuable comments, feedback, and review on the topics discussed in this document: Dimitri Papadimitriou, Jorge Rabadan, Prashanth Ishwar, Vipin Jain, John Rigby, Ali Sajassi, Wim Henderickx, Paul Kwok, Maarten Vissers, Daniel Cohn, Nabil Bitar, Giles Heron, Adrian Farrel, Ben Niven-Jenkins, Robert Sparks, Susan Hares, and Stephen Farrell.
著者は、このドキュメントで説明されているトピックについて貴重なコメント、フィードバック、レビューを提供してくれた次の人々に感謝したいと思います。 、マーティンヴィッサーズ、ダニエルコーン、ナビルビター、ジャイルズヘロン、エイドリアンファレル、ベンニベンジェンキンス、ロバートスパークス、スーザンヘアーズ、スティーブンファレル。
[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月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447] Martini、L.、Ed。、Rosen、E.、El-Aawar、N.、Smith、T.、and G. Heron、 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol（LDP）"、RFC 4447 、2006年4月。
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.
[RFC4762] Lasserre、M。、編、およびV. Kompella、編、「Label Distribution Protocol（LDP）シグナリングを使用したVirtual Private LAN Service（VPLS）」、RFC 4762、2007年1月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、October 2007。
[IEEE.802.1Q-2011] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q, 2011.
[IEEE.802.1Q-2011] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control（MAC）Bridges and Virtual Bridged Local Area Networks」、IEEE Std 802.1Q、2011。
[ITU.G8032] International Telecommunication Union, "Ethernet ring protection switching", ITU-T Recommendation G.8032, February 2012.
[ITU.G8032]国際電気通信連合、「イーサネットリング保護スイッチング」、ITU-T勧告G.8032、2012年2月。
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664] Andersson、L.、Ed。およびE. Rosen、Ed。、 "Framework for Layer 2 Virtual Private Networks（L2VPNs）"、RFC 4664、2006年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
[RFC6073]マティーニ、L。、メッツ、C。、ナドー、T。、ボッチ、M。、およびM.アイサウイ、「セグメント化された疑似配線」、RFC 6073、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月。
[RFC7041] Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed., "Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging", RFC 7041, November 2013.
[RFC7041] Balus、F.、Ed。、Sajassi、A.、Ed。、and N. Bitar、Ed。、 "Extensions to the Virtual Private LAN Service（VPLS）Provider Edge（PE）Model for Provider Backbone Bridging"、 RFC 7041、2013年11月。
[VPLS-MH] Kothari, B., Kompella, K., Henderickx, W., Balus, F., Uttaro, J., Palislamovic, S., and W. Lin, "BGP based Multi-homing in Virtual Private LAN Service", Work in Progress, July 2014.
[VPLS-MH] Kothari、B.、Kompella、K.、Henderickx、W.、Balus、F.、Uttaro、J.、Palislamovic、S。、およびW. Lin、「仮想プライベートLANにおけるBGPベースのマルチホーミングサービス」、作業中、2014年7月。
Authors' Addresses
著者のアドレス
Pranjal Kumar Dutta Alcatel-Lucent 701 E Middlefield Road Mountain View, CA 94043 USA
Pranjal Kumar Dutta Alcatel-Lucent 701 E Middlefield Road Mountain View、CA 94043 USA
EMail: pranjal.dutta@alcatel-lucent.com
Florin Balus Alcatel-Lucent 701 E Middlefield Road Mountain View, CA 94043 USA
Florin Balus Alcatel-Lucent 701 E Middlefield Road Mountain View、CA 94043 USA
EMail: florin.balus@alcatel-lucent.com
Olen Stokes Extreme Networks 2121 RDU Center Drive Suite 300 Morrisville, NC 27650 USA
Olen Stokes Extreme Networks 2121 RDU Center Drive Suite 300 Morrisville、NC 27650 USA
EMail: ostokes@extremenetworks.com
Geraldine Calvignac Orange 2, avenue Pierre-Marzin Lannion Cedex, 22307 France
Geraldine Calvignac Orange 2、avenue Pierre-Marzin Lannion Cedex、22307 France
EMail: geraldine.calvignac@orange.com
Don Fedyk Hewlett-Packard Company USA
Don Fedyk Hewlett-Packard Company USA
EMail: don.fedyk@hp.com