[要約] RFC 8379は、OSPF Graceful Link Shutdownの仕様を定義しています。この仕様の目的は、ネットワークのリンクを優雅にシャットダウンするための手法を提供することです。
Internet Engineering Task Force (IETF) S. Hegde
Request for Comments: 8379 Juniper Networks, Inc.
Category: Standards Track P. Sarkar
ISSN: 2070-1721 Arrcus, Inc.
H. Gredler
RtBrick Inc.
M. Nanduri
ebay Corporation
L. Jalil
Verizon
May 2018
OSPF Graceful Link Shutdown
OSPFグレースフルリンクシャットダウン
Abstract
概要
When a link is being prepared to be taken out of service, the traffic needs to be diverted from both ends of the link. Increasing the metric to the highest value on one side of the link is not sufficient to divert the traffic flowing in the other direction.
リンクがサービスを停止する準備ができている場合、トラフィックはリンクの両端から迂回する必要があります。リンクの片側でメトリックを最大値に増やすだけでは、反対方向に流れるトラフィックを迂回させるのに十分ではありません。
It is useful for the routers in an OSPFv2 or OSPFv3 routing domain to be able to advertise a link as being in a graceful-shutdown state to indicate impending maintenance activity on the link. This information can be used by the network devices to reroute the traffic effectively.
OSPFv2またはOSPFv3ルーティングドメイン内のルーターがリンクをグレースフルシャットダウン状態にあることをアドバタイズして、リンクのメンテナンスアクティビティが差し迫っていることを示すことができると便利です。ネットワークデバイスはこの情報を使用して、トラフィックを効果的に再ルーティングできます。
This document describes the protocol extensions to disseminate graceful-link-shutdown information in OSPFv2 and OSPFv3.
このドキュメントでは、OSPFv2およびOSPFv3でグレースフルリンクシャットダウン情報を配布するためのプロトコル拡張について説明します。
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/rfc8379.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8379で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Flooding Scope . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4
4.1. OSPFv2 Graceful-Link-Shutdown Sub-TLV . . . . . . . . . . 4
4.2. Remote IPv4 Address Sub-TLV . . . . . . . . . . . . . . . 4
4.3. Local/Remote Interface ID Sub-TLV . . . . . . . . . . . . 5
4.4. OSPFv3 Graceful-Link-Shutdown Sub-TLV . . . . . . . . . . 6
4.5. BGP-LS Graceful-Link-Shutdown TLV . . . . . . . . . . . . 6
4.6. Distinguishing Parallel Links . . . . . . . . . . . . . . 7
5. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 8
5.1. Point-to-Point Links . . . . . . . . . . . . . . . . . . 8
5.2. Broadcast/NBMA Links . . . . . . . . . . . . . . . . . . 9
5.3. Point-to-Multipoint Links . . . . . . . . . . . . . . . . 10
5.4. Unnumbered Interfaces . . . . . . . . . . . . . . . . . . 10
5.5. Hybrid Broadcast and P2MP Interfaces . . . . . . . . . . 10
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10
7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Overlay Network . . . . . . . . . . . . . . . . . . . . . 11
7.2. Controller-Based Deployments . . . . . . . . . . . . . . 12
7.3. L3VPN Services and Sham Links . . . . . . . . . . . . . . 13
7.4. Hub and Spoke Deployment . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
This document describes a mechanism for gracefully taking a link out of service while allowing it to be used if no other path is available. It also provides a mechanism to divert the traffic from both directions of the link.
このドキュメントでは、他のパスが利用できない場合にリンクを使用できるようにする一方で、リンクを適切にサービスから外すためのメカニズムについて説明します。また、リンクの両方向からトラフィックを迂回させるメカニズムも提供します。
Many OSPFv2 or OSPFv3 deployments run on overlay networks provisioned by means of pseudowires or L2 circuits. Prior to devices in the underlying network going offline for maintenance, it is useful to divert the traffic away from the node before maintenance is actually performed. Since the nodes in the underlying network are not visible to OSPF, the existing stub-router mechanism described in [RFC6987] cannot be used. In a service provider's network, there may be many CE-to-CE connections that run over a single PE. It is cumbersome to change the metric on every CE-to-CE connection in both directions. This document provides a mechanism to change the metric of the link on the remote side and also use the link as a last-resort link if no alternate paths are available. An application specific to this use case is described in detail in Section 7.1.
多くのOSPFv2またはOSPFv3展開は、疑似配線またはL2回線によってプロビジョニングされたオーバーレイネットワークで実行されます。基盤となるネットワーク内のデバイスがメンテナンスのためにオフラインになる前に、メンテナンスが実際に実行される前に、トラフィックをノードからそらすと便利です。基盤となるネットワークのノードはOSPFから見えないため、[RFC6987]で説明されている既存のスタブルーターメカニズムは使用できません。サービスプロバイダーのネットワークでは、単一のPE上で実行されるCE間の接続が多数存在する場合があります。双方向のすべてのCE-to-CE接続でメトリックを変更するのは面倒です。このドキュメントは、リモート側のリンクのメトリックを変更するメカニズムを提供します。また、代替パスが利用できない場合は、リンクを最後の手段として使用します。このユースケースに固有のアプリケーションについては、セクション7.1で詳しく説明します。
This document provides mechanisms to advertise graceful-link-shutdown state in the flexible encodings provided by "OSPFv2 Prefix/Link Attribute Advertisement" [RFC7684] and the E-Router-LSA [RFC8362] for OSPFv3. Throughout this document, OSPF is used when the text applies to both OSPFv2 and OSPFv3. OSPFv2 or OSPFv3 is used when the text is specific to one version of the OSPF protocol.
このドキュメントでは、OSPFv3の「OSPFv2プレフィックス/リンク属性アドバタイズメント」[RFC7684]およびE-Router-LSA [RFC8362]によって提供される柔軟なエンコーディングで、graceful-link-shutdown状態をアドバタイズするメカニズムを提供します。このドキュメント全体を通して、テキストがOSPFv2とOSPFv3の両方に適用される場合、OSPFが使用されます。 OSPFv2またはOSPFv3は、テキストがOSPFプロトコルの1つのバージョンに固有である場合に使用されます。
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]で説明されているように解釈されます。
The motivation of this document is to reduce manual intervention during maintenance activities. The following objectives help to accomplish this in a range of deployment scenarios.
このドキュメントの目的は、メンテナンス作業中の手動による介入を減らすことです。次の目的は、さまざまな展開シナリオでこれを達成するのに役立ちます。
1. Advertise impending maintenance activity so that traffic from both directions can be diverted away from the link.
1. 差し迫ったメンテナンスアクティビティをアドバタイズして、両方向からのトラフィックをリンクから迂回できるようにします。
2. Allow the solution to be backward compatible so that nodes that do not understand the new advertisement do not cause routing loops.
2. 新しいアドバタイズを理解しないノードがルーティングループを引き起こさないように、ソリューションに下位互換性を持たせます。
3. Advertise the maintenance activity to other nodes in the network so that Label Switched Path (LSP) ingress routers/controllers can learn about the impending maintenance activity and apply specific policies to reroute the LSPs for deployments based on Traffic Engineering (TE).
3. ネットワーク内の他のノードにメンテナンスアクティビティをアドバタイズして、ラベルスイッチドパス（LSP）の入力ルーター/コントローラーが差し迫ったメンテナンスアクティビティについて学習し、特定のポリシーを適用して、トラフィックエンジニアリング（TE）に基づく展開用にLSPを再ルーティングできるようにします。
4. Allow the link to be used as a last-resort link to prevent traffic disruption when alternate paths are not available.
4. 代替パスが利用できないときにトラフィックの中断を防ぐために、リンクをラストリゾートリンクとして使用できるようにします。
The graceful-link-shutdown information is flooded in an area-scoped Extended Link Opaque LSA [RFC7684] for OSPFv2 and in an E-Router-LSA for OSPFv3 [RFC8362]. The Graceful-Link-Shutdown sub-TLV MAY be processed by the head-end nodes or the controller as described in the Section 7. The procedures for processing the Graceful-Link-Shutdown sub-TLV are described in Section 5.
グレースフルリンクシャットダウン情報は、OSPFv2の場合はエリアスコープの拡張リンク不透明LSA [RFC7684]に、OSPFv3の場合はE-Router-LSAにフラッディングされます[RFC8362]。 Graceful-Link-ShutdownサブTLVは、セクション7で説明されているように、ヘッドエンドノードまたはコントローラで処理される場合があります（MAY）。Graceful-Link-ShutdownサブTLVの処理手順については、セクション5で説明されています。
The Graceful-Link-Shutdown sub-TLV identifies the link as being gracefully shutdown. It is advertised in the Extended Link TLV of the Extended Link Opaque LSA as defined in [RFC7684].
グレースフルリンクシャットダウンサブTLVは、リンクが正常にシャットダウンされていることを識別します。 [RFC7684]で定義されているように、拡張リンク不透明LSAの拡張リンク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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Graceful-Link-Shutdown Sub-TLV for OSPFv2
図1：OSPFv2のGraceful-Link-Shutdown Sub-TLV
Type: 7
タイプ：7
Length: 0
長さ：0
This sub-TLV specifies the IPv4 address of the remote endpoint on the link. It is advertised in the Extended Link TLV as defined in [RFC7684]. This sub-TLV is optional and MAY be advertised in an area-scoped Extended Link Opaque LSA to identify the link when there are multiple parallel links between two nodes.
このサブTLVは、リンク上のリモートエンドポイントのIPv4アドレスを指定します。 [RFC7684]で定義されているように、拡張リンクTLVでアドバタイズされます。このサブTLVはオプションであり、2つのノード間に複数の並列リンクがある場合にリンクを識別するために、エリアスコープの拡張リンク不透明LSAでアドバタイズされる場合があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Remote IPv4 Address Sub-TLV
図2：リモートIPv4アドレスサブTLV
Type: 8
タイプ：8
Length: 4
長さ：4
Value: Remote IPv4 address. The remote IPv4 address is used to identify a particular link on the remote side when there are multiple parallel links between two nodes.
値：リモートIPv4アドレス。 2つのノード間に複数の並列リンクがある場合、リモートIPv4アドレスは、リモート側の特定のリンクを識別するために使用されます。
This sub-TLV specifies Local and Remote Interface IDs. It is advertised in the Extended Link TLV as defined in [RFC7684]. This sub-TLV is optional and MAY be advertised in an area-scoped Extended Link Opaque LSA to identify the link when there are multiple parallel unnumbered links between two nodes. The Local Interface ID is generally readily available. One of the mechanisms to obtain the Remote Interface ID is described in [RFC4203].
このサブTLVは、ローカルおよびリモートインターフェイスIDを指定します。 [RFC7684]で定義されているように、拡張リンクTLVでアドバタイズされます。このサブTLVはオプションであり、2つのノード間に複数の並列の番号なしリンクがある場合にリンクを識別するために、エリアスコープの拡張リンク不透明LSAでアドバタイズできます（MAY）。ローカルインターフェイスIDは、通常、すぐに利用できます。リモートインターフェイスIDを取得するメカニズムの1つは、[RFC4203]で説明されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Local/Remote Interface ID Sub-TLV
図3：ローカル/リモートインターフェイスIDサブTLV
Type: 9
タイプ：9
Length: 8
長さ：8
Value: 4 octets of the Local Interface ID followed by 4 octets of the Remote Interface ID.
値：ローカルインターフェースIDの4オクテットと、それに続くリモートインターフェースIDの4オクテット。
The Graceful-Link-Shutdown sub-TLV is carried in the Router-Link TLV as defined in [RFC8362] for OSPFv3. The Router-Link TLV contains the Neighbor Interface ID and can uniquely identify the link on the remote node.
Graceful-Link-ShutdownサブTLVは、OSPFv3の[RFC8362]で定義されているように、Router-Link TLVで伝送されます。 Router-Link TLVにはネイバーインターフェイスIDが含まれており、リモートノード上のリンクを一意に識別できます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Graceful-Link-Shutdown Sub-TLV for OSPFv3
図4：OSPFv3のGraceful-Link-Shutdown Sub-TLV
Type: 8
タイプ：8
Length: 0
長さ：0
BGP-LS as defined in [RFC7752] is a mechanism that distributes network information to the external entities using the BGP routing protocol. Graceful link shutdown is important link information that the external entities can use for various use cases as defined in Section 7. BGP Link Network Layer Reachability Information (NLRI) is used to carry the link information. A new TLV called "Graceful-Link-Shutdown" is defined to describe the link attribute corresponding to graceful-link-shutdown state. The TLV format is as described in Section 3.1 of [RFC7752]. There is no Value field, and the Length field is set to zero for this TLV.
[RFC7752]で定義されているBGP-LSは、BGPルーティングプロトコルを使用して外部エンティティにネットワーク情報を配信するメカニズムです。グレースフルリンクシャットダウンは、セクション7で定義されているように、外部エンティティがさまざまなユースケースで使用できる重要なリンク情報です。リンク情報の伝達には、BGPリンクネットワーク層到達可能性情報（NLRI）が使用されます。 「Graceful-Link-Shutdown」という新しいTLVが定義され、graceful-link-shutdown状態に対応するリンク属性が記述されます。 TLV形式は、[RFC7752]のセクション3.1に記載されています。 Valueフィールドはなく、Lengthフィールドはこの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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Graceful-Link-Shutdown TLV for BGP-LS
図5：BGP-LSのグレースフルリンクシャットダウンTLV
Type: 1121
タイプ：1121
Length: 0
長さ：0
++++++++++I.w I.y+++++++++++
|Router A|------------------|Router B |
| |------------------| |
++++++++++I.x I.z+++++++++++
Figure 6: Parallel Links
図6：並列リンク
Consider two routers, A and B, connected with two parallel point-to-point interfaces. I.w and I.x represent the interface address on Router A's side, and I.y and I.z represent interface addresses on Router B's side. The Extended Link Opaque LSA as defined in [RFC7684] describes links using Link Type, Link ID, and Link Data. For example, a link with the address I.w is described as below on Router A.
2つのパラレルポイントツーポイントインターフェイスに接続された2つのルーターAとBについて考えてみます。 I.wとI.xはルーターA側のインターフェースアドレスを表し、I.yとI.zはルーターB側のインターフェースアドレスを表します。 [RFC7684]で定義されているExtended Link Opaque LSAは、リンクタイプ、リンクID、およびリンクデータを使用してリンクを記述します。たとえば、アドレスがI.wのリンクは、ルーターAでは次のように記述されます。
Link Type = Point-to-point
リンクタイプ=ポイントツーポイント
Link ID = Router ID of B
リンクID = BのルーターID
Link Data = I.w
リンクデータ= I.w
A third node (controller or head-end) in the network cannot distinguish the interface on Router B, which is connected to this particular Interface on Router A based on the link information described above. The interface with address I.y or I.z could be chosen due to this ambiguity. In such cases, a Remote IPv4 Address sub-TLV should be originated and added to the Extended Link TLV. The use cases as described in Section 7 require controller or head-end nodes to interpret the graceful-link-shutdown information and hence the need for the Remote IPv4 Address sub-TLV. I.y is carried in the Extended Link TLV, which unambiguously identifies the interface on the remote side. The OSPFv3 Router-Link TLV as described in [RFC8362] contains an Interface ID and a neighbor's Interface ID, which can uniquely identify connecting the interface on the remote side; hence, OSPFv3 does not require a separate remote IPv6 address to be advertised along with the OSPFv3 Graceful-Link-Shutdown sub-TLV.
ネットワークの3番目のノード（コントローラーまたはヘッドエンド）は、上記のリンク情報に基づいて、ルーターAのこの特定のインターフェースに接続されているルーターBのインターフェースを区別できません。このあいまいさにより、アドレスがI.yまたはI.zのインターフェースを選択できます。このような場合、リモートIPv4アドレスサブTLVを作成して、拡張リンクTLVに追加する必要があります。セクション7で説明する使用例では、コントローラまたはヘッドエンドノードがグレースフルリンクシャットダウン情報を解釈する必要があるため、リモートIPv4アドレスサブTLVが必要です。 I.yは拡張リンクTLVで伝送され、リモート側のインターフェースを明確に識別します。 [RFC8362]で説明されているOSPFv3ルーターリンクTLVには、インターフェイスIDとネイバーのインターフェイスIDが含まれています。これにより、リモート側のインターフェイスの接続を一意に識別できます。したがって、OSPFv3では、OSPFv3 Graceful-Link-ShutdownサブTLVと共にアドバタイズされる個別のリモートIPv6アドレスは必要ありません。
As defined in [RFC7684], every link on the node will have a separate Extended Link Opaque LSA. The node that has the link to be taken out of service MUST advertise the Graceful-Link-Shutdown sub-TLV in the Extended Link TLV of the Extended Link Opaque LSA for OSPFv2, as defined in [RFC7684], and in the Router-Link TLV of E-Router-LSA for OSPFv3. The Graceful-Link-Shutdown sub-TLV indicates that the link identified by the sub-TLV is subjected to maintenance.
[RFC7684]で定義されているように、ノード上のすべてのリンクには個別の拡張リンク不透明LSAがあります。 [RFC7684]で定義されているように、OSPFv2の拡張リンクOpaque LSAの拡張リンクTLVとルーターリンクでGraceful-Link-ShutdownサブTLVをアドバタイズする必要があります。 OSPFv3のE-Router-LSAのTLV。グレースフルリンクシャットダウンサブTLVは、サブTLVによって識別されたリンクがメンテナンスの対象であることを示します。
For the purposes of changing the metric OSPFv2 and OSPFv3 Router-LSAs need to be reoriginated. To change the Traffic Engineering metric, TE Opaque LSAs in OSPFv2 [RFC3630] and Intra-area-TE-LSAs in OSPFv3 [RFC5329] need to be reoriginated.
メトリックを変更するために、OSPFv2およびOSPFv3ルーターLSAを再発信する必要があります。トラフィックエンジニアリングメトリックを変更するには、OSPFv2 [RFC3630]のTE Opaque LSAおよびOSPFv3 [RFC5329]のエリア内TE-LSAを再生成する必要があります。
The graceful-link-shutdown information is advertised as a property of the link and is flooded through the area. This information can be used by ingress routers or controllers to take special actions. An application specific to this use case is described in Section 7.2.
グレースフルリンクシャットダウン情報は、リンクのプロパティとしてアドバタイズされ、エリア全体にフラッディングされます。この情報は、入口ルーターまたはコントローラーが特別なアクションを実行するために使用できます。このユースケースに固有のアプリケーションについては、セクション7.2で説明します。
When a link is ready to carry traffic, the Graceful-Link-Shutdown sub-TLV MUST be removed from the Extended Link TLV/Router-Link TLV, and the corresponding LSAs MUST be readvertised. Similarly, the metric MUST be set to original values, and the corresponding LSAs MUST be readvertised.
リンクがトラフィックを伝送する準備ができたら、Graceful-Link-ShutdownサブTLVを拡張リンクTLV /ルーターリンクTLVから削除する必要があり、対応するLSAを再アドバタイズする必要があります。同様に、メトリックは元の値に設定する必要があり、対応するLSAを再アドバタイズする必要があります。
The procedures described in this document may be used to divert the traffic away from the link in scenarios other than link-shutdown or link-replacement activity.
このドキュメントで説明されている手順を使用して、リンクシャットダウンまたはリンク交換アクティビティ以外のシナリオで、トラフィックをリンクからそらすことができます。
The precise action taken by the remote node at the other end of the link identified for graceful-shutdown depends on the link type.
graceful-shutdownとして識別されたリンクの反対側のリモートノードによって実行される正確なアクションは、リンクタイプによって異なります。
The node that has the link to be taken out of service MUST set the metric of the link to MaxLinkMetric (0xffff) and reoriginate its Router-LSA. The Traffic Engineering metric of the link SHOULD be set to (0xffffffff), and the node SHOULD reoriginate the corresponding TE Link Opaque LSAs. When a Graceful-Link-Shutdown sub-TLV is received for a point-to-point link, the remote node MUST identify the local link that corresponds to the graceful-shutdown link and set its metric to MaxLinkMetric (0xffff), and the remote node MUST reoriginate its Router-LSA with the changed metric. When TE is enabled, the Traffic Engineering metric of the link SHOULD be set to (0xffffffff) and follow the procedures in [RFC5817]. Similarly, the remote node SHOULD set the Traffic Engineering metric of the link to 0xffffffff and SHOULD reoriginate the TE Link Opaque LSA for the link with the new value.
サービスから外されるリンクを持つノードは、リンクのメトリックをMaxLinkMetric（0xffff）に設定し、ルーターLSAを再発信する必要があります。リンクのトラフィックエンジニアリングメトリックは（0xffffffff）に設定する必要があり（SHOULD）、ノードは対応するTE Link Opaque LSAを再生成する必要があります（SHOULD）。ポイントツーポイントリンクのGraceful-Link-ShutdownサブTLVを受信した場合、リモートノードは、graceful-shutdownリンクに対応するローカルリンクを識別し、そのメトリックをMaxLinkMetric（0xffff）に設定する必要があります。ノードは変更されたメトリックでルーターLSAを再発信する必要があります。 TEが有効になっている場合、リンクのトラフィックエンジニアリングメトリックは（0xffffffff）に設定する必要があり（SHOULD）、[RFC5817]の手順に従います。同様に、リモートノードは、リンクのトラフィックエンジニアリングメトリックを0xffffffffに設定する必要があり（SHOULD）、新しい値でリンクのTE Link Opaque LSAを再生成する必要があります（SHOULD）。
The Extended Link Opaque LSAs and the Extended Link TLV are not scoped for multi-topology [RFC4915]. In multi-topology deployments [RFC4915], the Graceful-Link-Shutdown sub-TLV advertised in an Extended Link Opaque LSA corresponds to all the topologies that include the link. The receiver node SHOULD change the metric in the reverse direction for all the topologies that include the remote link and reoriginate the Router-LSA as defined in [RFC4915].
Extended Link Opaque LSAとExtended Link TLVは、マルチトポロジ[RFC4915]のスコープではありません。マルチトポロジ展開[RFC4915]では、Extended Link Opaque LSAで通知されるGraceful-Link-ShutdownサブTLVは、リンクを含むすべてのトポロジに対応します。 [RFC4915]で定義されているように、受信ノードはリモートリンクを含むすべてのトポロジのメトリックを逆方向に変更し、ルーターLSAを再発信する必要があります（SHOULD）。
When the originator of the Graceful-Link-Shutdown sub-TLV purges the Extended Link Opaque LSA or reoriginates it without the Graceful-Link-Shutdown sub-TLV, the remote node must reoriginate the appropriate LSAs with the metric and TE metric values set to their original values.
Graceful-Link-ShutdownサブTLVのオリジネーターがExtended Link Opaque LSAをパージするか、Graceful-Link-ShutdownサブTLVなしでそれを再生成する場合、リモートノードは、メトリックとTEメトリック値を次のように設定して適切なLSAを再生成する必要があります。それらの元の値。
Broadcast or Non-Broadcast Multi-Access (NBMA) networks in OSPF are represented by a star topology where the Designated Router (DR) is the central point to which all other routers on the broadcast or NBMA network logically connect. As a result, routers on the broadcast or NBMA network advertise only their adjacency to the DR. Routers that do not act as DRs do not form or advertise adjacencies with each other. For the broadcast links, the MaxLinkMetric on the remote link cannot be changed since all the neighbors are on same link. Setting the link cost to MaxLinkMetric would impact all paths that traverse any of the neighbors connected on that broadcast link.
OSPFのブロードキャストまたは非ブロードキャストマルチアクセス（NBMA）ネットワークは、指定ルーター（DR）がブロードキャストまたはNBMAネットワーク上の他のすべてのルーターが論理的に接続する中心点であるスタートポロジで表されます。その結果、ブロードキャストまたはNBMAネットワーク上のルーターは、隣接関係のみをDRにアドバタイズします。 DRとして機能しないルーターは、相互に隣接関係を形成したり通知したりしません。ブロードキャストリンクの場合、すべてのネイバーが同じリンク上にあるため、リモートリンクのMaxLinkMetricは変更できません。リンクコストをMaxLinkMetricに設定すると、そのブロードキャストリンクに接続されているネイバーのいずれかを通過するすべてのパスに影響します。
The node that has the link to be taken out of service MUST set the metric of the link to MaxLinkMetric (0xffff) and reoriginate the Router-LSA. The Traffic Engineering metric of the link SHOULD be set to (0xffffffff), and the node SHOULD reoriginate the corresponding TE Link Opaque LSAs. For a broadcast link, the two-part metric as described in [RFC8042] is used. The node originating the Graceful-Link-Shutdown sub-TLV MUST set the metric in the Network-to-Router Metric sub-TLV to MaxLinkMetric (0xffff) for OSPFv2 and OSPFv3 and reoriginate the corresponding LSAs. The nodes that receive the two-part metric should follow the procedures described in [RFC8042]. The backward-compatibility procedures described in [RFC8042] should be followed to ensure loop-free routing.
サービスから外されるリンクを持つノードは、リンクのメトリックをMaxLinkMetric（0xffff）に設定し、ルーターLSAを再発信する必要があります。リンクのトラフィックエンジニアリングメトリックは（0xffffffff）に設定する必要があり（SHOULD）、ノードは対応するTE Link Opaque LSAを再生成する必要があります（SHOULD）。ブロードキャストリンクでは、[RFC8042]で説明されている2つの部分からなるメトリックが使用されます。 Graceful-Link-ShutdownサブTLVを発信するノードは、OSPFv2およびOSPFv3のNetwork-to-RouterメトリックサブTLVのメトリックをMaxLinkMetric（0xffff）に設定し、対応するLSAを再発信する必要があります。 2つの部分からなるメトリックを受信するノードは、[RFC8042]で説明されている手順に従う必要があります。 [RFC8042]で説明されている下位互換性の手順に従って、ループのないルーティングを確保する必要があります。
Operation for the point-to-multipoint (P2MP) links is similar to the point-to-point links. When a Graceful-Link-Shutdown sub-TLV is received for a point-to-multipoint link, the remote node MUST identify the neighbor that corresponds to the graceful-shutdown link and set its metric to MaxLinkMetric (0xffff). The remote node MUST reoriginate the Router-LSA with the changed metric for the corresponding neighbor.
ポイントツーマルチポイント（P2MP）リンクの操作は、ポイントツーポイントリンクに似ています。ポイントツーマルチポイントリンクのGraceful-Link-ShutdownサブTLVを受信した場合、リモートノードは、graceful-shutdownリンクに対応するネイバーを識別し、そのメトリックをMaxLinkMetric（0xffff）に設定する必要があります。リモートノードは、対応するネイバーの変更されたメトリックでルーターLSAを再発信する必要があります。
Unnumbered interfaces do not have a unique IP address and borrow their address from other interfaces. [RFC2328] describes procedures to handle unnumbered interfaces in the context of the Router-LSA. We apply a similar procedure to the Extended Link TLV advertising the Graceful-Link-Shutdown sub-TLV in order to handle unnumbered interfaces. The Link-Data field in the Extended Link TLV includes the Local Interface ID instead of the IP address. The Local/Remote Interface ID sub-TLV MUST be advertised when there are multiple parallel unnumbered interfaces between two nodes. One of the mechanisms to obtain the Interface ID of the remote side is defined in [RFC4203].
アンナンバードインターフェイスには一意のIPアドレスがなく、他のインターフェイスからアドレスを借用します。 [RFC2328]は、ルータLSAのコンテキストで番号付けされていないインターフェイスを処理する手順を説明しています。アンナンバードインターフェイスを処理するために、Graceful-Link-ShutdownサブTLVをアドバタイズする拡張リンクTLVに同様の手順を適用します。拡張リンクTLVのリンクデータフィールドには、IPアドレスではなくローカルインターフェイスIDが含まれています。ローカル/リモートインターフェイスIDサブTLVは、2つのノード間に複数のパラレルアンナンバードインターフェイスがある場合にアドバタイズする必要があります。リモート側のインターフェイスIDを取得するメカニズムの1つは、[RFC4203]で定義されています。
Hybrid Broadcast and P2MP interfaces represent a broadcast network modeled as P2MP interfaces. [RFC6845] describes procedures to handle these interfaces. Operation for the Hybrid interfaces is similar to operation for the P2MP interfaces. When a Graceful-Link-Shutdown sub-TLV is received for a hybrid link, the remote node MUST identify the neighbor that corresponds to the graceful-shutdown link and set its metric to MaxLinkMetric (0xffff). All the remote nodes connected to the originator MUST reoriginate the Router-LSA with the changed metric for the neighbor.
ハイブリッドブロードキャストおよびP2MPインターフェイスは、P2MPインターフェイスとしてモデル化されたブロードキャストネットワークを表します。 [RFC6845]は、これらのインターフェースを処理する手順を説明しています。ハイブリッドインターフェイスの操作は、P2MPインターフェイスの操作と似ています。ハイブリッドリンクのグレースフルリンクシャットダウンサブTLVを受信した場合、リモートノードはグレースフルシャットダウンリンクに対応するネイバーを識別し、そのメトリックをMaxLinkMetric（0xffff）に設定する必要があります。発信者に接続されているすべてのリモートノードは、変更されたネイバーのメトリックを使用して、Router-LSAを再発信する必要があります。
The mechanisms described in the document are fully backward compatible. It is required that the node adverting the Graceful-Link-Shutdown sub-TLV as well as the node at the remote end of the graceful-shutdown link support the extensions described herein for the traffic to be diverted from the graceful-shutdown link. If the remote node doesn't support the capability, it will still use the graceful-shutdown link, but there are no other adverse effects. In the case of broadcast links using two-part metrics, the backward-compatibility procedures as described in [RFC8042] are applicable.
このドキュメントで説明されているメカニズムは、完全に下位互換性があります。 Graceful-Link-ShutdownサブTLVをアドバタイズするノードとgraceful-shutdownリンクのリモートエンドのノードが、ここで説明する拡張機能をサポートし、トラフィックをgraceful-shutdownリンクから迂回させる必要があります。リモートノードが機能をサポートしていない場合でも、グレースフルシャットダウンリンクを使用しますが、他の悪影響はありません。 2つの部分からなるメトリックを使用するブロードキャストリンクの場合、[RFC8042]で説明されている下位互換性手順が適用されます。
Many service providers offer L2 services to a customer connecting different locations. The customer's IGP protocol creates a seamless private network (overlay network) across the locations for the customer. Service providers want to offer graceful-shutdown functionality when the PE device is taken out for maintenance. There can be large number of customers attached to a PE node, and the remote endpoints for these L2 attachment circuits are spread across the service provider's network. Changing the metric for all corresponding L2 circuits in both directions is a tedious and error-prone process. The graceful-link-shutdown feature simplifies the process by increasing the metric on the CE-CE overlay link so that traffic in both directions is diverted away from the PE undergoing maintenance. The graceful-link-shutdown feature allows the link to be used as a last-resort link so that traffic is not disrupted when alternate paths are not available.
多くのサービスプロバイダーは、異なる場所を接続する顧客にL2サービスを提供しています。顧客のIGPプロトコルは、顧客の場所全体にシームレスなプライベートネットワーク（オーバーレイネットワーク）を作成します。サービスプロバイダーは、PEデバイスがメンテナンスのために取り出されたときに、適切なシャットダウン機能を提供したいと考えています。 PEノードに接続された多数の顧客が存在する可能性があり、これらのL2接続回線のリモートエンドポイントは、サービスプロバイダーのネットワーク全体に広がっています。対応するすべてのL2回線のメトリックを両方向に変更するのは、面倒でエラーが発生しやすいプロセスです。 graceful-link-shutdown機能は、CE-CEオーバーレイリンクのメトリックを増やすことでプロセスを簡素化し、双方向のトラフィックがメンテナンス中のPEから迂回されるようにします。 graceful-link-shutdown機能を使用すると、リンクをラストリゾートリンクとして使用できるため、代替パスが利用できないときにトラフィックが中断されることはありません。
------PE3---------------PE4------CE3
/ \
/ \
CE1---------PE1----------PE2---------CE2
\
\
------CE4
CE: Customer Edge PE: Provider Edge
CE：カスタマーエッジPE：プロバイダーエッジ
Figure 7: Overlay Network
図7：オーバーレイネットワーク
In the example shown in Figure 7, when the PE1 node is going out of service for maintenance, a service provider sets the PE1 to stub-router state and communicates the pending maintenance action to the overlay customer networks. The mechanisms used to communicate between PE1 and CE1 is outside the scope of this document. CE1 sets the graceful-link-shutdown state on its links connecting CE3, CE2, and CE4, changes the metric to MaxLinkMetric, and reoriginates the corresponding LSA. The remote end of the link at CE3, CE2, and CE4 also set the metric on the link to MaxLinkMetric, and the traffic from both directions gets diverted away from PE1.
図7に示す例では、PE1ノードがメンテナンスのためにサービスを停止すると、サービスプロバイダーはPE1をスタブルーター状態に設定し、保留中のメンテナンスアクションをオーバーレイカスタマーネットワークに通知します。 PE1とCE1間の通信に使用されるメカニズムは、このドキュメントの範囲外です。 CE1は、CE3、CE2、およびCE4を接続するリンクにgraceful-link-shutdown状態を設定し、メトリックをMaxLinkMetricに変更して、対応するLSAを再発信します。 CE3、CE2、およびCE4のリンクのリモートエンドもリンクのメトリックをMaxLinkMetricに設定し、両方向からのトラフィックはPE1から迂回されます。
In controller-based deployments where the controller participates in the IGP protocol, the controller can also receive the graceful-link-shutdown information as a warning that link maintenance is imminent. Using this information, the controller can find alternate paths for traffic that uses the affected link. The controller can apply various policies and reroute the LSPs away from the link undergoing maintenance. If there are no alternate paths satisfying the constraints, the controller might temporarily relax those constraints and put the service on a different path. Increasing the link metric alone does not specify the maintenance activity as the metric could increase in events such as LDP-IGP synchronization. An explicit indication from the router using the Graceful-Link-Shutdown sub-TLV is needed to inform the controller or head-end routers.
コントローラがIGPプロトコルに参加しているコントローラベースの展開では、コントローラは、リンクのメンテナンスが差し迫っていることを警告するグレースフルリンクシャットダウン情報も受信できます。この情報を使用して、コントローラーは影響を受けるリンクを使用するトラフィックの代替パスを見つけることができます。コントローラは、さまざまなポリシーを適用し、メンテナンス中のリンクからLSPを再ルーティングできます。制約を満たす代替パスがない場合、コントローラーはそれらの制約を一時的に緩和し、サービスを別のパスに置く可能性があります。 LDP-IGP同期などのイベントでメトリックが増加する可能性があるため、リンクメトリックを増加させるだけではメンテナンスアクティビティは指定されません。コントローラまたはヘッドエンドルータに通知するには、Graceful-Link-ShutdownサブTLVを使用するルータからの明示的な指示が必要です。
_____________
| |
--------------| Controller |--------------
| |____________ | |
| |
|--------- Primary Path ------------------|
PE1---------P1----------------P2---------PE2
| |
| |
|________P3________|
Alternate Path
代替パス
Figure 8: Controller-Based Traffic Engineering
図8：コントローラベースのトラフィックエンジニアリング
In the above example, the PE1->PE2 LSP is set up to satisfy a constraint of 10 Gbps bandwidth on each link. The links P1->P3 and P3->P2 have only 1 Gbps capacity, and there is no alternate path satisfying the bandwidth constraint of 10 Gbps. When the P1->P2 link is being prepared for maintenance, the controller receives the graceful-link-shutdown information, as there is no alternate path available that satisfies the constraints, and the controller chooses a path that is less optimal and temporarily sets up an alternate path via P1->P3->P2. Once the traffic is diverted, the P1->P2 link can be taken out of service for maintenance/upgrade.
上記の例では、各リンクの10 Gbps帯域幅の制約を満たすようにPE1-> PE2 LSPが設定されています。リンクP1-> P3およびP3-> P2の容量は1 Gbpsのみであり、10 Gbpsの帯域幅制約を満たす代替パスはありません。 P1-> P2リンクのメンテナンス準備が完了すると、制約を満たす代替パスがないため、コントローラーはグレースフルリンクシャットダウン情報を受け取り、コントローラーは最適でないパスを選択して一時的にセットアップします。 P1-> P3-> P2による代替パス。トラフィックが迂回されると、P1-> P2リンクは保守/アップグレードのためにサービスを停止できます。
Many service providers offer Layer 3 Virtual Private Network (L3VPN) services to customers, and CE-PE links run OSPF [RFC4577]. When the PE is taken out of service for maintenance, all the links on the PE can be set to graceful-link-shutdown state, which will guarantee that the traffic to/from dual-homed CEs gets diverted. The interaction between OSPF and BGP is outside the scope of this document. A mechanism based on [RFC6987] with summaries and externals that are advertised with high metrics could also be used to achieve the same functionality when implementations support high metrics advertisement for summaries and externals.
多くのサービスプロバイダーがレイヤ3バーチャルプライベートネットワーク（L3VPN）サービスを顧客に提供しており、CE-PEリンクはOSPF [RFC4577]を実行しています。 PEがメンテナンスのためにサービスを停止すると、PE上のすべてのリンクをgraceful-link-shutdown状態に設定できます。これにより、デュアルホームCEとの間のトラフィックが迂回されることが保証されます。 OSPFとBGPの間の相互作用は、このドキュメントの範囲外です。 [RFC6987]に基づく、高メトリックでアドバタイズされるサマリーとエクスターナルのメカニズムは、実装がサマリーとエクスターナルの高メトリックアドバタイズをサポートしている場合にも、同じ機能を実現するために使用できます。
Another useful use case is when ISPs provide sham-link services to customers [RFC4577]. When the PE goes out of service for maintenance, all sham links on the PE can be set to graceful-link-shutdown state, and traffic can be diverted from both ends without having to touch the configurations on the remote end of the sham links.
別の有用な使用例は、ISPが模造リンクサービスを顧客に提供する場合です[RFC4577]。 PEがメンテナンスのためにアウトオブサービスになると、PE上のすべての模造リンクをgraceful-link-shutdown状態に設定でき、模造リンクのリモートエンドの設定に触れる必要なく、両端からトラフィックを迂回させることができます。
OSPF is largely deployed in Hub and Spoke deployments with a large number of Spokes connecting to the Hub. It is a general practice to deploy multiple Hubs with all Spokes connecting to these Hubs to achieve redundancy. The mechanism defined in [RFC6987] can be used to divert the Spoke-to-Spoke traffic from the overloaded Hub router. The traffic that flows from Spokes via the Hub into an external network may not be diverted in certain scenarios. When a Hub node goes down for maintenance, all links on the Hub can be set to graceful-link-shutdown state, and traffic gets diverted from the Spoke sites as well without having to make configuration changes on the Spokes.
OSPFは主にハブアンドスポークの展開に展開され、多数のスポークがハブに接続されています。複数のハブを配置してすべてのスポークをこれらのハブに接続し、冗長性を実現するのが一般的な方法です。 [RFC6987]で定義されたメカニズムを使用して、過負荷のハブルーターからスポーク間トラフィックを迂回させることができます。スポークからハブを経由して外部ネットワークに流れるトラフィックは、特定のシナリオでは迂回されない場合があります。メンテナンスのためにハブノードがダウンすると、ハブ上のすべてのリンクをgraceful-link-shutdown状態に設定でき、スポークの構成を変更する必要なく、トラフィックがスポークサイトから迂回されます。
This document utilizes the OSPF packets and LSAs described in [RFC2328] , [RFC3630], [RFC5329], and [RFC5340]. The authentication procedures described in [RFC2328] for OSPFv2 and [RFC4552] for OSPFv3 are applicable to this document as well. This document does not introduce any further security issues other than those discussed in [RFC2328] and [RFC5340].
このドキュメントは、[RFC2328]、[RFC3630]、[RFC5329]、および[RFC5340]で説明されているOSPFパケットとLSAを利用しています。 OSPFv2の[RFC2328]およびOSPFv3の[RFC4552]で説明されている認証手順は、このドキュメントにも適用されます。このドキュメントでは、[RFC2328]と[RFC5340]で説明されている問題以外のセキュリティの問題は紹介していません。
IANA has registered the following in the "OSPFv2 Extended Link TLV Sub-TLVs" registry:
IANAは、「OSPFv2 Extended Link TLV Sub-TLVs」レジストリに以下を登録しています。
7 - Graceful-Link-Shutdown Sub-TLV
7-グレースフルリンクシャットダウンサブTLV
8 - Remote IPv4 Address Sub-TLV
8-リモートIPv4アドレスサブTLV
9 - Local/Remote Interface ID Sub-TLV
9-ローカル/リモートインターフェイスIDサブTLV
IANA has registered the following value in the "OSPFv3 Extended-LSA Sub-TLVs" registry:
IANAは、「OSPFv3 Extended-LSA Sub-TLVs」レジストリに次の値を登録しました。
8 - Graceful-Link-Shutdown sub-TLV
8-グレースフルリンクシャットダウンサブTLV
IANA has registered the following value in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry [RFC7752]":
IANAは、「BGP-LSノード記述子、リンク記述子、プレフィックス記述子、および属性TLV」レジストリ[RFC7752]に次の値を登録しました。
1121 - Graceful-Link-Shutdown TLV
1121-グレースフルリンクシャットダウンTLV
[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>。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<https://www.rfc-editor.org/info/rfc2328>。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
[RFC3630] Katz、D.、Kompella、K.、D。Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、DOI 10.17487 / RFC3630、2003年9月、<https：//www.rfc -editor.org/info/rfc3630>。
[RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, <https://www.rfc-editor.org/info/rfc5329>.
[RFC5329] Ishiguro、K.、Manral、V.、Davey、A.、and A. Lindem、Ed。、 "Traffic Engineering Extensions to OSPF Version 3"、RFC 5329、DOI 10.17487 / RFC5329、September 2008、<https： //www.rfc-editor.org/info/rfc5329>。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <https://www.rfc-editor.org/info/rfc5340>.
[RFC5340] Coltun、R.、Ferguson、D.、Moy、J。、およびA. Lindem、「OSPF for IPv6」、RFC 5340、DOI 10.17487 / RFC5340、2008年7月、<https：//www.rfc-editor .org / info / rfc5340>。
[RFC5817] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton, "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", RFC 5817, DOI 10.17487/RFC5817, April 2010, <https://www.rfc-editor.org/info/rfc5817>.
[RFC5817] Ali、Z.、Vasseur、JP。、Zamfir、A。、およびJ. Newton、「MPLSおよび一般化されたMPLSトラフィックエンジニアリングネットワークにおけるグレースフルシャットダウン」、RFC 5817、DOI 10.17487 / RFC5817、2010年4月、<https： //www.rfc-editor.org/info/rfc5817>。
[RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type", RFC 6845, DOI 10.17487/RFC6845, January 2013, <https://www.rfc-editor.org/info/rfc6845>.
[RFC6845] Sheth、N.、Wang、L。、およびJ. Zhang、「OSPFハイブリッドブロードキャストおよびポイントツーマルチポイントインターフェイスタイプ」、RFC 6845、DOI 10.17487 / RFC6845、2013年1月、<https：// www。 rfc-editor.org/info/rfc6845>。
[RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. McPherson, "OSPF Stub Router Advertisement", RFC 6987, DOI 10.17487/RFC6987, September 2013, <https://www.rfc-editor.org/info/rfc6987>.
[RFC6987] Retana、A.、Nguyen、L.、Zinin、A.、White、R。、およびD. McPherson、「OSPF Stub Router Advertisement」、RFC 6987、DOI 10.17487 / RFC6987、2013年9月、<https：/ /www.rfc-editor.org/info/rfc6987>。
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, <https://www.rfc-editor.org/info/rfc7684>.
[RFC7684] Psenak、P.、Gredler、H.、Shakir、R.、Henderickx、W.、Tantsura、J。、およびA. Lindem、「OSPFv2 Prefix / Link Attribute Advertisement」、RFC 7684、DOI 10.17487 / RFC7684、 2015年11月、<https://www.rfc-editor.org/info/rfc7684>。
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.
[RFC7752] Gredler、H.、Ed。、Medved、J.、Previdi、S.、Farrel、A.、and S. Ray、 "North-bound Distribution of Link-State and Traffic Engineering（TE）Information using BGP" 、RFC 7752、DOI 10.17487 / RFC7752、2016年3月、<https://www.rfc-editor.org/info/rfc7752>。
[RFC8042] Zhang, Z., Wang, L., and A. Lindem, "OSPF Two-Part Metric", RFC 8042, DOI 10.17487/RFC8042, December 2016, <https://www.rfc-editor.org/info/rfc8042>.
[RFC8042] Zhang、Z.、Wang、L。、およびA. Lindem、「OSPF Two-Part Metric」、RFC 8042、DOI 10.17487 / RFC8042、2016年12月、<https://www.rfc-editor.org/ info / rfc8042>。
[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>。
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, <https://www.rfc-editor.org/info/rfc8362>.
[RFC8362] Lindem、A.、Roy、A.、Goethals、D.、Reddy Vallem、V。、およびF. Baker、「OSPFv3 Link State Advertisement（LSA）Extensibility」、RFC 8362、DOI 10.17487 / RFC8362、2018年4月、<https://www.rfc-editor.org/info/rfc8362>。
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <https://www.rfc-editor.org/info/rfc4203>.
[RFC4203] Kompella、K.、Ed。およびY. Rekhter編、「汎用マルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張機能」、RFC 4203、DOI 10.17487 / RFC4203、2005年10月、<https://www.rfc-editor.org/info / rfc4203>。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, <https://www.rfc-editor.org/info/rfc4552>.
[RFC4552] Gupta、M.、N。Melam、「Authentication / Confidentiality for OSPFv3」、RFC 4552、DOI 10.17487 / RFC4552、2006年6月、<https://www.rfc-editor.org/info/rfc4552>。
[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, June 2006, <https://www.rfc-editor.org/info/rfc4577>.
[RFC4577] Rosen、E.、Psenak、P。、およびP. Pillay-Esault、「BGP / MPLS IP仮想プライベートネットワーク（VPN）のプロバイダー/カスタマーエッジプロトコルとしてのOSPF」、RFC 4577、DOI 10.17487 / RFC4577、 2006年6月、<https://www.rfc-editor.org/info/rfc4577>。
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, <https://www.rfc-editor.org/info/rfc4915>.
[RFC4915] Psenak、P.、Mirtorabi、S.、Roy、A.、Nguyen、L。、およびP. Pillay-Esnault、「OSPFでのマルチトポロジ（MT）ルーティング」、RFC 4915、DOI 10.17487 / RFC4915、 2007年6月、<https://www.rfc-editor.org/info/rfc4915>。
Acknowledgements
謝辞
Thanks to Chris Bowers for valuable input and edits to the document. Thanks to Jeffrey Zhang, Acee Lindem, and Ketan Talaulikar for their input. Thanks to Karsten Thomann for careful review and input on the applications where graceful link shutdown is useful.
ドキュメントへの貴重な入力と編集をしてくれたChris Bowersに感謝します。 Jeffrey Zhang、Acee Lindem、Ketan Talaulikarの各氏の協力に感謝します。グレースフルリンクシャットダウンが役立つアプリケーションについて慎重に検討および入力してくれたKarsten Thomannに感謝します。
Thanks to Alia Atlas, Deborah Brungard, Alvaro Retana, Andrew G. Malis, and Tim Chown for their valuable input.
Alia Atlas、Deborah Brungard、Alvaro Retana、Andrew G. Malis、Tim Chownの貴重な情報に感謝します。
Authors' Addresses
著者のアドレス
Shraddha Hegde Juniper Networks, Inc. Embassy Business Park Bangalore, KA 560093 India
Shraddha Hegde Juniper Networks、Inc.エンバシービジネスパークバンガロールインド
Email: shraddha@juniper.net
Pushpasis Sarkar Arrcus, Inc.
Pushpasis Sarkar Rarkus、これ。
Email: pushpasis.ietf@gmail.com
Hannes Gredler RtBrick Inc.
Hannes Gredler RtBrick Inc.
Email: hannes@rtbrick.com
Mohan Nanduri ebay Corporation 2025 Hamilton Avenue San Jose, CA 98052 United States of America
Mohan Nanduri ebay Corporation 2025 Hamilton Avenue San Jose、CA 98052アメリカ合衆国
Email: mnanduri@ebay.com
Luay Jalil Verizon
ルアイ・ジャリル・ベライゾン
Email: luay.jalil@verizon.com