メインコンテンツまでスキップ

RFC 9026 - Multicast VPN Fast Upstream Failover

  • ステータス: Proposed Standard
  • 発行日: April 2021
  • ストリーム: IETF
  • エラッタ: エラッタなし

Abstract​

This document defines Multicast Virtual Private Network (VPN) extensions and procedures that allow fast failover for upstream failures by allowing downstream Provider Edges (PEs) to consider the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow. The fast failover is enabled by using "Bidirectional Forwarding Detection (BFD) for Multipoint Networks" (RFC 8562) and the new BGP Attribute, BFD Discriminator. Also, this document introduces a new BGP Community, Standby PE, extending BGP Multicast VPN (MVPN) routing so that a C-multicast route can be advertised toward a Standby Upstream PE.

このドキュメントでは、マルチキャスト仮想プライベートネットワーク（VPN）の拡張と手順を定義します。これにより、ダウンストリームプロバイダーエッジ（PE）がVPNマルチキャストフローのアップストリームPEを選択するときに、プロバイダートンネル（P-tunnels）のステータスを考慮できるようになり、アップストリーム障害の高速フェイルオーバーが可能になります。高速フェイルオーバーは、「マルチポイントネットワークの双方向転送検出（BFD）」（RFC 8562）と新しいBGP属性であるBFD Discriminatorを使用して有効になります。また、このドキュメントでは、新しいBGPコミュニティであるStandby PEを導入し、BGPマルチキャストVPN（MVPN）ルーティングを拡張して、C-マルチキャストルートをスタンバイアップストリームPEに向けてアドバタイズできるようにします。

Status of This Memo​

This is an Internet Standards Track document.

これはインターネット標準化過程の文書です。

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.

このドキュメントは、Internet Engineering Task Force（IETF）の成果物です。これはIETFコミュニティのコンセンサスを表しています。公開レビューを受けており、Internet Engineering Steering Group（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/rfc9026.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9026 で入手できます。

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright (c) 2021 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）の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、トラスト法的規定のセクション4.eで説明されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseで説明されている保証なしで提供されます。

Table of Contents​

    1. Introduction
    1. Conventions Used in This Document
    1. UMH Selection Based on Tunnel Status
    1. Standby C-Multicast Route
    1. Hot Root Standby
    1. Duplicate Packets
    1. IANA Considerations
    1. Security Considerations
    1. References
  • Acknowledgments
  • Contributors
  • Authors' Addresses

1. Introduction​

It is assumed that the reader is familiar with the workings of multicast MPLS/BGP IP VPNs as described in [RFC6513] and [RFC6514].

読者は、[RFC6513]および[RFC6514]で説明されているマルチキャストMPLS/BGP IP VPNの仕組みに精通していることを前提としています。

In the context of multicast in BGP/MPLS VPNs [RFC6513], it is desirable to provide mechanisms allowing fast recovery of connectivity on different types of failures. This document addresses failures of elements in the provider network that are upstream of PEs connected to VPN sites with receivers.

BGP/MPLS VPN [RFC6513]のマルチキャストのコンテキストでは、さまざまなタイプの障害時に接続を迅速に回復できるメカニズムを提供することが望まれます。このドキュメントでは、受信側を持つVPNサイトに接続されたPEのアップストリームにあるプロバイダーネットワーク内の要素の障害に対処します。

Section 3 describes local procedures allowing an egress PE (a PE connected to a receiver site) to take into account the status of P-tunnels to determine the Upstream Multicast Hop (UMH) for a given (C-S,C-G). One of the optional methods uses [RFC8562] and the new BGP Attribute, BFD Discriminator. None of these methods provide a "fast failover" solution when used alone but can be used together with the mechanism described in Section 4 for a "fast failover" solution.

セクション3では、出力PE（受信側サイトに接続されたPE）がP-tunnelsのステータスを考慮して、特定の（C-S、C-G）のアップストリームマルチキャストホップ（UMH）を決定できるようにするローカル手順について説明します。オプションの方法の1つは、[RFC8562]と新しいBGP属性であるBFD Discriminatorを使用します。これらの方法はどれも単独で使用した場合に「高速フェイルオーバー」ソリューションを提供するものではありませんが、セクション4で説明されているメカニズムと組み合わせて使用​​することで、「高速フェイルオーバー」ソリューションを実現できます。

