[要約] 要約： RFC 8614は、BGP Virtual Private LAN Service（VPLS）の制御フラグの処理方法を更新するためのものである。目的： このRFCの目的は、VPLSの制御フラグの処理に関する不明瞭さや誤解を解消し、より効果的なネットワーク運用を実現することである。
Internet Engineering Task Force (IETF) R. Singh
Request for Comments: 8614 K. Kompella
Updates: 4761 Juniper Networks
Category: Standards Track S. Palislamovic
ISSN: 2070-1721 Nokia
June 2019
Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS)
BGP仮想プライベートLANサービス（VPLS）の制御フラグの処理の更新
Abstract
概要
This document updates the meaning of the Control Flags field in the "Layer2 Info Extended Community" used for BGP Virtual Private LAN Service (VPLS) Network Layer Reachability Information (NLRI) as defined in RFC 4761. This document updates RFC 4761.
このドキュメントは、RFC 4761で定義されているように、BGP仮想プライベートLANサービス（VPLS）ネットワークレイヤー到達可能性情報（NLRI）に使用される「Layer2 Info Extended Community」のControl Flagsフィールドの意味を更新します。このドキュメントは、RFC 4761を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8614.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8614で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Problem Description .............................................3
3. Updated Meaning of Control Flags in the Layer2 Info Extended
Community .......................................................3
3.1. Control Word (C-Bit) .......................................4
3.2. Sequence Flag (S-Bit) ......................................4
4. Using Point-to-Multipoint (P2MP) LSPs as Transport for
BGP VPLS ........................................................5
5. Illustrative Diagram ............................................6
6. Treatment of C-Bits and S-Bits in Multihoming Scenarios .........7
6.1. Control Word (C-Bit) .......................................7
6.2. Sequence Flag (S-Bit) ......................................7
7. Security Considerations .........................................8
8. IANA Considerations .............................................8
9. References ......................................................8
9.1. Normative References .......................................8
9.2. Informative References .....................................9
Authors' Addresses .................................................9
"Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling" [RFC4761] describes the concepts and signaling for using the Border Gateway Protocol (BGP) to set up a VPLS. It specifies the BGP VPLS Network Layer Reachability Information (NLRI) by which a Provider Edge (PE) router may require other PEs in the same VPLS to include (or not) the Control Word (CW) and sequencing information in VPLS frames sent to this PE.
「自動検出とシグナリングにBGPを使用する仮想プライベートLANサービス（VPLS）」[RFC4761]では、ボーダーゲートウェイプロトコル（BGP）を使用してVPLSを設定するための概念とシグナリングについて説明しています。これは、プロバイダーエッジ（PE）ルーターが同じVPLS内の他のPEに制御ワード（CW）とシーケンス情報をこのVPLSフレームに含める（または含めない）ことを要求するBGP VPLSネットワーク層到達可能性情報（NLRI）を指定しますPE。
The use of the CW helps prevent the misordering of IPv4 or IPv6 Pseudowire (PW) traffic over Equal-Cost Multipath (ECMP) paths or Link Aggregation Group (LAG) bundles. [RFC4385] describes the format for the CW that may be used over point-to-point PWs and over a VPLS. Along with [RFC3985], [RFC4385] also describes sequence number usage for VPLS frames.
CWを使用すると、等コストマルチパス（ECMP）パスまたはリンク集約グループ（LAG）バンドルを介したIPv4またはIPv6疑似配線（PW）トラフィックの誤った順序を防ぐことができます。 [RFC4385]は、ポイントツーポイントPWとVPLSで使用できるCWの形式を説明しています。 [RFC3985]とともに、[RFC4385]はVPLSフレームのシーケンス番号の使用法についても説明しています。
However, [RFC4761] does not specify the behavior of PEs in a mixed environment where some PEs support CW/sequencing and others do not.
ただし、[RFC4761]は、一部のPEがCW /シーケンスをサポートし、他のPEがサポートしない混合環境でのPEの動作を指定していません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
[RFC4761] specifies the VPLS BGP NLRI by which a given PE advertises the behavior expected by the multiple PEs participating in the same VPLS. The NLRI indicates the VPLS label that the various PE routers, which are referred to in the NLRI, should use when forwarding VPLS traffic to this PE. Additionally, by using the Control Flags, this PE specifies whether the other PEs (in the same VPLS) should use the CW or sequenced delivery for frames forwarded to this PE. These are indicated by the C-bits and the S-bits, respectively, in the Control Flags, as specified in Section 3.2.4 in [RFC4761].
[RFC4761]は、特定のPEが同じVPLSに参加している複数のPEが予期する動作を通知するためのVPLS BGP NLRIを指定します。 NLRIは、NLLSで参照されるさまざまなPEルータが、VPLSトラフィックをこのPEに転送するときに使用する必要があるVPLSラベルを示します。さらに、制御フラグを使用することにより、このPEは、（同じVPLS内の）他のPEがこのPEに転送されるフレームにCWまたはシーケンス配信を使用するかどうかを指定します。これらは、[RFC4761]のセクション3.2.4で指定されているように、制御フラグのCビットとSビットでそれぞれ示されます。
[RFC4761] requires that if the advertising PE sets the C-bits and S-bits, the receiving PE MUST, respectively, insert a CW and include sequence numbers when forwarding VPLS traffic to the advertising PE.
[RFC4761]は、アドバタイジングPEがCビットとSビットを設定する場合、受信PEがそれぞれCWを挿入し、VPLSトラフィックをアドバタイジングPEに転送するときにシーケンス番号を含める必要があることを要求します。
However, in a BGP VPLS deployment, there would often be cases where a PE receiving the VPLS BGP NLRI may not have the ability to insert a CW or include sequencing information inside PW frames. Thus, the behavior of CW processing and sequencing needs to be further specified.
ただし、BGP VPLS展開では、VPLS BGP NLRIを受信するPEがCWを挿入したり、PWフレーム内にシーケンス情報を含めることができない場合がよくあります。したがって、CW処理とシーケンスの動作をさらに指定する必要があります。
This document updates the meaning of the Control Flags in the Layer2 Info Extended Community in the BGP VPLS NLRI. It also specifies the forwarding behavior for a mixed-mode environment where not every PE in a VPLS has the ability or the configuration to honor the Control Flags received from the PE advertising the BGP NLRI.
このドキュメントでは、BGP VPLS NLRIのLayer2 Info Extended Communityの制御フラグの意味を更新します。また、VPLS内のすべてのPEが、BGP NLRIをアドバタイズするPEから受信した制御フラグを尊重する機能または構成を備えていない混合モード環境の転送動作も指定します。
3. Updated Meaning of Control Flags in the Layer2 Info Extended Community
3. Layer2 Info拡張コミュニティでの制御フラグの意味の更新
[RFC4761] does not allow for the CW setting to be negotiated. In a typical implementation, if a PE sets the C-bit, it expects to receive VPLS frames with a CW and will send frames the same way. If the PEs at the two ends of a PW do not agree on the setting of the C-bit, the PW does not come up. The behavior is similar for the S-bit.
[RFC4761]は、CW設定のネゴシエートを許可していません。典型的な実装では、PEがCビットを設定すると、CWでVPLSフレームを受信することが期待され、同じ方法でフレームが送信されます。 PWの両端のPEがCビットの設定に同意しない場合、PWは起動しません。動作はSビットでも同様です。
This memo updates the meaning of the C-bit and the S-bit in the Control Flags.
このメモは、制御フラグのCビットとSビットの意味を更新します。
If a PE sets the C-bit in its NLRI, it means that the PE has the ability to send and receive frames with a CW.
PEがそのNLRIでCビットを設定する場合、これは、PEがCWでフレームを送受信できることを意味します。
- If the PEs at both ends of a PW set the C-bit, CWs MUST be used in both directions of the PW.
- PWの両端のPEがCビットを設定する場合、CWはPWの両方向で使用する必要があります。
- If both PEs send a C-bit of 0, CWs MUST NOT be used on the PW.
- 両方のPEが0のCビットを送信する場合、CWをPWで使用してはなりません（MUST NOT）。
These two cases behave as before.
これらの2つのケースは以前と同様に動作します。
However, if the PEs at both ends of the PW do not agree on the setting of the C-bit, CWs MUST NOT be used in either direction on that PW, but the PW MUST NOT be prevented from coming up due to this mismatch. So, the PW will still come up but will not use the CW in either direction. This behavior is changed from the behavior described in [RFC4761] where the PW does not come up.
ただし、PWの両端のPEがCビットの設定に同意しない場合、CWはそのPWのどちらの方向にも使用してはなりません（MUST）が、この不一致が原因でPWが起動するのを防ぐことはできません。したがって、PWは引き続きアップしますが、どちらの方向でもCWを使用しません。この動作は、PWが起動しない[RFC4761]で説明されている動作から変更されています。
If a PE sets the S-bit in its NLRI, it means that the PE has the ability to set sequence numbers as described in Section 4.1 in [RFC4385] and process sequence numbers as described in Section 4.2 in [RFC4385].
PEがNLRIでSビットを設定する場合、それはPEが[RFC4385]のセクション4.1で説明されているようにシーケンス番号を設定し、[RFC4385]のセクション4.2で説明されているようにシーケンス番号を処理できることを意味します。
- If the PEs at both ends of a PW set the S-bit, non-zero sequence numbers MUST be used in both directions of the PW.
- PWの両端のPEがSビットを設定する場合、ゼロ以外のシーケンス番号をPWの両方向で使用する必要があります。
- If both PEs send an S-bit of 0, sequence numbers MUST NOT be used on the PW.
- 両方のPEが0のSビットを送信する場合、シーケンス番号をPWで使用してはなりません（MUST NOT）。
These two cases behave as before.
これらの2つのケースは以前と同様に動作します。
[RFC4761] does not allow for the S-bit setting to be negotiated either. In a typical implementation, if the PE sets the S-bit in the advertised NLRI, it expects to receive VPLS frames with non-zero sequence numbers and will send outgoing frames over the PW with non-zero sequence numbers.
[RFC4761]では、Sビット設定をネゴシエートすることもできません。典型的な実装では、PEがアドバタイズされたNLRIでSビットを設定する場合、非ゼロのシーケンス番号でVPLSフレームを受信することを期待し、非ゼロのシーケンス番号でPW経由で送信フレームを送信します。
This memo further specifies the expected behavior when the PEs at the ends of the PW advertise differing S-bit values. If the PEs at both ends of the PW do not agree on the setting of the S-bit, then the PW SHOULD NOT come up. This is to avoid running into out-of-sequence ordering scenarios when the multiple PEs that are enabling multihoming for a site have differing S-bit advertisements as described in Section 4.2 in [RFC4385]. However, if a deployment is known to not utilize multihoming, a user-configurable way to override this recommendation MAY be provided by an implementation whereby the PW is allowed to come up. In that case, the PE advertising the S-bit as 0 should set sequence numbers in the frames as 0, and the PW receiving the frames should not expect to receive non-zero sequence numbers.
このメモはさらに、PWの終わりにあるPEが異なるSビット値をアドバタイズするときの予想される動作を指定します。 PWの両端のPEがSビットの設定に同意しない場合、PWは起動しません。これは、[RFC4385]のセクション4.2で説明されているように、サイトのマルチホーミングを有効にしている複数のPEが異なるSビットアドバタイズを使用している場合に、順序が乱れる注文シナリオに遭遇しないようにするためです。ただし、展開がマルチホーミングを利用しないことがわかっている場合、この推奨事項を上書きするユーザー構成可能な方法が、PWの起動を許可される実装によって提供される場合があります。その場合、Sビットを0としてアドバタイズするPEは、フレーム内のシーケンス番号を0に設定し、フレームを受信するPWは、ゼロ以外のシーケンス番号を受信することを期待すべきではありません。
BGP VPLS can be used over point-to-point Label Switched Paths (LSPs) acting as transport between the VPLS PEs. Alternately, BGP VPLS may also be used over Point-to-Multipoint (P2MP) LSPs with the source of the P2MP LSP rooted at the PE advertising the VPLS BGP NLRI.
BGP VPLSは、VPLS PE間のトランスポートとして機能するポイントツーポイントのラベルスイッチドパス（LSP）で使用できます。あるいは、BGP VPLSは、VPLS BGP NLRIをアドバタイズするPEをルートとするP2MP LSPのソースを使用して、ポイントツーマルチポイント（P2MP）LSPで使用することもできます。
In a network that uses P2MP LSPs as transport for a VPLS, there may be some PEs that support the CW while others may not. The behavior is similar for the sequencing of VPLS frames.
VPLSのトランスポートとしてP2MP LSPを使用するネットワークでは、CWをサポートしているPEとサポートしていないPEがある場合があります。動作は、VPLSフレームのシーケンスについても同様です。
In such a setup, a source PE that supports CW should set up two different P2MP LSPs such that:
このようなセットアップでは、CWをサポートするソースPEは、次のような2つの異なるP2MP LSPをセットアップする必要があります。
- One P2MP LSP will transport CW-marked frames to those PEs that advertised the C-bit as 1.
- 1つのP2MP LSPは、CWマークフレームを、Cビットを1としてアドバタイズしたPEに転送します。
- The other P2MP LSP will transport frames without the CW to those PEs that advertised the C-bit as 0.
- 他のP2MP LSPは、CWなしのフレームを、Cビットを0としてアドバタイズしたPEに転送します。
Using two different P2MP LSPs to deliver frames with and without the CW to different PEs ensures that a P2MP root PE honors the C-bit advertised by the other P2MP PEs.
2つの異なるP2MP LSPを使用して、CWの有無にかかわらずフレームを異なるPEに配信することで、P2MPルートPEが他のP2MP PEによってアドバタイズされたCビットを確実に尊重するようになります。
However, the set of leaves on the two P2MP LSPs (rooted at the given PE) MUST NOT contain any PEs that advertised a value for the S-bit different from what the root PE itself is advertising. PEs that advertised their S-bit values differently (from what the P2MP root PE advertised) will not be on either of the P2MP LSPs. This ensures that the P2MP root PE is sending VPLS frames only to those PEs that agree on the setting of the S-bit.
ただし、2つのP2MP LSP（特定のPEをルートとする）上のリーフのセットには、ルートPE自体がアドバタイズしているものとは異なるSビットの値をアドバタイズしたPEを含めてはなりません。 （P2MPルートPEがアドバタイズしたものとは）異なるSビット値をアドバタイズしたPEは、どちらのP2MP LSPにもありません。これにより、P2MPルートPEがSビットの設定に同意するPEにのみVPLSフレームを送信することが保証されます。
The ingress router for the P2MP LSP should send separate NLRIs for the cases of using the CW and for not using the CW.
P2MP LSPの入力ルーターは、CWを使用する場合と使用しない場合で別々のNLRIを送信する必要があります。
-----
/ A1 \
---- ____CE1 |
/ \ -------- -------- / | |
| A2 CE2- / \ / PE1 \ /
\ / \ / \___/ | \ -----
---- ---PE2 | \
| | \ -----
| Service Provider Network | \ / \
| | CE5 A5
| ___ | / \ /
\ / \ PE4_/ -----
PE3 / \ /
|------/ \------- -------
---- / | ----
/ \/ \ / \ CE = Customer Edge Device
| A3 CE3 --CE4 A4 | PE = Provider Edge Router
\ / \ /
---- ---- A<n> = Customer site n
Figure 1: Example of a VPLS
図1：VPLSの例
In the above topology, let there be a VPLS configured with the PEs as displayed. Let PE1 be the PE under consideration that is CW enabled and sequencing enabled. Let PE2 and PE3 also be CW enabled and sequencing enabled. Let PE4 not be CW enabled or have the ability to include sequence numbers. PE1 will advertise a VPLS BGP NLRI, containing the C/S-bits marked as 1. PE2 and PE3, on learning of the NLRI from PE1, will include the CW and non-zero sequence numbers in the VPLS frames being forwarded to PE1 as described in Section 4 in [RFC4385]. However, PE4, which does not have the ability to include a CW or include non-zero sequence numbers, will not.
上記のトポロジで、表示されているようにPEで構成されたVPLSがあるとします。 PE1をCWが有効で、シーケンスが有効な検討中のPEとします。 PE2とPE3もCWを有効にし、シーケンスを有効にします。 PE4をCW対応にしないか、シーケンス番号を含めることができるようにします。 PE1は、1とマークされたC / Sビットを含むVPLS BGP NLRIをアドバタイズします。PE2とPE3は、PE1からのNLRIの学習時に、PE1に転送されるVPLSフレームにCWとゼロ以外のシーケンス番号を含めます。 [RFC4385]のセクション4で説明されています。ただし、CWを含めたり、ゼロ以外のシーケンス番号を含めたりすることができないPE4は含まれません。
As per [RFC4761], PE1 would expect all other PEs to forward CW-containing frames that have non-zero sequence numbers. That expectation cannot be met by PE4 in this example. Thus, as per [RFC4761], the PW between PE1 and PE4 does not come up.
[RFC4761]によると、PE1は、他のすべてのPEがゼロ以外のシーケンス番号を持つCWを含むフレームを転送することを期待します。この例では、PE4はその期待に応えることができません。したがって、[RFC4761]のように、PE1とPE4間のPWはアップしません。
However, this document addresses how an implementation should support BGP VPLS in a network where a subset of the BGP VPLS PEs support the CW and/or frame sequencing. PE1 will not bring up the PW with PE4 due to the S-bit mismatch, unless overridden by local configuration on PE1 and PE4 as specified in Section 3.2. If PE4 instead was to advertise a C-bit of 0 and an S-bit of 1, then the PW between PE1 and PE4 would come up despite the CW mismatch. Additionally, PE1 would set up its data plane such that it will strip the CW only for those VPLS frames that are received from PEs that have indicated their desire to receive CW-marked frames. So, PE1 will set up its data plane to strip the CW only for VPLS frames received from PE2 and PE3, and it will expect to process PW frames containing non-zero sequence numbers as described in Section 4.2 in [RFC4385]. PE1 will set up its data plane to not strip the CW from frames received from PE4, and it would expect PE4 to send frames with non-zero sequence numbers. All frames sent by PE4 to PE1 over the PW would have a non-zero sequence number.
ただし、このドキュメントでは、BGP VPLS PEのサブセットがCWやフレームシーケンスをサポートするネットワークで、実装がBGP VPLSをサポートする方法について説明します。セクション3.2で指定されているようにPE1とPE4のローカル構成でオーバーライドされない限り、S1ビットの不一致により、PE1はPE4でPWを起動しません。 PE4が代わりに0のCビットと1のSビットをアドバタイズする場合、CWの不一致にもかかわらずPE1とPE4間のPWがアップします。さらに、PE1は、CWマーク付きフレームを受信したいという希望を示した、PEから受信したVPLSフレームに対してのみCWを削除するように、データプレーンをセットアップします。したがって、PE1はデータプレーンをセットアップして、PE2およびPE3から受信したVPLSフレームのCWのみを削除し、[RFC4385]のセクション4.2で説明されているように、ゼロ以外のシーケンス番号を含むPWフレームを処理することを期待します。 PE1は、PE4から受信したフレームからCWを取り除かないようにデータプレーンを設定し、PE4がゼロ以外のシーケンス番号を持つフレームを送信することを期待します。 PWを介してPE4からPE1に送信されるすべてのフレームには、ゼロ以外のシーケンス番号が含まれます。
In a multihomed environment, different PEs may effectively represent the same service destination endpoint. It could be assumed that the end-to-end PW establishment process should follow the same rules when it comes to CW requirements, meaning that setting the C-bit would be enforced equally toward both primary and backup designated forwarders.
マルチホーム環境では、異なるPEが同じサービス宛先エンドポイントを効果的に表す場合があります。エンドツーエンドのPW確立プロセスは、CW要件に関しては同じルールに従う必要があると想定できます。つまり、Cビットの設定は、プライマリフォワーダーとバックアップフォワーダーの両方に等しく適用されます。
However, in the multihoming case, each PW SHOULD be evaluated independently. Assuming the network topology specified in Section 5, there could be the case where the PW between PE2 and PE1 could have the CW signaled via the extended community and would be used in the VPLS frame, while the PE2-to-PE4 PW would not insert the CW in the VPLS frame due to a C-bit mismatch. The multihoming behavior of the rest of the PEs should simply follow the rules specified in [VPLS-MULTIHOMING].
ただし、マルチホーミングの場合、各PWは個別に評価する必要があります（SHOULD）。セクション5で指定されたネットワークトポロジを想定すると、PE2とPE4の間のPWは挿入されず、PE2とPE1の間のPWが拡張コミュニティを介してCWをシグナリングし、VPLSフレームで使用される場合があります。 Cビットの不一致によるVPLSフレームのCW残りのPEのマルチホーミング動作は、[VPLS-MULTIHOMING]で指定されたルールに従うだけです。
In a multihomed environment, different PEs may effectively represent the same service destination endpoint. In this case, the rules for end-to-end PW establishment SHOULD follow the same behavior as that described in Section 3.2 when it comes to S-bit requirements. Consider the case described in Section 5 with CE5 having a connection to multiple PEs (multihomed) to PE4 and PE1. The PW's behavior is similar to that for the CW scenario such that the S-bit evaluation SHOULD be independent per PW. So, in the case where PE4 does not set the S-bit in its advertised NLRI, there is an S-bit mismatch between PE1 and PE4. This mismatch prevents the PW establishment between PE1 and PE4. So, only one PW -- between PE1 and PE2 -- would be established for the multihomed site shown. Thus, even though CE5 is physically multihomed, due to PE4's lack of support for sending frames with non-zero sequence numbers, there would be no PW between PE2 and PE4. CE5 would effectively not be multihomed.
マルチホーム環境では、異なるPEが同じサービス宛先エンドポイントを効果的に表す場合があります。この場合、エンドツーエンドのPW確立のルールは、Sビット要件に関して、セクション3.2で説明されているのと同じ動作に従う必要があります（SHOULD）。 CE5が複数のPE（マルチホーム）からPE4およびPE1に接続しているセクション5で説明されているケースを考えてみます。 PWの動作はCWシナリオの動作と同様で、Sビットの評価はPWごとに独立している必要があります（SHOULD）。したがって、PE4がアドバタイズされたNLRIでSビットを設定しない場合、PE1とPE4の間にSビットの不一致があります。この不一致により、PE1とPE4間のPW確立が妨げられます。したがって、示されているマルチホームサイトでは、PE1とPE2の間に1つのPWのみが確立されます。したがって、CE5は物理的にマルチホーム化されていますが、PE4はゼロ以外のシーケンス番号を持つフレームの送信をサポートしていないため、PE2とPE4の間にPWはありません。 CE5は事実上マルチホーム化されません。
This document updates the behavior specified in [RFC4761]. The security considerations discussed in [RFC4761] apply. This document essentially addresses BGP VPLS behavior for PEs when the C-bit value, the S-bit value, or both values advertised by a given PE are different from what another PE in the VPLS is advertising. Any bit-flipping media errors leading to causing this mismatch of C/S-bits between PEs do not adversely affect the availability of the PWs. Rather, they cause CWs to not be used or cause the NLRI-advertising PE to not expect non-zero sequenced frames, for the C-bit and the S-bit, respectively, being mismatched across PEs. This is no worse than the previous behavior where any bit-flipping media errors leading to a mismatch of the C/S-bits between PEs would cause the PW to not come up.
このドキュメントは、[RFC4761]で指定された動作を更新します。 [RFC4761]で説明されているセキュリティの考慮事項が適用されます。このドキュメントでは、特定のPEによってアドバタイズされるCビット値、Sビット値、またはその両方の値が、VPLS内の別のPEがアドバタイズしているものと異なる場合の、PEのBGP VPLS動作を本質的に扱います。 PE間のC / Sビットの不一致を引き起こすビットフリッピングメディアエラーは、PWの可用性に悪影響を及ぼしません。むしろ、それらはCWが使用されないようにするか、NLRIアドバタイジングPEがCとSビットそれぞれについてPE間で一致しないためにゼロ以外のシーケンスフレームを期待しないようにします。これは、PE間のC / Sビットの不一致につながるビットフリッピングメディアエラーが原因でPWが起動しないという以前の動作よりも悪いことではありません。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>.
[RFC4761] Kompella、K.、Ed。およびY. Rekhter編、「自動検出とシグナリングにBGPを使用した仮想プライベートLANサービス（VPLS）」、RFC 4761、DOI 10.17487 / RFC4761、2007年1月、<https://www.rfc-editor.org/ info / rfc4761>。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC4385]ブライアント、S。、スワロー、G。、マティーニ、L。、およびD.マクファーソン、「MPLS PSNで使用する疑似配線エミュレーションエッジツーエッジ（PWE3）制御ワード」、RFC 4385、DOI 10.17487 / RFC4385、2006年2月、<https://www.rfc-editor.org/info/rfc4385>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <https://www.rfc-editor.org/info/rfc3985>.
[RFC3985]ブライアント、S。、エド。およびP. Pate、編、「疑似ワイヤーエミュレーションエッジツーエッジ（PWE3）アーキテクチャ」、RFC 3985、DOI 10.17487 / RFC3985、2005年3月、<https://www.rfc-editor.org/info/rfc3985 >。
[VPLS-MULTIHOMING] Kothari, B., Kompella, K., Henderickx, W., Balus, F., and J. Uttaro, "BGP based Multi-homing in Virtual Private LAN Service", Work in Progress, draft-ietf-bess-vpls-multihoming-03, March 2019.
[VPLS-MULTIHOMING] Kothari、B.、Kompella、K.、Henderickx、W.、Balus、F。、およびJ. Uttaro、「仮想プライベートLANサービスにおけるBGPベースのマルチホーミング」、Work in Progress、draft-ietf -bess-vpls-multihoming-03、2019年3月。
Authors' Addresses
著者のアドレス
Ravi Singh Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America
Ravi Singh Juniper Networks 1133 Innovation Way Sunnyvale、CA 94089アメリカ合衆国
Email: ravis@juniper.net
Kireeti Kompella Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America
キリーティコンペラジュニパーネットワークス1133イノベーションウェイサニーベール、カリフォルニア州94089アメリカ合衆国
Email: kireeti@juniper.net
Senad Palislamovic Nokia 600 Mountain Avenue Murray Hill, NJ 07974-0636 United States of America
セナドパリスラモビッチノキア600マウンテンアベニューマレーヒル、ニュージャージー州07974-0636アメリカ合衆国
Email: Senad.palislamovic@nokia.com