Section 4 describes an optional BGP extension, a new Standby PE Community, that can speed up failover by not requiring any Multicast VPN (MVPN) routing message exchange at recovery time.

セクション4では、オプションのBGP拡張機能である新しいStandby PEコミュニティについて説明します。これにより、回復時にマルチキャストVPN（MVPN）ルーティングメッセージの交換が不要になり、フェイルオーバーを高速化できます。

Section 5 describes a "hot root standby" mechanism that can be used to improve failover time in MVPN. The approach combines mechanisms defined in Sections 3 and 4 and has similarities with the solution described in [RFC7431] to improve failover times when PIM routing is used in a network given some topology and metric constraints.

セクション5では、MVPNのフェイルオーバー時間を改善するために使用できる「ホットルートスタンバイ」メカニズムについて説明します。このアプローチは、セクション3および4で定義されたメカニズムを組み合わせたものであり、[RFC7431]で説明されているソリューションと類似しており、特定のトポロジおよびメトリックの制約があるネットワークでPIMルーティングが使用されている場合のフェイルオーバー時間を改善します。

2. Conventions Used in This Document​

2.1. Requirements Language​

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] で説明されているように解釈されます。これらは、ここに示すようにすべて大文字で表示される場合にのみ適用されます。

2.2. Terminology​

The terminology used in this document is the terminology defined in [RFC6513] and [RFC6514].

このドキュメントで使用される用語は、[RFC6513]および[RFC6514]で定義されている用語です。

2.3. Abbreviations​

This document uses the following abbreviations:

このドキュメントでは、次の略語を使用しています。

  • BFD: Bidirectional Forwarding Detection (双方向転送検出)
  • MVPN: Multicast Virtual Private Network (マルチキャスト仮想プライベートネットワーク)
  • NLRI: Network Layer Reachability Information (ネットワーク層到達可能性情報)
  • PE: Provider Edge (プロバイダーエッジ)
  • PMSI: Provider Multicast Service Interface (プロバイダーマルチキャストサービスインターフェイス)
  • RPT: Rendezvous Point Tree (ランデブーポイントツリー)
  • SPT: Shortest Path Tree (最短パスツリー)
  • UMH: Upstream Multicast Hop (アップストリームマルチキャストホップ)
  • VPN: Virtual Private Network (仮想プライベートネットワーク)
  • VRF: VPN Routing and Forwarding (VPNルーティングおよび転送)

3. UMH Selection Based on Tunnel Status​

Section 5.1 of RFC 6513 describes procedures used by an MVPN downstream PE to determine the Upstream Multicast Hop (UMH) for a given (C-S,C-G).

RFC 6513のセクション5.1では、MVPNダウンストリームPEが特定の（C-S、C-G）のアップストリームマルチキャストホップ（UMH）を決定するために使用する手順について説明しています。

For a given downstream PE and a given VRF, the P-tunnel corresponding to a given Upstream PE for a given (C-S,C-G) state is the S-PMSI tunnel advertised by that Upstream PE for that (C-S,C-G) and imported into that VRF or, if there isn't any such S-PMSI, the I-PMSI tunnel advertised by that PE and imported into that VRF.

特定のダウンストリームPEおよび特定のVRFの場合、特定の（C-S、C-G）状態の特定のアップストリームPEに対応するP-tunnelは、その（C-S、C-G）に対してそのアップストリームPEによってアドバタイズされ、そのVRFにインポートされたS-PMSIトンネルです。または、そのようなS-PMSIがない場合は、そのPEによってアドバタイズされ、そのVRFにインポートされたI-PMSIトンネルです。

The procedure described here is optional one, based on a downstream PE taking into account the status of P-tunnels rooted at each possible Upstream PE, for including or not including each given PE in the list of candidate UMHs for a given (C-S,C-G) state. If it is not possible to determine whether a P-tunnel's current status is Up, the state shall be considered "not known to be Down", and it may be treated as if it is Up so that attempts to use the tunnel are acceptable. The result is that, if a P-tunnel is Down (see Section 3.1), the PE that is the root of the P-tunnel will not be considered for UMH selection. This will result in the downstream PE failing over to use the next Upstream PE in the list of candidates. Some downstream PEs could arrive at a different conclusion regarding the tunnel's state because the failure impacts only a subset of branches. Because of that, the procedures of Section 9.1.1 of RFC 6513 are applicable when using I-PMSI P-tunnels. That document is a foundation for this document, and its processes all apply here.

ここで説明する手順はオプションであり、特定の（C-S、C-G）状態の候補UMHのリストに特定のPEを含めるか含めないかを決定するために、ダウンストリームPEが各可能なアップストリームPEをルートとするP-tunnelsのステータスを考慮することに基づいています。P-tunnelの現在のステータスがUpであるかどうかを判断できない場合、ステータスは「Downであることがわかっていない」と見なされ、トンネルを使用する試みが許容されるようにUpであるかのように扱われる場合があります。その結果、P-tunnelがDownの場合（セクション3.1を参照）、P-tunnelのルートであるPEはUMH選択の対象になりません。これにより、ダウンストリームPEはフェイルオーバーして、候補リストの次のアップストリームPEを使用します。一部のダウンストリームPEは、障害がブランチのサブセットにのみ影響するため、トンネルの状態に関して異なる結論に達する可能性があります。そのため、I-PMSI P-tunnelsを使用する場合、RFC 6513のセクション9.1.1の手順が適用されます。そのドキュメントはこのドキュメントの基礎であり、そのプロセスはすべてここに適用されます。

There are three options specified in Section 5.1 of RFC 6513 for a downstream PE to select an Upstream PE.

RFC 6513のセクション5.1には、ダウンストリームPEがアップストリームPEを選択するための3つのオプションが指定されています。

The first two options select the Upstream PE from a candidate PE set based either on an IP address or a hashing algorithm. When used together with the optional procedure of considering the P-tunnel status as in this document, a candidate Upstream PE is included in the set if it either:

最初の2つのオプションは、IPアドレスまたはハッシュアルゴリズムに基づいて、候補PEセットからアップストリームPEを選択します。このドキュメントのようにP-tunnelステータスを考慮するオプションの手順と一緒に使用する場合、候補アップストリームPEは、次のいずれかの場合にセットに含まれます。

  • advertises an x-PMSI bound to a tunnel, where the specified tunnel's state is not known to be Down, or,
  • トンネルにバインドされたx-PMSIをアドバタイズし、指定されたトンネルの状態がDownであることがわかっていない場合、または、
  • does not advertise any x-PMSI applicable to the given (C-S,C-G) but has associated a VRF Route Import BGP Extended Community to the unicast VPN route for S. That is necessary to avoid incorrectly invalidating a UMH PE that would use a policy where no I-PMSI is advertised for a given VRF and where only S-PMSIs are used. The S-PMSI can be advertised only after the Upstream PE receives a C-multicast route for (C-S,C-G) / (C-*,C-G) to be carried over the advertised S-PMSI.
  • 特定の（C-S、C-G）に適用可能なx-PMSIをアドバタイズしませんが、SのユニキャストVPNルートにVRF Route Import BGP拡張コミュニティを関連付けています。これは、特定のVRFに対してI-PMSIがアドバタイズされず、S-PMSIのみが使用されるポリシーを使用するUMH PEを誤って無効にしないようにするために必要です。S-PMSIは、アップストリームPEがアドバタイズされたS-PMSI上で伝送される（C-S、C-G）/（C-*、C-G）のC-マルチキャストルートを受信した後にのみアドバタイズできます。

If the resulting candidate set is empty, then the procedure is repeated without considering the P-tunnel status.

結果の候補セットが空の場合、P-tunnelステータスを考慮せずに手順が繰り返されます。

The third option uses the installed UMH Route (i.e., the "best" route towards the C-root) as the Selected UMH Route, and its originating PE is the selected Upstream PE. With the optional procedure of considering P-tunnel status as in this document, the Selected UMH Route is the best one among those whose originating PE's P-tunnel is not "down". If that does not exist, the installed UMH Route is selected regardless of the P-tunnel status.

3番目のオプションは、インストールされたUMHルート（つまり、C-rootへの「最良」のルート）を選択されたUMHルートとして使用し、その発信PEが選択されたアップストリームPEになります。このドキュメントのようにP-tunnelステータスを考慮するオプションの手順を使用すると、選択されたUMHルートは、発信PEのP-tunnelが「ダウン」していないものの中で最良のものになります。それが存在しない場合、P-tunnelステータスに関係なく、インストールされたUMHルートが選択されます。

3.1. Determining the Status of a Tunnel​

Different factors can be considered to determine the "status" of a P-tunnel and are described in the following subsections. The optional procedures described in this section also handle the case when the downstream PEs do not all apply the same rules to define what the status of a P-tunnel is (please see Section 6), and some of them will produce a result that may be different for different downstream PEs. Thus, the "status" of a P-tunnel in this section is not a characteristic of the tunnel in itself but is the tunnel status, as seen from a particular downstream PE. Additionally, some of the following methods determine the ability of a downstream PE to receive traffic on the P-tunnel and not specifically on the status of the P-tunnel itself. That could be referred to as "P-tunnel reception status", but for simplicity, we will use the terminology of P-tunnel "status" for all of these methods.

P-tunnelの「ステータス」を決定するためにさまざまな要因を考慮することができ、次のサブセクションで説明します。このセクションで説明するオプションの手順は、ダウンストリームPEがすべて同じルールを適用してP-tunnelのステータスを定義しない場合（セクション6を参照）も処理し、その一部はダウンストリームPEごとに異なる結果を生成する可能性があります。したがって、このセクションのP-tunnelの「ステータス」はトンネル自体の特性ではなく、特定のダウンストリームPEから見たトンネルステータスです。さらに、次の方法の一部は、P-tunnel自体のステータスではなく、ダウンストリームPEがP-tunnelでトラフィックを受信する能力を決定します。これは「P-tunnel受信ステータス」と呼ばれることもありますが、簡単にするために、これらすべての方法にP-tunnel「ステータス」という用語を使用します。

Depending on the criteria used to determine the status of a P-tunnel, there may be an interaction with another resiliency mechanism used for the P-tunnel itself, and the UMH update may happen immediately or may need to be delayed. Each particular case is covered in each separate subsection below.

P-tunnelのステータスを決定するために使用される基準に応じて、P-tunnel自体に使用される別の回復力メカニズムとの相互作用がある可能性があり、UMHの更新がすぐに行われる場合や遅延が必要な場合があります。それぞれの特定のケースについては、以下の各サブセクションで説明します。

An implementation may support any combination of the methods described in this section and provide a network operator with control to choose which one to use in the particular deployment.

実装は、このセクションで説明されている方法の任意の組み合わせをサポートし、ネットワークオペレーターに、特定の展開で使用する方法を選択する制御を提供できます。

3.1.1. MVPN Tunnel Root Tracking​

When determining if the status of a P-tunnel is Up, a condition to consider is whether the root of the tunnel, as specified in the x-PMSI Tunnel attribute, is reachable through unicast routing tables. In this case, the downstream PE can immediately update its UMH when the reachability condition changes.

P-tunnelのステータスがUpであるかどうかを判断するときに考慮すべき条件は、x-PMSIトンネル属性で指定されているトンネルのルートがユニキャストルーティングテーブルを介して到達可能かどうかです。この場合、ダウンストリームPEは、到達可能性条件が変更されたときにUMHをすぐに更新できます。

That is similar to BGP next-hop tracking for VPN routes, except that the address considered is not the BGP next-hop address but the root address in the x-PMSI Tunnel attribute. BGP next-hop tracking monitors BGP nexthops.

これはVPNルートのBGPネクストホップトラッキングに似ていますが、考慮されるアドレスはBGPネクストホップアドレスではなく、x-PMSIトンネル属性のルートアドレスである点が異なります。BGPネクストホップトラッキングはBGPネクストホップを監視します。

To determine the status of a P-tunnel, the downstream PE can check the status of the link that it uses to reach the Upstream PE. If the link is down, the P-tunnel status is considered Down.

P-tunnelのステータスを決定するために、ダウンストリームPEは、アップストリームPEに到達するために使用するリンクのステータスを確認できます。リンクがダウンしている場合、P-tunnelステータスはDownと見なされます。

3.1.3. P2MP RSVP-TE Tunnels​

For Point-to-Multipoint (P2MP) RSVP-TE tunnels, the status of the tunnel can be determined by the state of the RSVP-TE Label Switched Path (LSP). If the LSP is down, the P-tunnel status is considered Down.

ポイントツーマルチポイント（P2MP）RSVP-TEトンネルの場合、トンネルのステータスは、RSVP-TEラベルスイッチパス（LSP）の状態によって決定できます。LSPがダウンしている場合、P-tunnelステータスはDownと見なされます。

3.1.4. Leaf-Initiated P-Tunnels​

For leaf-initiated P-tunnels, the status can be determined by the state of the signaling protocol used to set up the tunnel.

リーフ開始P-tunnelsの場合、ステータスは、トンネルの設定に使用されるシグナリングプロトコルの状態によって決定できます。

3.1.5. (C-S,C-G) Counter Information​

The status of a P-tunnel can also be inferred from the traffic statistics for a specific (C-S,C-G). If the traffic rate drops below a certain threshold, the P-tunnel status can be considered Down.

P-tunnelのステータスは、特定の（C-S、C-G）のトラフィック統計から推測することもできます。トラフィックレートが特定のしきい値を下回る場合、P-tunnelステータスはDownと見なすことができます。

3.1.6. BFD Discriminator Attribute​

This document defines a new BGP Attribute, BFD Discriminator, which can be used to associate a BFD session with a P-tunnel. The status of the BFD session determines the status of the P-tunnel.

このドキュメントでは、新しいBGP属性であるBFD Discriminatorを定義しています。これを使用して、BFDセッションをP-tunnelに関連付けることができます。BFDセッションのステータスによって、P-tunnelのステータスが決まります。

In some cases, it may be useful to associate a BFD discriminator with a specific PE-CE link. This allows the downstream PE to monitor the status of the link to the CE using BFD.

場合によっては、BFD識別子を特定のPE-CEリンクに関連付けると便利なことがあります。これにより、ダウンストリームPEはBFDを使用してCEへのリンクのステータスを監視できます。

3.1.8. Operational Considerations for Monitoring a P-Tunnel's Status​

When monitoring the status of a P-tunnel, care must be taken to avoid false positives and to ensure that the monitoring mechanism does not introduce excessive overhead.

P-tunnelのステータスを監視するときは、誤検知を回避し、監視メカニズムが過度のオーバーヘッドをもたらさないように注意する必要があります。

4. Standby C-Multicast Route​

This section describes an optional BGP extension, a new Standby PE Community, that can speed up failover by not requiring any Multicast VPN (MVPN) routing message exchange at recovery time.

このセクションでは、オプションのBGP拡張機能である新しいStandby PEコミュニティについて説明します。これにより、回復時にマルチキャストVPN（MVPN）ルーティングメッセージの交換が不要になり、フェイルオーバーを高速化できます。

4.1. Downstream PE Behavior​

A downstream PE that supports the Standby PE Community can advertise a C-multicast route to a Standby Upstream PE. This allows the Standby Upstream PE to be pre-programmed with the necessary state to forward traffic for the (C-S,C-G).

Standby PEコミュニティをサポートするダウンストリームPEは、Standby Upstream PEにC-マルチキャストルートをアドバタイズできます。これにより、Standby Upstream PEは、（C-S、C-G）のトラフィックを転送するために必要な状態で事前にプログラムできます。

4.2. Upstream PE Behavior​

An Upstream PE that receives a C-multicast route with the Standby PE Community MUST install the state for the (C-S,C-G) but MUST NOT forward traffic until it is selected as the UMH.

Standby PEコミュニティでC-マルチキャストルートを受信するアップストリームPEは、（C-S、C-G）の状態をインストールする必要がありますが、UMHとして選択されるまでトラフィックを転送してはなりません（MUST NOT）。

4.3. Reachability Determination​

The downstream PE determines the reachability of the Upstream PE and the Standby Upstream PE using the mechanisms described in Section 3.

ダウンストリームPEは、セクション3で説明されているメカニズムを使用して、アップストリームPEおよびスタンバイアップストリームPEの到達可能性を決定します。

4.4. Inter-AS​

This section describes the procedures for Inter-AS scenarios.

このセクションでは、Inter-ASシナリオの手順について説明します。

4.4.1. Inter-AS Procedures for Downstream PEs, ASBR Fast Failover​

In Inter-AS scenarios, the downstream PE can use the Standby PE Community to advertise C-multicast routes to ASBRs.

Inter-ASシナリオでは、ダウンストリームPEはStandby PEコミュニティを使用して、C-マルチキャストルートをASBRにアドバタイズできます。

4.4.2. Inter-AS Procedures for ASBRs​

ASBRs can use the Standby PE Community to advertise C-multicast routes to other ASBRs or to Upstream PEs.

ASBRは、Standby PEコミュニティを使用して、他のASBRまたはアップストリームPEにC-マルチキャストルートをアドバタイズできます。

5. Hot Root Standby​

This section describes a "hot root standby" mechanism that can be used to improve failover time in MVPN. The approach combines mechanisms defined in Sections 3 and 4 and has similarities with the solution described in [RFC7431] to improve failover times when PIM routing is used in a network given some topology and metric constraints.

このセクションでは、MVPNのフェイルオーバー時間を改善するために使用できる「ホットルートスタンバイ」メカニズムについて説明します。このアプローチは、セクション3および4で定義されたメカニズムを組み合わせたものであり、[RFC7431]で説明されているソリューションと類似しており、特定のトポロジおよびメトリックの制約があるネットワークでPIMルーティングが使用されている場合のフェイルオーバー時間を改善します。

6. Duplicate Packets​

When using the fast failover mechanisms described in this document, it is possible for duplicate packets to be delivered to the receiver. This section discusses the implications of duplicate packets and how to mitigate them.

このドキュメントで説明されている高速フェイルオーバーメカニズムを使用する場合、重複したパケットが受信者に配信される可能性があります。このセクションでは、重複パケットの影響とそれを軽減する方法について説明します。

7. IANA Considerations​

7.1. Standby PE Community​

IANA has assigned a BGP Community value for the Standby PE Community.

IANAは、Standby PEコミュニティにBGPコミュニティ値を割り当てました。

7.2. BFD Discriminator​

IANA has assigned a BGP Attribute type code for the BFD Discriminator Attribute.

IANAは、BFD Discriminator属性にBGP属性タイプコードを割り当てました。

7.3. BFD Discriminator Optional TLV Type​

IANA has assigned a Type value for the BFD Discriminator Optional TLV in the BGP Tunnel Encapsulation Attribute.

IANAは、BGPトンネルカプセル化属性のBFD DiscriminatorオプションTLVにタイプ値を割り当てました。

8. Security Considerations​

The security considerations for this document are similar to those for [RFC6513] and [RFC6514]. In addition, the use of BFD introduces new security considerations related to the authentication and integrity of BFD packets.

このドキュメントのセキュリティに関する考慮事項は、[RFC6513]および[RFC6514]の考慮事項と同様です。さらに、BFDの使用により、BFDパケットの認証と整合性に関連する新しいセキュリティに関する考慮事項が導入されます。

9. References​

9.1. Normative References​

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

[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, https://www.rfc-editor.org/info/rfc6513.

[RFC6514] Aggarwal, R., Ed., Rosen, E., Ed., Morin, T., Ed., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, https://www.rfc-editor.org/info/rfc6514.

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

[RFC8562] Katz, D., Ward, D., and S. Pallagatti, Ed., "Bidirectional Forwarding Detection (BFD) for Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, April 2019, https://www.rfc-editor.org/info/rfc8562.

9.2. Informative References​

[RFC7431] Karan, A., Wijnands, IJ., Ed., and E. Rosen, "Multicast-Only Fast Reroute", RFC 7431, DOI 10.17487/RFC7431, August 2015, https://www.rfc-editor.org/info/rfc7431.

[RFC7841] Halpern, J., Ed., Resnick, P., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, and Boilerplates", RFC 7841, DOI 10.17487/RFC7841, May 2016, https://www.rfc-editor.org/info/rfc7841.

Acknowledgments​

The authors would like to thank...

著者は、...に感謝します。

Contributors​

...

貢献者...

Authors' Addresses​

Thomas Morin (editor) Orange Email: [email protected]

Robert Kebler (editor) Juniper Networks Email: [email protected]

Greg Mirsky (editor) ZTE Corp. Email: [email protected]

に最終更新