[要約] RFC 4577は、BGP/MPLS IP仮想プライベートネットワーク（VPN）におけるプロバイダ/カスタマーエッジプロトコルとしてのOSPFの要約です。このRFCの目的は、OSPFを使用してBGP/MPLS IP VPNのエッジルータ間でルーティング情報を交換する方法を提案することです。
Network Working Group E. Rosen
Request for Comments: 4577 P. Psenak
Updates: 4364 P. Pillay-Esnault
Category: Standards Track Cisco Systems, Inc.
June 2006
OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)
BGP/MPLSのプロバイダー/カスタマーエッジプロトコルとしてのOSPF IP仮想プライベートネットワーク（VPNS）
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers (CE routers) are routing peers of provider edge routers (PE routers). The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First (OSPF) protocol.
多くのサービスプロバイダーは、顧客エッジルーター（CEルーター）がプロバイダーエッジルーター（PEルーター）のピアをルーティングするテクニックを使用して、顧客に仮想プライベートネットワーク（VPN）サービスを提供しています。Border Gateway Protocol（BGP）は、プロバイダーのIPバックボーンネットワーク全体に顧客のルートを配布するために使用され、マルチプロトコルラベルスイッチング（MPLS）を使用して、プロバイダーのバックボーン全体の顧客パケットをトンネルします。これは「BGP/MPLS IP VPN」として知られています。BGP/MPLS IP VPNのベース仕様は、PEルーターとCEルーターの間のインターフェイス上のルーティングプロトコルがBGPであると推定しています。このドキュメントは、PE/CEインターフェイス上のルーティングプロトコルを最初に開いた最短パス（OSPF）プロトコルにすることにより、その仕様を拡張します。
This document updates RFC 4364.
このドキュメントは、RFC 4364を更新します。
Table of Contents
目次
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Requirements ....................................................4
4. BGP/OSPF Interaction Procedures for PE Routers ..................6
4.1. Overview ...................................................6
4.1.1. VRFs and OSPF Instances .............................6
4.1.2. VRFs and Routes .....................................6
4.1.3. Inter-Area, Intra-Area, and External Routes .........7
4.1.4. PEs and OSPF Area 0 .................................8
4.1.5. Prevention of Loops .................................9
4.2. Details ....................................................9
4.2.1. Independent OSPF Instances in PEs ...................9
4.2.2. Router ID ..........................................10
4.2.3. OSPF Areas .........................................10
4.2.4. OSPF Domain Identifiers ............................10
4.2.5. Loop Prevention ....................................12
4.2.5.1. The DN Bit ................................12
4.2.5.2. Use of OSPF Route Tags ....................12
4.2.5.3. Other Possible Loops ......................13
4.2.6. Handling LSAs from the CE ..........................14
4.2.7. Sham Links .........................................16
4.2.7.1. Intra-Area Routes .........................16
4.2.7.2. Creating Sham Links .......................17
4.2.7.3. OSPF Protocol on Sham Links ...............18
4.2.7.4. Routing and Forwarding on Sham Links ......19
4.2.8. VPN-IPv4 Routes Received via BGP ...................19
4.2.8.1. External Routes ...........................20
4.2.8.2. Summary Routes ............................22
4.2.8.3. NSSA Routes ...............................22
5. IANA Considerations ............................................22
6. Security Considerations ........................................23
7. Acknowledgements ...............................................23
8. Normative References ...........................................23
9. Informative References .........................................24
[VPN] describes a method by which a Service Provider (SP) can use its IP backbone to provide a VPN (Virtual Private Network) service to customers. In that method, a customer's edge devices (CE devices) are connected to the provider's edge routers (PE routers). If the CE device is a router, then the PE router may become a routing peer of the CE router (in some routing protocol) and may, as a result, learn the routes that lead to the CE's site and that need to be distributed to other PE routers that attach to the same VPN.
[VPN]は、サービスプロバイダー（SP）がIPバックボーンを使用してVPN（仮想プライベートネットワーク）サービスを顧客に提供できる方法を説明しています。その方法では、顧客のエッジデバイス（CEデバイス）がプロバイダーのエッジルーター（PEルーター）に接続されています。CEデバイスがルーターである場合、PEルーターはCEルーターのルーティングピア（一部のルーティングプロトコルで）になる可能性があり、その結果、CEのサイトにつながり、に分布する必要があるルートを学習できます。同じVPNに接続する他のPEルーター。
The PE routers that attach to a common VPN use BGP (Border Gateway Protocol) to distribute the VPN's routes to each other. A CE router can then learn the routes to other sites in the VPN by peering with its attached PE router in a routing protocol. CE routers at different sites do not, however, peer with each other.
一般的なVPNに接続するPEルーターは、BGP（Border Gateway Protocol）を使用してVPNのルートを相互に配布します。CEルーターは、ルーティングプロトコルに接続されたPEルーターを覗き込むことにより、VPNの他のサイトへのルートを学習できます。ただし、さまざまなサイトのCEルーターは互いにピアではありません。
It can be expected that many VPNs will use OSPF (Open Shortest Path First) as their IGP (Interior Gateway Protocol), i.e., the routing protocol used by a network for the distribution of internal routes within that network. This does not necessarily mean that the PE routers need to use OSPF to peer with the CE routers. Each site in a VPN can use OSPF as its intra-site routing protocol, while using, for example, BGP [BGP] or RIP (Routing Information Protocol) [RIP] to distribute routes to a PE router. However, it is certainly convenient, when OSPF is being used intra-site, to use it on the PE-CE link as well, and [VPN] explicitly allows this.
多くのVPNは、IGP（Interior Gateway Protocol）としてOSPF（最初に最も短いパスを最初に開く）、つまりそのネットワーク内の内部ルートの分布にネットワークが使用するルーティングプロトコルを使用することが予想されます。これは、PEルーターがOSPFを使用してCEルーターをピアに使用する必要があることを必ずしも意味するものではありません。VPN内の各サイトは、BGP [BGP]またはRIP（ルーティング情報プロトコル）[RIP] [RIP]を使用して、PEルーターにルートを配布しながら、サイト内ルーティングプロトコルとしてOSPFを使用できます。ただし、OSPFが敷地内で使用されている場合、PE-CEリンクでも使用する場合は確かに便利です。[VPN]はこれを明示的に許可します。
Like anything else, the use of OSPF on the PE-CE link has advantages and disadvantages. The disadvantage to using OSPF on the PE-CE link is that it gets the SP's PE router involved, however peripherally, in a VPN site's IGP. The advantages though are:
他のものと同様に、PE-CEリンクでのOSPFの使用には利点と短所があります。PE-CEリンクでOSPFを使用することの欠点は、VPNサイトのIGPでSPのPEルーターを周辺的に関与させることです。しかし、利点は次のとおりです。
- The administrators of the CE router need not have any expertise in any routing protocol other than OSPF.
- CEルーターの管理者は、OSPF以外のルーティングプロトコルの専門知識を持っている必要はありません。
- The CE routers do not need to have support for any routing protocols other than OSPF.
- CEルーターは、OSPF以外のルーティングプロトコルをサポートする必要はありません。
- If a customer is transitioning his network from a traditional OSPF backbone to the VPN service described in [VPN], the use of OSPF on the PE-CE link eases the transitional issues.
- 顧客が自分のネットワークを従来のOSPFバックボーンから[VPN]に記載されているVPNサービスに移行している場合、PE-CEリンクでのOSPFの使用は移行問題を緩和します。
It seems likely that some SPs and their customers will resolve these trade-offs in favor of the use of OSPF on the PE-CE link. Thus, we need to specify the procedures that must be implemented by a PE router in order to make this possible. (No special procedures are needed in the CE router though; CE routers just run whatever OSPF implementations they may have.)
一部のSPSとその顧客は、PE-CEリンクでのOSPFの使用を支持してこれらのトレードオフを解決する可能性が高いようです。したがって、これを可能にするために、PEルーターによって実装する必要がある手順を指定する必要があります。（CEルーターでは特別な手順は必要ありませんが、CEルーターは、OSPFの実装を実行するものを実行するだけです。）
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
Consider a set of VPN sites that are thought of as being in the same "OSPF domain". Two sites are considered to be in the same OSPF domain if it is intended that routes from one site to the other be considered intra-network routes. A set of OSPF sites in the same domain will almost certainly be a set of sites that together constitute an "intranet", each of which runs OSPF as its intra-site routing protocol.
同じ「OSPFドメイン」にあると考えられているVPNサイトのセットを検討してください。1つのサイトから別のサイトへのルートをネットワーク内ルートと見なすことを意図している場合、2つのサイトが同じOSPFドメインにあると見なされます。同じドメイン内の一連のOSPFサイトは、ほぼ間違いなく「イントラネット」を構成する一連のサイトであり、それぞれが敷地内ルーティングプロトコルとしてOSPFを実行します。
Per [VPN], the VPN routes are distributed among the PE routers by BGP. If the PE uses OSPF to distribute routes to the CE router, the standard procedures governing BGP/OSPF interactions [OSPFv2] would cause routes from one site to be delivered to another in type 5 LSAs (Link State Advertisements), as "AS-external" routes. This is undesirable; it would be much better to deliver such routes in type 3 LSAs (as inter-area routes), so that they can be distinguished from any "real" AS-external routes that may be circulating in the VPN (that is, so that they can be distinguished by OSPF from routes that really do not come from within the VPN). Hence, it is necessary for the PE routers to implement a modified version of the BGP/OSPF interaction procedures.
[VPN]ごとに、VPNルートはBGPによってPEルーターに分布しています。PEがOSPFを使用してルートをCEルーターに配布する場合、BGP/OSPF相互作用[OSPFV2]を支配する標準手順により、あるサイトからのルートがタイプ5 LSA（リンク状態広告）で別のサイトに配信されます。「ルート。これは望ましくありません。タイプ3 LSA（エリア間ルートとして）にそのようなルートを配信する方がはるかに良いでしょう。そうすれば、VPNで循環する可能性のある「実際の」外側のルート（つまり、つまり、VPN内から実際には由来しないルートとOSPFによって区別できます）。したがって、PEルーターがBGP/OSPF相互作用手順の修正バージョンを実装する必要があります。
In fact, we would like to have a very general set of procedures that allows a customer to replace a legacy private OSPF backbone easily with the VPN service. We would like this procedure to meet the following set of requirements:
実際、お客様がレガシープライベートOSPFバックボーンをVPNサービスに簡単に置き換えることができる非常に一般的な一連の手順を希望しています。この手順に、次の要件を満たすようにしたいと思います。
- The procedures should not make assumptions about the OSPF topology. In particular, it should not be assumed that customer sites are OSPF stub sites or NSSA (Not So Stubby Area) sites. Nor should it be assumed that a customer site contains only one OSPF area, or that it has no area 0 routers.
- 手順は、OSPFトポロジについて仮定を立てるべきではありません。特に、顧客サイトはOSPFスタブサイトまたはNSSA（それほどずんったエリアではない）であると想定すべきではありません。また、顧客サイトには1つのOSPF領域のみが含まれている、またはエリア0ルーターがないと想定されるべきではありません。
- If VPN sites A and B are in the same OSPF domain, then routes from one should be presented to the other as OSPF intra-network routes. In general, this can be done by presenting such routes as inter-area routes in type 3 LSAs.
- VPNサイトAとBが同じOSPFドメインにある場合、OSPFのネットワーク内ルートとして一方からのルートを他方に提示する必要があります。一般に、これはタイプ3 LSAのエリア間ルートなどのルートを提示することで実行できます。
Note that this allows two VPN sites to be connected via an "OSPF backdoor link". That is, one can have an OSPF link between the two sites that is used only when the VPN backbone is unavailable. (This would not be possible with the ordinary BGP/OSPF interaction procedures. The ordinary procedures would present routes via the VPN backbone as AS-external routes, and these could never be preferred to intra-network routes.) This may be very useful during a period of transition from a legacy OSPF backbone to a VPN backbone.
これにより、「OSPFバックドアリンク」を介して2つのVPNサイトを接続できることに注意してください。つまり、VPNバックボーンが利用できない場合にのみ使用される2つのサイト間にOSPFリンクを持つことができます。（これは通常のBGP/OSPF相互作用手順では不可能です。通常の手順は、VPNバックボーンを介して外部ルートとしてルートを提示します。これらはネットワーク内ルートよりも好まれることはありません。）レガシーOSPFバックボーンからVPNバックボーンへの移行期間。
- It should be possible to make use of an "OSPF backdoor link" between two sites, even if the two sites are in the same OSPF area and neither of the routers attached to the inter-site backdoor link is an area 0 router. This can also be very useful during a transition period, and it eliminates any need to reconfigure the sites' routers to be ABRs (Area Border Routers).
- 2つのサイトが同じOSPF領域にあり、敷地間のバックドアリンクに取り付けられたルーターのいずれもエリア0ルーターであっても、2つのサイト間の「OSPFバックドアリンク」を使用することは可能です。これはまた、移行期間中に非常に有用である可能性があり、サイトのルーターをABR（エリアボーダールーター）に再構成する必要性を排除します。
Assuming that it is desired to have the route via the VPN backbone be preferred to the backdoor route, the VPN backbone itself must be presented to the CE routers at each site as a link between the two PE routers to which the CE routers are respectively attached.
VPNバックボーンを介してルートをバックドアルートよりも優先することが望ましいと仮定すると、VPNバックボーン自体は、CEルーターがそれぞれ接続されている2つのPEルーター間のリンクとして、各サイトのCEルーターに提示する必要があります。。
- CE routers, connected to PE routers of the VPN service, may themselves function as OSPF backbone (area 0) routers. An OSPF backbone may even consist of several "segments" that are interconnected themselves only via the VPN service. In such a scenario, full intercommunication between sites connected to different segments of the OSPF backbone should still be possible.
- VPNサービスのPEルーターに接続されたCEルーターは、それ自体がOSPFバックボーン（エリア0）ルーターとして機能する場合があります。OSPFバックボーンは、VPNサービスを介してのみ相互に接続されているいくつかの「セグメント」で構成される場合があります。このようなシナリオでは、OSPF骨格の異なるセグメントに接続されたサイト間の完全な通信がまだ可能です。
- The transition from the legacy private OSPF backbone to the VPN service must be simple and straightforward. The transition is likely to be phased, such that customer sites are migrated one by one from the legacy private OSPF backbone to the VPN service. During the transition, any given site might be connected to the VPN service, to the legacy OSPF backbone, or to both. Complete connectivity among all such sites must be maintained.
- レガシープライベートOSPFバックボーンからVPNサービスへの移行は、シンプルで簡単でなければなりません。この移行は段階的に段階的になる可能性が高いため、顧客サイトはレガシープライベートOSPFバックボーンからVPNサービスに1つずつ移行します。移行中、特定のサイトがVPNサービス、レガシーOSPFバックボーン、またはその両方に接続される可能性があります。そのようなすべてのサイト間の完全な接続を維持する必要があります。
Since the VPN service is to replace the legacy backbone, it must be possible, by suitable adjustment of the OSPF metrics, to make OSPF prefer routes that traverse the SP's VPN backbone to alternative routes that do not.
VPNサービスはレガシーバックボーンを置き換えることであるため、OSPFメトリックを適切に調整することにより、OSPFにSPのVPNバックボーンを通過しないルートを好まないルートを好むことが可能でなければなりません。
- The OSPF metric assigned to a given route should be carried transparently over the VPN backbone.
- 特定のルートに割り当てられたOSPFメトリックは、VPNバックボーンの上に透過的に運ぶ必要があります。
Routes from sites that are not in the same OSPF domain will appear as AS-external routes.
同じOSPFドメインにないサイトからのルートは、外部ルートとして表示されます。
We presuppose familiarity with the contents of [OSPFv2], including the OSPF LSA types, and will refer without further exegesis to type 1, 2, 3, etc. LSAs. Familiarity with [VPN] is also presupposed.
OSPF LSAタイプを含む[OSPFv2]の内容に精通していることを前提としており、タイプ1、2、3などをさらに解釈することなく参照します。LSA。[VPN]に精通していることも前提です。
A PE router that attaches to more than one OSPF domain MUST run an independent instance of OSPF for each domain. If the PE is running OSPF as its IGP (Interior Gateway Protocol), the instance of OSPF running as the IGP must be separate and independent from any other instance of OSPF that the PE is running. (Whether these instances are realized as separate processes or merely as separate contexts of a common process is an implementation matter.) Each interface that attaches to a VPN site belongs to no more than one OSPF instance.
複数のOSPFドメインに付着するPEルーターは、各ドメインに対してOSPFの独立したインスタンスを実行する必要があります。PEがIGP（インテリアゲートウェイプロトコル）としてOSPFを実行している場合、IGPとして実行されるOSPFのインスタンスは、PEが実行されている他のOSPFのインスタンスとは分離され、独立している必要があります。（これらのインスタンスが個別のプロセスとして実現されているか、単に共通プロセスの個別のコンテキストとして実現されるかどうかは実装問題です。）VPNサイトに接続する各インターフェイスは、1つ以下のOSPFインスタンスに属します。
[VPN] defines the notion of a Per-Site Routing and Forwarding Table, or VRF. Each VRF is associated with a set of interfaces. If a VRF is associated with a particular interface, and that interface belongs to a particular OSPF instance, then that OSPF instance is said to be associated with the VRF. If two interfaces belong to the same OSPF instance, then both interfaces must be associated with the same VRF.
[VPN]は、一つのルーティングと転送テーブル、またはVRFの概念を定義します。各VRFは、一連のインターフェイスに関連付けられています。VRFが特定のインターフェイスに関連付けられており、そのインターフェイスが特定のOSPFインスタンスに属している場合、そのOSPFインスタンスはVRFに関連付けられていると言われています。2つのインターフェイスが同じOSPFインスタンスに属している場合、両方のインターフェイスを同じVRFに関連付ける必要があります。
If an interface attaches a PE to a CE, and that interface is associated with a VRF, we will speak of the CE as being associated with the VRF.
インターフェイスがCEにPEを取り付け、そのインターフェイスがVRFに関連付けられている場合、CEについてVRFに関連付けられていると話します。
OSPF is used to distribute routes from a CE to a PE. The standard OSPF decision process is used to install the best OSPF-distributed routes in the VRF.
OSPFは、CEからPEにルートを配布するために使用されます。標準のOSPF決定プロセスは、VRFに最適なOSPF分配ルートをインストールするために使用されます。
Per [VPN], BGP is used to distribute VPN-IPv4 routes among PE routers. An OSPF route installed in a VRF may be "exported" by being redistributed into BGP as a VPN-IPv4 route. It may then be distributed by BGP to other PEs. At the other PEs, a VPN-IPv4 route may be "imported" by a VRF and may then be redistributed into one or more of the OSPF instances associated with that VRF.
[VPN]ごとに、BGPはPEルーター間にVPN-IPV4ルートを配布するために使用されます。VRFに設置されたOSPFルートは、VPN-IPV4ルートとしてBGPに再配布されることにより、「エクスポート」される場合があります。その後、BGPによって他のPESに配布される場合があります。他のPESでは、VPN-IPV4ルートはVRFによって「インポート」され、そのVRFに関連付けられたOSPFインスタンスの1つ以上に再配布される場合があります。
Import from and export to particular VRFs is controlled by the use of the Route Target Extended Communities attribute (or, more simply, Route Target or RT), as specified in [VPN].
特定のVRFからのインポートとエクスポートは、[VPN]で指定されているように、ルートターゲット拡張コミュニティ属性（より簡単にルートターゲットまたはRT）を使用することにより制御されます。
A VPN-IPv4 route is "eligible for import" into a particular VRF if its Route Target is identical to one of the VRF's import Route Targets. The standard BGP decision process is used to select, from among the routes eligible for import, the set of VPN-IPv4 routes to be "installed" in the VRF.
VPN-IPV4ルートは、ルートターゲットがVRFのインポートルートターゲットのいずれかと同一である場合、特定のVRFに「インポートの対象」です。標準のBGP決定プロセスは、インポートの対象となるルートの中から、VRFに「インストール」されるVPN-IPV4ルートのセットを選択するために使用されます。
If a VRF contains both an OSPF-distributed route and a VPN-IPv4 route for the same IPv4 prefix, then the OSPF-distributed route is preferred. In general, this means that forwarding is done according to the OSPF route. The one exception to this rule has to do with the "sham link". If the next hop interface for an installed (OSPF-distributed) route is the sham link, forwarding is done according to a corresponding BGP route. This is detailed in Section 4.2.7.4.
VRFに、同じIPv4プレフィックスのOSPF-DistributedルートとVPN-IPV4ルートの両方が含まれている場合、OSPF-Distributedルートが推奨されます。一般に、これは、OSPFルートに従って転送が行われることを意味します。このルールの1つの例外は、「偽のリンク」に関係しています。インストールされた（OSPF-Distributed）ルートの次のホップインターフェイスが偽リンクである場合、転送は対応するBGPルートに従って行われます。これについては、セクション4.2.7.4で詳しく説明しています。
To meet the requirements of Section 3, a PE that installs a particular route into a particular VRF needs to know whether that route was originally an OSPF route and, if so, whether the OSPF instance from which it was redistributed into BGP is in the same domain as the OSPF instances into which the route may be redistributed. Therefore, a domain identifier is encoded as a BGP Extended Communities attribute [EXTCOMM] and distributed by BGP along with the VPN-IPv4 route. The route's OSPF metric and OSPF route type are also carried as BGP attributes of the route.
セクション3の要件を満たすために、特定のルートを特定のVRFにインストールするPEは、そのルートが元々OSPFルートであったかどうかを知る必要があります。ルートが再配布される可能性のあるOSPFインスタンスとしてのドメイン。したがって、ドメイン識別子は、BGP拡張コミュニティ属性[extcomm]としてエンコードされ、VPN-IPV4ルートとともにBGPによって分布します。ルートのOSPFメトリックおよびOSPFルートタイプも、ルートのBGP属性として運ばれます。
If a PE installs a particular VPN-IPv4 route (learned via BGP) in a VRF, and if this is the preferred BGP route for the corresponding IPv4 prefix, the corresponding IPv4 route is then "eligible for redistribution" into each OSPF instance that is associated with the VRF. As a result, it may be advertised to each CE in an LSA.
PEがVRFで特定のVPN-IPV4ルート（BGPを介して学習）をインストールし、これが対応するIPv4プレフィックスの好ましいBGPルートである場合、対応するIPv4ルートは各OSPFインスタンスへの「再配布の対象」です。VRFに関連付けられています。その結果、LSAの各CEに宣伝される場合があります。
Whether a route that is eligible for redistribution into OSPF is actually redistributed into a particular OSPF instance may depend upon the configuration. For instance, the PE may be configured to distribute only the default route into a given OSPF instance. In this case, the routes that are eligible for redistribution would not actually be redistributed.
OSPFへの再配布の対象となるルートが実際に特定のOSPFインスタンスに再配布されるかどうかは、構成によって依存する可能性があります。たとえば、PEは、デフォルトルートのみを特定のOSPFインスタンスに配布するように構成されている場合があります。この場合、再配布の対象となるルートは実際には再分配されません。
In the following, we discuss the procedures for redistributing a BGP-distributed VPN-IPv4 route into OSPF; these are the procedures to be followed whenever such a route is eligible to be redistributed into OSPF and the configuration does not prevent such redistribution.
以下では、BGPに寄付されたVPN-IPV4ルートをOSPFに再配布する手順について説明します。これらは、そのようなルートがOSPFに再配布される資格がある場合に従うべき手順であり、構成はそのような再分配を妨げません。
If the route is from an OSPF domain different from that of the OSPF instance into which it is being redistributed, or if the route is not from an OSPF domain at all, then the route is considered an external route.
ルートが再配布されているOSPFインスタンスとは異なるOSPFドメインからのものである場合、またはルートがOSPFドメインからのものではない場合、ルートは外部ルートと見なされます。
If the route is from the same OSPF domain as the OSPF instance into which it is being redistributed, and if it was originally advertised to a PE as an OSPF external route or an OSPF NSSA route, it will be treated as an external route. Following the normal OSPF procedures, external routes may be advertised to the CE in type 5 LSAs, or in type 7 LSAs, or not at all, depending on the type of area to which the PE/CE link belongs.
ルートが再配布されているOSPFインスタンスと同じOSPFドメインから、そしてもともとOSPFの外部ルートまたはOSPF NSSAルートとしてPEに宣伝されていた場合、外部ルートとして扱われます。通常のOSPF手順に続いて、PE/CEリンクが属する領域のタイプに応じて、タイプ5 LSA、またはタイプ7 LSAのCEに外部ルートを宣伝することができます。
If the route is from the same OSPF domain as the OSPF instance into which it is being redistributed, and if it was originally advertised to a PE as an inter-area or intra-area route, the route will generally be advertised to the CE as an inter-area route (in a type 3 LSA).
ルートが再配布されているOSPFインスタンスと同じOSPFドメインからのものであり、元々はエリア間またはエリア内ルートとしてPEに宣伝されていた場合、ルートは通常CEに宣伝されます。エリア間ルート（タイプ3 LSA）。
As a special case, suppose that PE1 attaches to CE1, and that PE2 attaches to CE2, where:
特別なケースとして、PE1がCE1に付着し、PE2がCE2に付着すると仮定します。
- the OSPF instance containing the PE1-CE1 link and the OSPF instance containing the PE2-CE2 link are in the same OSPF domain, and
- PE1-CE1リンクとPE2-CE2リンクを含むOSPFインスタンスを含むOSPFインスタンスは、同じOSPFドメインにあり、
- the PE1-CE1 and PE2-CE2 links are in the same OSPF area A (as determined by the configured OSPF area number),
- PE1-CE1およびPE2-CE2リンクは、同じOSPF領域A（構成されたOSPF領域番号によって決定される）にあります。
then, PE1 may flood to CE1 a type 1 LSA advertising a link to PE2, and PE2 may flood to CE2 a type 1 LSA advertising a link to PE1. The link advertised in these LSAs is known as a "sham link", and it is advertised as a link in area A. This makes it look to routers within area A as if the path from CE1 to PE1 across the service provider's network to PE2 to CE2 is an intra-area path. Sham links are an OPTIONAL feature of this specification and are used only when it is necessary to have the service provider's network treated as an intra-area link. See Section 4.2.7 for further details about the sham link.
その後、PE1はCE1に洪水に浸水し、PE2へのリンクを宣伝するタイプ1 LSA、PE2はCE2に浸水し、PE1へのリンクを宣伝する可能性があります。これらのLSAで宣伝されているリンクは「偽のリンク」として知られており、エリアAのリンクとして宣伝されています。CE2へは地域内パスです。偽のリンクは、この仕様のオプションの機能であり、サービスプロバイダーのネットワークをエリア内リンクとして扱う必要がある場合にのみ使用されます。偽のリンクの詳細については、セクション4.2.7を参照してください。
The precise details by which a PE determines the type of LSA used to advertise a particular route to a CE are specified in Section 4.2.8. Note that if the VRF is associated with multiple OSPF instances, the type of LSA used to advertise the route might be different in different instances.
PEがCEへの特定のルートを宣伝するために使用されるLSAのタイプを決定する正確な詳細は、セクション4.2.8で指定されています。VRFが複数のOSPFインスタンスに関連付けられている場合、ルートを宣伝するために使用されるLSAのタイプは、インスタンスによって異なる場合があることに注意してください。
Note that if a VRF is associated with several OSPF instances, a given route may be redistributed into some or all of those OSPF instances, depending on the characteristics of each instance. If redistributed into two or more OSPF instances, it may be advertised within each instance using a different type of LSA, again depending on the characteristics of each instance.
VRFがいくつかのOSPFインスタンスに関連付けられている場合、各インスタンスの特性に応じて、特定のルートがこれらのOSPFインスタンスの一部またはすべてに再配布される可能性があることに注意してください。2つ以上のOSPFインスタンスに再配布された場合、各インスタンスの特性に応じて、異なるタイプのLSAを使用して各インスタンス内で宣伝される場合があります。
Within a given OSPF domain, a PE may attach to multiple CEs. Each PE/CE link is assigned (by configuration) to an OSPF area. Any link can be assigned to any area, including area 0.
特定のOSPFドメイン内で、PEは複数のCEに付着する場合があります。各PE/CEリンクは（構成ごとに）OSPF領域に割り当てられます。リンクは、エリア0を含む任意のエリアに割り当てることができます。
If a PE attaches to a CE via a link that is in a non-zero area, then the PE serves as an ABR for that area.
PEがゼロ以外の領域にあるリンクを介してCEに付着する場合、PEはその領域のABRとして機能します。
PEs can thus be considered OSPF "area 0 routers", i.e., they can be considered part of the "OSPF backbone". Thus, they are allowed to distribute inter-area routes to the CE via Type 3 LSAs.
したがって、PEはOSPF「エリア0ルーター」と見なすことができます。つまり、「OSPFバックボーン」の一部と見なすことができます。したがって、タイプ3 LSAを介してエリア間ルートをCEに分配することが許可されています。
If the OSPF domain has any area 0 routers other than the PE routers, then at least one of those MUST be a CE router and MUST have an area 0 link to at least one PE router. This adjacency MAY be via an OSPF virtual link. (The ability to use an OSPF virtual link in this way is an OPTIONAL feature.) This is necessary to ensure that inter-area routes and AS-external routes can be leaked between the PE routers and the non-PE OSPF backbone.
OSPFドメインにPEルーター以外の領域0ルーターがある場合、少なくとも1つはCEルーターでなければならず、少なくとも1つのPEルーターへのエリア0リンクが必要です。この隣接は、OSPF仮想リンクを介して行われる場合があります。（この方法でOSPF仮想リンクを使用する機能は、オプションの機能です。）これは、エリア間ルートと外部ルートをPEルーターと非PE OSPFバックボーンの間に漏洩できるようにするために必要です。
Two sites that are not in the same OSPF area will see the VPN backbone as being an integral part of the OSPF backbone. However, if there are area 0 routers that are NOT PE routers, then the VPN backbone actually functions as a sort of higher-level backbone, providing a third level of hierarchy above area 0. This allows a legacy OSPF backbone to become disconnected during a transition period, as long as the various segments all attach to the VPN backbone.
同じOSPFエリアにない2つのサイトでは、VPNバックボーンがOSPFバックボーンの不可欠な部分であると見られます。ただし、PEルーターではない領域0ルーターがある場合、VPNバックボーンは実際には一種の高レベルのバックボーンとして機能し、エリア0の上に3番目のレベルのヒエラルキーを提供します。さまざまなセグメントがすべてVPNバックボーンに付着する限り、遷移期間。
If a route sent from a PE router to a CE router could then be received by another PE router from one of its own CE routers, it would be possible for routing loops to occur. To prevent this, a PE sets the DN bit [OSPF-DN] in any LSA that it sends to a CE, and a PE ignores any LSA received from a CE that already has the DN bit sent. Older implementations may use an OSPF Route Tag instead of the DN bit, in some cases. See Sections 4.2.5.1 and 4.2.5.2.
PEルーターからCEルーターに送信されたルートが、独自のCEルーターの1つから別のPEルーターによって受信される可能性がある場合、ルーピングループが発生する可能性があります。これを防ぐために、PEはCEに送信するLSAにDNビット[OSPF-DN]を設定し、PEは既にDNビットが送信されているCEから受け取ったLSAを無視します。古い実装では、場合によってはDNビットの代わりにOSPFルートタグを使用する場合があります。セクション4.2.5.1および4.2.5.2を参照してください。
The PE MUST support one OSPF instance for each OSPF domain to which it attaches. These OSPF instances function independently and do not leak routes to each other. Each instance of OSPF MUST be associated with a single VRF. If n CEs associated with that VRF are running OSPF on their respective PE/CE links, then those n CEs are OSPF adjacencies of the PE in the corresponding instance of OSPF.
PEは、付着する各OSPFドメインに対して1つのOSPFインスタンスをサポートする必要があります。これらのOSPFインスタンスは独立して機能し、互いにルートを漏らしません。OSPFの各インスタンスは、単一のVRFに関連付けられている必要があります。そのVRFに関連付けられたN CEがそれぞれのPE/CEリンクでOSPFを実行している場合、それらのn CEは、対応するOSPFのPEのOSPF隣接です。
Generally, though not necessarily, if the PE attaches to several CEs in the same OSPF domain, it will associate the interfaces to those PEs with a single VRF.
一般に、必ずしもそうではありませんが、PEが同じOSPFドメイン内のいくつかのCEに付着する場合、インターフェイスをそれらのPESに単一のVRFに関連付けます。
If a PE and a CE are communicating via OSPF, the PE will have an OSPF Router ID that is valid (i.e., unique) within the OSPF domain. More precisely, each OSPF instance has a Router ID. Different OSPF instances may have different Router IDs.
PEとCEがOSPFを介して通信している場合、PEにはOSPFドメイン内で有効な（つまり、一意）OSPFルーターIDがあります。より正確には、各OSPFインスタンスにはルーターIDがあります。異なるOSPFインスタンスには、ルーターIDが異なる場合があります。
A PE-CE link may be in any area, including area 0; this is a matter of the OSPF configuration.
PE-CEリンクは、エリア0を含むどのエリアにある場合もあります。これはOSPF構成の問題です。
If a PE has a link that belongs to a non-zero area, the PE functions as an Area Border Router (ABR) for that area.
PEに非ゼロエリアに属するリンクがある場合、PEはその領域のエリアボーダールーター（ABR）として機能します。
PEs do not pass along the link state topology from one site to another (except in the case where a sham link is used; see Section 4.2.7).
PESは、あるサイトから別のサイトにリンク状態トポロジを渡すことはありません（偽のリンクが使用される場合を除き、セクション4.2.7を参照）。
Per [OSPFv2, Section 3.1], "the OSPF backbone always contains all area border routers". The PE routers are therefore considered area 0 routers. Section 3.1 of [OSPFv2] also requires that area 0 be contiguous. It follows that if the OSPF domain has any area 0 routers other than the PE routers, at least one of those MUST be a CE router, and it MUST have an area 0 link (possibly a virtual link) to at least one PE router.
[OSPFV2、セクション3.1]ごとに、「OSPFバックボーンには常にすべての領域の境界ルーターが含まれています」。したがって、PEルーターは、面積0ルーターと見なされます。[OSPFV2]のセクション3.1では、領域0が隣接することも必要です。OSPFドメインにPEルーター以外の領域0ルーターがある場合、少なくとも1つはCEルーターでなければならず、少なくとも1つのPEルーターへの領域0リンク（おそらく仮想リンク）が必要です。
Each OSPF instance MUST be associated with one or more Domain Identifiers. This MUST be configurable, and the default value (if none is configured) SHOULD be NULL.
各OSPFインスタンスは、1つ以上のドメイン識別子に関連付けられている必要があります。これは構成可能でなければならず、デフォルト値（構成されていない場合）はnullである必要があります。
If an OSPF instance has multiple Domain Identifiers, one of these is considered its "primary" Domain Identifier; this MUST be determinable by configuration. If an OSPF instance has exactly one Domain Identifier, this is of course its primary Domain Identifier. If an OSPF instance has more than one Domain Identifier, the NULL Domain Identifier MUST NOT be one of them.
OSPFインスタンスに複数のドメイン識別子がある場合、これらの1つはその「主要な」ドメイン識別子と見なされます。これは、構成によって決定可能でなければなりません。OSPFインスタンスに1つのドメイン識別子が1つある場合、これはもちろんその主要なドメイン識別子です。OSPFインスタンスに複数のドメイン識別子がある場合、nullドメイン識別子はそれらの1つであってはなりません。
If a route is installed in a VRF by a particular OSPF instance, the primary Domain Identifier of that OSPF instance is considered the route's Domain Identifier.
特定のOSPFインスタンスによってルートがVRFにインストールされている場合、そのOSPFインスタンスの主要なドメイン識別子は、ルートのドメイン識別子と見なされます。
Consider a route, R, that is installed in a VRF by OSPF instance I1, then redistributed into BGP as a VPN-IPv4 route, and then installed by BGP in another VRF. If R needs to be redistributed into OSPF instance I2, associated with the latter VRF, the way in which R is advertised in I2 will depend upon whether R's Domain Identifier is one of I2's Domain Identifiers. If R's Domain Identifier is not one of I2's Domain Identifiers, then, if R is redistributed into I2, R will be advertised as an AS-external route, no matter what its OSPF route type is. If, on the other hand, R's Domain Identifier is one of I2's Domain Identifiers, how R is advertised will depend upon R's OSPF route type.
OSPFインスタンスI1によってVRFにインストールされているルートrを考えてから、VPN-IPV4ルートとしてBGPに再配布し、別のVRFにBGPによってインストールされます。rを後者のVRFに関連付けたOSPFインスタンスi2に再配布する必要がある場合、i2でRが宣伝される方法は、Rのドメイン識別子がI2のドメイン識別子の1つであるかどうかに依存します。rのドメイン識別子がi2のドメイン識別子の1つではない場合、rがi2に再配布される場合、rはOSPFルートタイプが何であれ、as-fernalルートとして宣伝されます。一方、Rのドメイン識別子がI2のドメイン識別子の1つである場合、Rの宣伝方法はRのOSPFルートタイプに依存します。
If two OSPF instances are in the same OSPF domain, then either:
2つのOSPFインスタンスが同じOSPFドメインにある場合、次のとおりです。
1. They both have the NULL Domain Identifier, OR
1. どちらもnullドメイン識別子を持っています
2. Each OSPF instance has the primary Domain Identifier of the other as one of its own Domain Identifiers.
2. 各OSPFインスタンスには、独自のドメイン識別子の1つとして、もう1つの主要なドメイン識別子があります。
If two OSPF instances are in different OSPF domains, then either:
2つのOSPFインスタンスが異なるOSPFドメインにある場合、次のとおりです。
3. They both have the NULL Domain Identifier, OR
3. どちらもnullドメイン識別子を持っています
4. Neither OSPF instance has the Primary Domain Identifier of the other as one of its own Domain Identifiers.
4. どちらのOSPFインスタンスも、独自のドメイン識別子の1つとして、他方の主要なドメイン識別子を持っていません。
(Note that if two OSPF instances each have the NULL Domain Identifier, we cannot tell from the Domain Identifier whether they are in the same OSPF Domain. If they are in different domains, and if routes from one are distributed into the other, the routes will appear as intra-network routes, which may not be what is intended.)
（2つのOSPFインスタンスがそれぞれnullドメイン識別子を持っている場合、ドメイン識別子が同じOSPFドメインにあるかどうかを知ることはできません。それらが異なるドメインにある場合、および1つのルートが他方に分布している場合、ルートはルートです。ネットワーク内のルートとして表示されますが、これは意図されていないものではありません。）
A Domain Identifier is an eight-byte quantity that is a valid BGP Extended Communities attribute, as specified in Section 4.2.4. If a particular OSPF instance has a non-NULL Domain Identifier, when routes from that OSPF instance are distributed by BGP as VPN-IPv4 routes, the routes MUST carry the Domain Identifier Extended Communities attribute that corresponds to the OSPF instance's Primary Domain Identifier. If the OSPF instance's Domain Identifier is NULL, the Domain Identifier Extended Communities attribute MAY be omitted when routes from that OSPF instance are distributed by BGP; alternatively, a value of the Domain Identifier Extended Communities attribute that represents NULL (see Section 4.2.4) MAY be carried with the route.
ドメイン識別子は、セクション4.2.4で指定されているように、有効なBGP拡張コミュニティ属性である8バイトの量です。特定のOSPFインスタンスが非ヌルドメイン識別子を持っている場合、そのOSPFインスタンスからのルートがBGPによってVPN-IPV4ルートとして分布している場合、ルートはOSPFインスタンスの主要ドメイン識別子に対応するドメイン識別子拡張コミュニティ属性を運ぶ必要があります。OSPFインスタンスのドメイン識別子がnullの場合、そのOSPFインスタンスからのルートがBGPによって分布される場合、ドメイン識別子拡張コミュニティ属性が省略される場合があります。あるいは、nullを表す（セクション4.2.4を参照）を表すドメイン識別子拡張コミュニティ属性の値をルートに携帯する場合があります。
If the OSPF instances of an OSPF domain are given one or more non-NULL Domain Identifiers, this procedure allows us to determine whether a particular OSPF-originated VPN-IPv4 route belongs to the same domain as a given OSPF instance. We can then determine whether the route should be redistributed to that OSPF instance as an inter-area route or as an OSPF AS-external route. Details can be found in Sections 4.2.4 and 4.2.8.1.
OSPFドメインのOSPFインスタンスに1つ以上の非ヌルドメイン識別子が与えられた場合、この手順により、特定のOSPFオリジー化されたVPN-IPV4ルートが特定のOSPFインスタンスと同じドメインに属しているかどうかを判断できます。次に、そのルートをそのOSPFインスタンスにエリア間ルートとして再配布するのか、それともExtertferのOSPFとして再配布する必要があるかを判断できます。詳細については、セクション4.2.4および4.2.8.1をご覧ください。
When a type 3 LSA is sent from a PE router to a CE router, the DN bit [OSPF-DN] in the LSA Options field MUST be set. This is used to ensure that if any CE router sends this type 3 LSA to a PE router, the PE router will not redistribute it further.
タイプ3 LSAがPEルーターからCEルーターに送信される場合、LSAオプションフィールドのDNビット[OSPF-DN]を設定する必要があります。これは、CEルーターがこのタイプ3 LSAをPEルーターに送信した場合、PEルーターがそれをさらに再配布しないようにするために使用されます。
When a PE router needs to distribute to a CE router a route that comes from a site outside the latter's OSPF domain, the PE router presents itself as an ASBR (Autonomous System Border Router), and distributes the route in a type 5 LSA. The DN bit [OSPF-DN] MUST be set in these LSAs to ensure that they will be ignored by any other PE routers that receive them.
PEルーターがCEルーターに分配する必要がある場合、後者のOSPFドメインの外側のサイトから来るルートを使用する場合、PEルーターはASBR（自律システムの境界ルーター）としてそれ自体を提示し、5型LSAでルートを分散します。DNビット[OSPF-DN]をこれらのLSAに設定して、それらを受け取った他のPEルーターによって無視されるようにする必要があります。
There are deployed implementations that do not set the DN bit, but instead use OSPF route tagging to ensure that a type 5 LSA generated by a PE router will be ignored by any other PE router that may receive it. A special OSPF route tag, which we will call the VPN Route Tag (see Section 4.2.5.2), is used for this purpose. To ensure backward compatibility, all implementations adhering to this specification MUST by default support the VPN Route Tag procedures specified in Sections 4.2.5.2, 4.2.8.1, and 4.2.8.2. When it is no longer necessary to use the VPN Route Tag in a particular deployment, its use (both sending and receiving) may be disabled by configuration.
DNビットを設定しない展開された実装がありますが、代わりにOSPFルートタグ付けを使用して、PEルーターによって生成されたタイプ5 LSAが、受信する可能性のある他のPEルーターによって無視されるようにします。この目的のために、VPNルートタグ（セクション4.2.5.2を参照）を呼び出す特別なOSPFルートタグが使用されます。後方互換性を確保するために、この仕様に準拠したすべての実装は、デフォルトでセクション4.2.5.2、4.2.8.1、および4.2.8.2で指定されたVPNルートタグ手順をサポートする必要があります。特定の展開でVPNルートタグを使用する必要がなくなった場合、その使用（送信と受信の両方）が構成によって無効になる場合があります。
If a particular VRF in a PE is associated with an instance of OSPF, then by default it MUST be configured with a special OSPF route tag value, which we call the VPN Route Tag. By default, this route tag MUST be included in the Type 5 LSAs that the PE originates (as the result of receiving a BGP-distributed VPN-IPv4 route, see Section 4.2.8) and sends to any of the attached CEs.
PEの特定のVRFがOSPFのインスタンスに関連付けられている場合、デフォルトでは、VPNルートタグと呼ばれる特別なOSPFルートタグ値で構成する必要があります。デフォルトでは、このルートタグは、PEが発生するタイプ5 LSAに含めなければなりません（BGP分配VPN-IPV4ルートを受信した結果、セクション4.2.8を参照）。
The configuration and inclusion of the VPN Route Tag is required for backward compatibility with deployed implementations that do not set the DN bit in type 5 LSAs. The inclusion of the VPN Route Tag may be disabled by configuration if it has been determined that it is no longer needed for backward compatibility.
VPNルートタグの構成と包含は、タイプ5 LSAでDNビットを設定しない展開された実装との後方互換性に必要です。VPNルートタグを含めることは、後方互換性に必要でないと判断された場合、構成によって無効になる場合があります。
The value of the VPN Route Tag is arbitrary but must be distinct from
any OSPF Route Tag being used within the OSPF domain. Its value MUST
therefore be configurable. If the Autonomous System number of the
VPN backbone is two bytes long, the default value SHOULD be an
automatically computed tag based on that Autonomous System number:
Tag = <Automatic = 1, Complete = 1, PathLength = 01>
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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|0|1| ArbitraryTag | AutonomousSystem |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 _AS number of the VPN Backbone_
1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 _ vpn backbone_の番号_
If the Autonomous System number is four bytes long, then a Route Tag value MUST be configured, and it MUST be distinct from any Route Tag used within the VPN itself.
自律システム番号の長さが4バイトの場合、ルートタグ値を構成する必要があり、VPN自体で使用されるルートタグとは異なる必要があります。
If a PE router needs to use OSPF to distribute to a CE router a route that comes from a site outside the CE router's OSPF domain, the PE router SHOULD present itself to the CE router as an Autonomous System Border Router (ASBR) and SHOULD report such routes as AS-external routes. That is, these PE routers originate Type 5 LSAs reporting the extra-domain routes as AS-external routes. Each such Type 5 LSA MUST contain an OSPF route tag whose value is that of the VPN Route Tag. This tag identifies the route as having come from a PE router. The VPN Route Tag MUST be used to ensure that a Type 5 LSA originated by a PE router is not redistributed through the OSPF area to another PE router.
PEルーターがOSPFを使用してCEルーターにCEルーターのOSPFドメインの外側のサイトから来るルートに配布する必要がある場合、PEルーターは自律システムの境界ルーター（ASBR）としてCEルーターに現れる必要があります。そのような外部ルートなど。つまり、これらのPEルーターは、エクスタナルルートとしてドメイン外ルートを報告するタイプ5 LSAを開始します。このようなタイプ5 LSAには、VPNルートタグの値がその値のOSPFルートタグを含める必要があります。このタグは、ルートをPEルーターから来たものとして識別します。VPNルートタグを使用して、PEルーターから発信されたタイプ5 LSAがOSPFエリアを介して別のPEルーターに再配布されないことを確認する必要があります。
The procedures specified in this document ensure that if routing information derived from a BGP-distributed VPN-IPv4 route is distributed into OSPF, it cannot be redistributed back into BGP as a VPN-IPv4 route, as long as the DN bit and/or VPN route tag is maintained within the OSPF domain. This does not eliminate all possible sources of loops. For example, if a BGP VPN-IPv4 route is distributed into OSPF, then distributed into RIP (where all the information needed to prevent looping is lost), and then distributed back into OSPF, then it is possible that it could be distributed back into BGP as a VPN-IPv4 route, thereby causing a loop.
このドキュメントで指定された手順により、BGPに寄付されたVPN-IPV4ルートから派生したルーティング情報がOSPFに配布される場合、DNビットおよび/またはVPNである限り、VPN-IPV4ルートとしてBGPに再配布することはできません。ルートタグはOSPFドメイン内で維持されます。これは、可能なすべてのループソースを排除しません。たとえば、BGP VPN-IPV4ルートがOSPFに分布している場合、RIP（ループを防ぐために必要なすべての情報が失われる場合）に分散し、OSPFに分布すると、VPN-IPV4ルートとしてのBGPでは、ループを引き起こします。
Therefore, extreme care must be taken if there is any mutual redistribution of routes between the OSPF domain and any third routing domain (i.e., not the VPN backbone). If the third routing domain is a BGP domain (e.g., the public Internet), the ordinary BGP loop prevention measures will prevent the route from reentering the OSPF domain.
したがって、OSPFドメインと3番目のルーティングドメイン（つまり、VPNバックボーンではなく）の間にルートの相互再分配がある場合は、極度の注意を払う必要があります。3番目のルーティングドメインがBGPドメイン（パブリックインターネットなど）である場合、通常のBGPループ予防測定により、ルートがOSPFドメインに再び入ることができなくなります。
This section specifies the way in which a PE router handles the OSPF LSAs it receives from a CE router.
このセクションでは、PEルーターがCEルーターから受信するOSPF LSAを処理する方法を指定します。
When a PE router receives, from a CE router, any LSA with the DN bit [OSPF-DN] set, the information from that LSA MUST NOT be used by the route calculation. If a Type 5 LSA is received from the CE, and if it has an OSPF route tag value equal to the VPN Route Tag (see Section 4.2.5.2), then the information from that LSA MUST NOT be used by the route calculation.
CEルーターからPEルーターがDNビット[OSPF-DN]セットを備えたLSAを受信した場合、そのLSAからの情報はルート計算で使用してはなりません。タイプ5 LSAがCEから受信され、VPNルートタグに等しいOSPFルートタグ値がある場合（セクション4.2.5.2を参照）、そのLSAからの情報はルート計算で使用してはなりません。
Otherwise, the PE must examine the corresponding VRF. For every address prefix that was installed in the VRF by one of its associated OSPF instances, the PE must create a VPN-IPv4 route in BGP. Each such route will have some of the following Extended Communities attributes:
それ以外の場合、PEは対応するVRFを調べる必要があります。関連するOSPFインスタンスの1つによってVRFにインストールされたすべてのアドレスプレフィックスについて、PEはBGPにVPN-IPV4ルートを作成する必要があります。このようなルートには、次の拡張コミュニティ属性の一部があります。
- The OSPF Domain Identifier Extended Communities attribute. If the OSPF instance that installed the route has a non-NULL primary Domain Identifier, this MUST be present; if that OSPF instance has only a NULL Domain Identifier, it MAY be omitted. This attribute is encoded with a two-byte type field, and its type is 0005, 0105, or 0205. For backward compatibility, the type 8005 MAY be used as well and is treated as if it were 0005. If the OSPF instance has a NULL Domain Identifier, and the OSPF Domain Identifier Extended Communities attribute is present, then the attribute's value field must be all zeroes, and its type field may be any of 0005, 0105, 0205, or 8005.
- OSPFドメイン識別子拡張コミュニティ属性。ルートをインストールしたOSPFインスタンスに非ヌルプライマリドメイン識別子がある場合、これが存在する必要があります。そのOSPFインスタンスにnullドメイン識別子のみがある場合、省略される場合があります。この属性は2バイトタイプフィールドでエンコードされ、そのタイプは0005、0105、または0205です。後方互換性のために、タイプ8005も使用でき、0005のように扱われます。nullドメイン識別子、およびOSPFドメイン識別子拡張コミュニティ属性が存在する場合、属性の値フィールドはすべてゼロでなければならず、そのタイプフィールドは0005、0105、0205、または8005のいずれかである場合があります。
- OSPF Route Type Extended Communities Attribute. This attribute MUST be present. It is encoded with a two-byte type field, and its type is 0306. To ensure backward compatibility, the type 8000 SHOULD be accepted as well and treated as if it were type 0306. The remaining six bytes of the Attribute are encoded as follows:
- OSPFルートタイプの拡張コミュニティ属性。この属性は存在する必要があります。2バイトタイプフィールドでエンコードされ、そのタイプは0306です。後方互換性を確保するには、タイプ8000も受け入れ、タイプ0306のように扱う必要があります。：
+-------+-------+-------+-------+-------+-------+
| Area Number | Route |Options|
| | Type | |
+-------+-------+-------+-------+-------+-------+
* Area Number: 4 bytes, encoding a 32-bit area number. For AS-external routes, the value is 0. A non-zero value identifies the route as being internal to the OSPF domain, and as being within the identified area. Area numbers are relative to a particular OSPF domain.
* エリア番号：4バイト、32ビットエリア番号をエンコードします。as-externalルートの場合、値は0です。非ゼロ値は、ルートをOSPFドメインの内部であり、特定された領域内にあると識別します。面積番号は、特定のOSPFドメインに関連しています。
* OSPF Route Type: 1 byte, encoded as follows:
* OSPFルートタイプ：1バイト、次のようにエンコードされています。
** 1 or 2 for intra-area routes (depending on whether the route came from a type 1 or a type 2 LSA).
**エリア内ルートの場合は1または2（ルートがタイプ1またはタイプ2 LSAから来たかどうかに応じて）。
** 3 for inter-area routes.
** 3つのエリア間ルートの場合。
** 5 for external routes (area number must be 0).
**外部ルートの場合（エリア番号は0でなければなりません）。
** 7 for NSSA routes.
** NSSAルートの場合。
Note that the procedures of Section 4.2.8 do not make any distinction between routes types 1, 2, and 3. If BGP installs a route of one of these types in the VRF, and if that route is selected for redistribution into OSPF, it will be advertised by OSPF in either a type 3 or a type 5 LSA, depending on the domain identifier.
セクション4.2.8の手順は、ルートタイプ1、2、および3を区別しないことに注意してください。BGPがVRFにこれらのタイプの1つのルートをインストールする場合、およびそのルートがOSPFへの再配布のために選択されている場合、ドメイン識別子に応じて、タイプ3またはタイプ5 LSAのいずれかでOSPFによって宣伝されます。
* Options: 1 byte. Currently, this is only used if the route type is 5 or 7. Setting the least significant bit in the field indicates that the route carries a type 2 metric.
* オプション：1バイト。現在、これは、ルートタイプが5または7の場合にのみ使用されます。フィールドで最小のビットを設定すると、ルートがタイプ2メトリックがあることを示します。
- OSPF Router ID Extended Communities Attribute. This OPTIONAL attribute specifies the OSPF Router ID of the system that is identified in the BGP Next Hop attribute. More precisely, it specifies the OSPF Router Id of the PE in the OSPF instance that installed the route into the VRF from which this route was exported. This attribute is encoded with a two-byte type field, and its type is 0107, with the Router ID itself carried in the first 4 bytes of the value field. The type 8001 SHOULD be accepted as well, to ensure backward compatibility, and should be treated as if it were 0107.
- OSPFルーターID拡張コミュニティ属性。このオプション属性は、BGP Next Hop属性で識別されるシステムのOSPFルーターIDを指定します。より正確には、このルートがエクスポートされたVRFにルートをインストールしたOSPFインスタンスのPEのOSPFルーターIDを指定します。この属性は2バイトタイプフィールドでエンコードされており、そのタイプは0107で、ルーターID自体は値フィールドの最初の4バイトに掲載されています。タイプ8001も同様に受け入れられ、後方互換性を確保し、0107のように扱う必要があります。
- MED (Multi_EXIT_DISC attribute). By default, this SHOULD be set to the value of the OSPF distance associated with the route, plus 1.
- Med（multi_exit_disc属性）。デフォルトでは、これはルートに関連付けられたOSPF距離の値と1に設定する必要があります。
The intention of all this is the following. OSPF Routes from one site are converted to BGP, distributed across the VPN backbone, and possibly converted back to OSPF routes before being distributed into another site. With these attributes, BGP carries enough information about the route to enable the route to be converted back into OSPF "transparently", just as if BGP had not been involved.
これのすべての意図は次のとおりです。1つのサイトからのOSPFルートはBGPに変換され、VPNバックボーン全体に配布され、おそらく別のサイトに配布される前にOSPFルートに戻る可能性があります。これらの属性を使用すると、BGPは、BGPが関与していないかのように、ルートをOSPFに「透過的」に戻すことができるようにルートに関する十分な情報を提供します。
Routes that a PE receives in type 4 LSAs MUST NOT be redistributed to BGP.
PEがタイプ4 LSAで受け取るルートをBGPに再配布してはなりません。
The attributes specified above are in addition to any other attributes that routes must carry in accordance with [VPN].
上記で指定された属性は、ルートが[VPN]に従って携帯する必要がある他の属性に追加されます。
The Site of Origin attribute, which is usually required by [VPN], is OPTIONAL for routes that a PE learns from a CE via OSPF.
通常、[VPN]で必要とされるOriginの属性は、PEがOSPFを介してCEから学習するルートに対してオプションです。
Use of the Site of Origin attribute would, in the case of a multiply homed site (i.e., a site attached to several PE routers), prevent an intra-site route from being reinjected into a site from the VPN backbone. Such a reinjection would not harm the routing, because the route via the VPN backbone would be advertised in a type 3 LSA, and hence would appear to be an inter-area route; the real intra-area route would be preferred. But unnecessary overhead would be introduced. On the other hand, if the Site of Origin attribute is not used, a partitioned site will find itself automatically repaired, since traffic from one partition to the other will automatically travel via the VPN backbone. Therefore, the use of a Site of Origin attribute is optional, so that a trade-off can be made between the cost of the increased overhead and the value of automatic partition repair.
原点属性の使用は、複数のホームされたサイト（つまり、いくつかのPEルーターに接続されたサイト）の場合、サイト内ルートがVPNバックボーンからサイトに再注入されないようにします。このような再注入は、VPNバックボーンを介したルートがタイプ3 LSAで宣伝されるため、ルーティングに害を及ぼすことはありません。したがって、エリア間ルートのように見えます。実際のエリア内ルートが推奨されます。しかし、不必要なオーバーヘッドが導入されます。一方、Originの属性を使用していない場合、あるパーティションからもう一方のパーティションへのトラフィックはVPNバックボーンを介して自動的に移動するため、分割されたサイトが自動的に修復されます。したがって、原点属性の使用はオプションであるため、オーバーヘッドの増加と自動パーティション修理の値との間にトレードオフを行うことができます。
This section describes the protocol and procedures necessary for the support of "Sham Links," as defined herein. Support for sham links is an OPTIONAL feature of this specification.
このセクションでは、本明細書で定義されている「偽リンク」のサポートに必要なプロトコルと手順について説明します。Shamリンクのサポートは、この仕様のオプションの機能です。
Suppose that there are two sites in the same OSPF area. Each site is attached to a different PE router, and there is also an intra-area OSPF link connecting the two sites.
同じOSPFエリアに2つのサイトがあると仮定します。各サイトは別のPEルーターに接続されており、2つのサイトを接続するエリア内のOSPFリンクもあります。
It is possible to treat these two sites as a single VPN site that just happens to be multihomed to the backbone. This is in fact the simplest thing to do and is perfectly adequate, provided that the preferred route between the two sites is via the intra-area OSPF link (a "backdoor link"), rather than via the VPN backbone. There will be routes between sites that go through the PE routers, but these routes will appear to be inter-area routes, and OSPF will consider them less preferable than the intra-area routes through the backdoor link.
これら2つのサイトを、たまたまバックボーンにマルチホームしている単一のVPNサイトとして扱うことができます。実際、これは最も単純なことであり、2つのサイト間の優先ルートがVPNバックボーンを介してではなく、エリア内のOSPFリンク（「バックドアリンク」）を介して行われることを条件に、完全に適切です。PEルーターを通過するサイト間にルートがありますが、これらのルートはエリア間ルートのように見え、OSPFはバックドアリンクを通るエリア内ルートよりも好ましくないと見なします。
If it is desired to have OSPF prefer the routes through the backbone over the routes through the backdoor link, then the routes through the backbone must be appear to be intra-area routes. To make a route through the backbone appear to be an intra-area route, it is necessary to make it appear as if there is an intra-area link connecting the two PE routers. This is what we refer to as a "sham link". (If the two sites attach to the same PE router, this is of course not necessary.)
OSPFにバックドアリンクを通るルートを介してバックボーンを通るルートを好むことが望ましい場合は、バックボーンを通るルートがエリア内ルートのように見える必要があります。バックボーンを通過するルートをエリア内ルートのように見せるためには、2つのPEルーターを接続するエリア内リンクがあるかのように表示される必要があります。これは私たちが「偽のリンク」と呼ぶものです。（2つのサイトが同じPEルーターに接続されている場合、これはもちろん必要ありません。）
A sham link can be thought of as a relation between two VRFs. If two VRFs are to be connected by a sham link, each VRF must be associated with a "Sham Link Endpoint Address", a 32-bit IPv4 address that is treated as an address of the PE router containing that VRF. The Sham Link Endpoint Address is an address in the VPN's address space, not the SP's address space. The Sham Link Endpoint Address associated with a VRF MUST be configurable. If the VRF is associated with only a single OSPF instance, and if the PE's router id in that OSPF instance is an IP address, then the Sham Link Endpoint Address MAY default to that Router ID. If a VRF is associated with several OSPF instances, each sham link belongs to a single OSPF instance.
偽のリンクは、2つのVRFの関係と考えることができます。2つのVRFを偽のリンクで接続する場合、各VRFは、そのVRFを含むPEルーターのアドレスとして扱われる32ビットIPv4アドレスである「偽リンクエンドポイントアドレス」に関連付けられている必要があります。SHAMリンクエンドポイントアドレスは、SPのアドレススペースではなく、VPNのアドレススペースのアドレスです。VRFに関連付けられた偽のリンクエンドポイントアドレスは、構成可能でなければなりません。VRFが単一のOSPFインスタンスのみに関連付けられている場合、およびそのOSPFインスタンスのPEのルーターIDがIPアドレスである場合、SHAMリンクエンドポイントアドレスはそのルーターIDにデフォルトする場合があります。VRFがいくつかのOSPFインスタンスに関連付けられている場合、各偽リンクは単一のOSPFインスタンスに属します。
For a given OSPF instance, a VRF needs only a single Sham Link Endpoint Address, no matter how many sham links it has. The Sham Link Endpoint Address MUST be distributed by BGP as a VPN-IPv4 address whose IPv4 address prefix part is 32 bits long. The Sham Link Endpoint Address MUST NOT be advertised by OSPF; if there is no BGP route to the Sham Link Endpoint Address, that address is to appear unreachable, so that the sham link appears to be down.
特定のOSPFインスタンスの場合、VRFは、どれだけの偽リンクがあるかに関係なく、単一の偽リンクエンドポイントアドレスのみを必要とします。SHAMリンクエンドポイントアドレスは、IPv4アドレスのプレフィックスパーツの長さの長さのVPN-IPV4アドレスとしてBGPによって配布する必要があります。偽のリンクエンドポイントアドレスは、OSPFによって宣伝されてはなりません。SHAMリンクエンドポイントアドレスへのBGPルートがない場合、そのアドレスは到達不可能に見えるため、偽のリンクがダウンしているように見えるようにします。
Sham links are manually configured.
偽のリンクは手動で構成されています。
For a sham link to exist between two VRFs, each VRF has to be configured to create a sham link to the other, where the "other" is identified by its sham link endpoint address. No more than one sham link with the same pair of sham link endpoint addresses will ever be created. This specification does not include procedures for single-ended manual configuration of the sham link.
2つのVRFの間に偽のリンクが存在するためには、各VRFを構成する必要があります。他のVRFは、他のVRFを作成する必要があります。ここで、「その他」が偽リンクエンドポイントアドレスによって識別されます。同じペアの偽リンクエンドポイントアドレスを含む1つの偽リンクが作成されません。この仕様には、偽リンクのシングルエンドの手動構成の手順は含まれていません。
Note that sham links may be created for any area, including area 0.
領域0を含むあらゆるエリアに対して偽リンクが作成される場合があることに注意してください。
A sham link connecting two VRFs is considered up if and only if a route to the 32-bit remote endpoint address of the sham link has been installed in VRF.
2つのVRFを接続する偽のリンクは、SHAMリンクの32ビットリモートエンドポイントアドレスへのルートがVRFにインストールされている場合にのみ、上昇します。
The sham link endpoint address MUST NOT be used as the endpoint address of an OSPF Virtual Link.
偽のリンクエンドポイントアドレスは、OSPF仮想リンクのエンドポイントアドレスとして使用してはなりません。
An OSPF protocol packet sent on a Sham Link from one PE to another must have as its IP source address the Sham Link Endpoint Address of the sender, and as its IP destination address the Sham Link Endpoint Address of the receiver. The packet will travel from one PE router to the other over the VPN backbone, which means that it can be expected to traverse multiple hops. As such, its TTL (Time to Live) field must be set appropriately.
OSPFプロトコルパケットは、1つのPEから別のPEへの偽リンクで送信されたPEソースアドレスとして、送信者の偽リンクエンドポイントアドレスとそのIP宛先アドレスとして、レシーバーの偽リンクエンドポイントアドレスをアドレスにします。パケットは、VPNバックボーンを越えて1つのPEルーターから別のPEルーターに移動します。つまり、複数のホップを通過することが期待できます。そのため、TTL（Live to Live）フィールドを適切に設定する必要があります。
An OSPF protocol packet is regarded as having been received on a particular sham link if and only if the following three conditions hold:
OSPFプロトコルパケットは、次の3つの条件が保持された場合にのみ、特定の偽リンクで受信されたと見なされます。
- The packet arrives as an MPLS packet, and its MPLS label stack causes it to be "delivered" to the local sham link endpoint address.
- パケットはMPLSパケットとして到着し、そのMPLSラベルスタックにより、ローカルShamリンクエンドポイントアドレスに「配信」されます。
- The packet's IP destination address is the local sham link endpoint address.
- パケットのIP宛先アドレスは、ローカルシャムリンクエンドポイントアドレスです。
- The packet's IP source address is the remote sham link endpoint address.
- パケットのIPソースアドレスは、リモートシャムリンクエンドポイントアドレスです。
Sham links SHOULD be treated by OSPF as OSPF Demand Circuits. This means that LSAs will be flooded over them, but periodic refresh traffic is avoided. Note that, as long as the backdoor link is up, flooding the LSAs over the sham link serves no purpose. However, if the backdoor link goes down, OSPF does not have mechanisms enabling the routers in one site to rapidly flush the LSAs from the other site. Therefore, it is still necessary to maintain synchronization among the LSA databases at the two sites, hence the flooding over the sham link.
偽のリンクは、OSPFによってOSPF需要回路として扱われるべきです。これは、LSAがそれらの上に浸水することを意味しますが、定期的な更新トラフィックは回避されます。バックドアリンクがアップしている限り、偽のリンク上にLSAをあふれさせることは目的を果たさないことに注意してください。ただし、バックドアリンクがダウンした場合、OSPFには、あるサイトのルーターが他のサイトからLSAを迅速に洗い流すメカニズムがありません。したがって、2つのサイトのLSAデータベース間で同期を維持する必要があるため、偽のリンク上に洪水が発生します。
The sham link is an unnumbered point-to-point intra-area link and is advertised as a type 1 link in a type 1 LSA.
SHAMリンクは、数え切れないほどのポイントツーポイント内部リンクであり、タイプ1 LSAのタイプ1リンクとして宣伝されています。
The OSPF metric associated with a sham link MUST be configurable (and there MUST be a configurable default). Whether traffic between the sites flows via a backdoor link or via the VPN backbone (i.e., via the sham link) depends on the settings of the OSPF link metrics. The metrics can be set so that the backdoor link is not used unless connectivity via the VPN backbone fails, for example.
偽のリンクに関連付けられたOSPFメトリックは、構成可能でなければなりません（また、設定可能なデフォルトが必要です）。サイト間のトラフィックがバックドアリンクを介して流れるか、VPNバックボーンを介して（つまり、偽リンクを介して）、OSPFリンクメトリックの設定に依存します。たとえば、VPNバックボーンを介した接続が失敗しない限り、バックドアリンクが使用されないようにメトリックを設定できます。
The default Hello Interval for sham links is 10 seconds, and the default Router Dead Interval for sham links is 40 seconds.
偽リンクのデフォルトのハロー間隔は10秒で、偽リンクのデフォルトのルーターデッドインターバルは40秒です。
If a PE determines that the next hop interface for a particular route is a sham link, then the PE SHOULD NOT redistribute that route into BGP as a VPN-IPv4 route.
PEが特定のルートの次のホップインターフェイスが偽のリンクであると判断した場合、PEはそのルートをVPN-IPv4ルートとしてBGPに再配布してはなりません。
Any other route advertised in an LSA that is transmitted over a sham link MUST also be redistributed (by the PE flooding the LSA over the sham link) into BGP. This means that if the preferred (OSPF) route for a given address prefix has the sham link as its next hop interface, then there will also be a "corresponding BGP route", for that same address prefix, installed in the VRF. Per Section 4.1.2, the OSPF route is preferred. However, when forwarding a packet, if the preferred route for that packet has the sham link as its next hop interface, then the packet MUST be forwarded according to the corresponding BGP route. That is, it will be forwarded as if the corresponding BGP route had been the preferred route. The "corresponding BGP route" is always a VPN-IPv4 route; the procedure for forwarding a packet over a VPN-IPv4 route is described in [VPN].
偽のリンクを介して送信されるLSAで宣伝されている他のルートも、（PEがLSAを偽のリンク上に浸水させることにより）BGPに再配布する必要があります。これは、特定のアドレスプレフィックスの優先（OSPF）ルートが次のホップインターフェイスとして偽のリンクを持っている場合、VRFにインストールされている同じアドレスプレフィックスに「対応するBGPルート」もあることを意味します。セクション4.1.2に従って、OSPFルートが推奨されます。ただし、パケットを転送する場合、そのパケットの優先ルートに次のホップインターフェイスとして偽のリンクがある場合、対応するBGPルートに従ってパケットを転送する必要があります。つまり、対応するBGPルートが好ましいルートであったかのように転送されます。「対応するBGPルート」は、常にVPN-IPV4ルートです。VPN-IPV4ルートにパケットを転送する手順は、[VPN]で説明されています。
This same rule applies to any packet whose IP destination address is the remote endpoint address of a sham link. Such packets MUST be forwarded according to the corresponding BGP route.
この同じルールは、IP宛先アドレスが偽のリンクのリモートエンドポイントアドレスであるパケットに適用されます。このようなパケットは、対応するBGPルートに従って転送する必要があります。
This section describes how the PE router handles VPN-IPv4 routes received via BGP.
このセクションでは、PEルーターがBGPを介して受信したVPN-IPV4ルートを処理する方法について説明します。
If a received BGP VPN-IPv4 route is not installed in the VRF, nothing is reported to the CE. A received route will not be installed into the VRF if the BGP decision process regards some other route as preferable. When installed in the VRF, the route appears to be an IPv4 route.
受信したBGP VPN-IPV4ルートがVRFにインストールされていない場合、CEには何も報告されません。BGP決定プロセスが他のルートを望ましいものと見なす場合、受信したルートはVRFにインストールされません。VRFにインストールされると、ルートはIPv4ルートのように見えます。
A BGP route installed in the VRF is not necessarily used for forwarding. If an OSPF route for the same IPv4 address prefix has been installed in the VRF, the OSPF route will be used for forwarding, except in the case where the OSPF route's next-hop interface is a sham link.
VRFに設置されたBGPルートは、必ずしも転送に使用されるわけではありません。同じIPv4アドレスプレフィックスのOSPFルートがVRFにインストールされている場合、OSPFルートの次のインターフェイスが偽リンクである場合を除き、OSPFルートは転送に使用されます。
If a BGP route installed in the VRF is used for forwarding, then the BGP route is redistributed into OSPF and possibly reported to the CEs in an OSPF LSA. The sort of LSA, if any, to be generated depends on various characteristics of the BGP route, as detailed in subsequent sections of this document.
VRFに設置されたBGPルートが転送に使用される場合、BGPルートはOSPFに再配布され、おそらくOSPF LSAのCESに報告されます。生成されるLSAの種類は、このドキュメントの後続のセクションで詳述されているように、BGPルートのさまざまな特性に依存します。
The procedure for forwarding a packet over a VPN-IPv4 route is described in [VPN].
VPN-IPV4ルートにパケットを転送する手順は、[VPN]で説明されています。
In the following, we specify what is reported, in OSPF LSAs, by the PE to the CE, assuming that the PE is not configured to do any further summarization or filtering of the routing information before reporting it to the CE.
以下では、PEがCEにPEで報告されている内容を指定し、PEがCEに報告する前にルーティング情報をさらに要約またはフィルタリングするように構成されていないと仮定します。
When sending an LSA to the CE, it may be necessary to set the DN bit. See Section 4.2.5.1 for the rules regarding the DN bit.
LSAをCEに送信する場合、DNビットを設定する必要がある場合があります。DNビットに関するルールについては、セクション4.2.5.1を参照してください。
When sending an LSA to the CE, it may be necessary to set the OSPF Route Tag. See Section 4.2.5.2 for the rules about setting the OSPF Route Tag.
LSAをCEに送信する場合、OSPFルートタグを設定する必要がある場合があります。OSPFルートタグの設定に関するルールについては、セクション4.2.5.2を参照してください。
When type 5 LSAs are sent, the Forwarding Address is set to 0.
タイプ5 LSAが送信されると、転送アドレスが0に設定されます。
With respect to a particular OSPF instance associated with a VRF, a VPN-IPv4 route that is installed in the VRF and then selected as the preferred route is treated as an External Route if one of the following conditions holds:
VRFに関連付けられた特定のOSPFインスタンスに関しては、VRFにインストールされ、優先ルートとして選択されるVPN-IPV4ルートが、次の条件のいずれかが保持される場合、外部ルートとして扱われます。
- The route type field of the OSPF Route Type Extended Community has an OSPF route type of "external".
- OSPFルートタイプの拡張コミュニティのルートタイプフィールドには、「外部」のOSPFルートタイプがあります。
- The route is from a different domain from the domain of the OSPF instance.
- ルートは、OSPFインスタンスのドメインとは異なるドメインからのものです。
The rules for determining whether a route is from a domain different from that of a particular OSPF instance are the following. The OSPF Domain Identifier Extended Communities attribute carried by the route is compared with the OSPF Domain Identifier Extended Communities attribute(s) with which the OSPF instance has been configured (if any). In general, when two such attributes are compared, all eight bytes must be compared. Thus, two OSPF Domain Identifier Extended Communities attributes are regarded as equal if and only if one of the following three conditions holds:
ルートが特定のOSPFインスタンスのドメインとは異なるドメインからであるかどうかを判断するためのルールが次のとおりです。ルートで運ばれるOSPFドメイン識別子拡張コミュニティ属性は、OSPFインスタンスが構成されている（存在する場合）に構成されているOSPFドメイン識別子拡張コミュニティ属性と比較されます。一般に、2つのそのような属性を比較する場合、8つのバイトすべてを比較する必要があります。したがって、2つのOSPFドメイン識別子拡張コミュニティ属性は、次の3つの条件のいずれかが保持された場合にのみ、等しいと見なされます。
1. They are identical in all eight bytes.
1. それらは8バイトすべてで同じです。
2. They are identical in their lower-order six bytes (value field), but one attribute has two high-order bytes (type field) of 0005 and the other has two high-order bytes (type field) of 8005. (This condition is for backward compatibility.)
2. それらは低次の6バイト（値フィールド）で同一ですが、1つの属性には0005の2つの高次バイト（タイプフィールド）があり、もう1つの属性には8005の2つの高次バイト（タイプフィールド）があります（この条件はその条件です。後方互換性のため。）
3. The lower-order six bytes (value field) of both attributes consist entirely of zeroes. In this case, the two attributes are considered identical irrespective of their type fields, and they are regarded as representing the NULL Domain Identifier.
3. 両方の属性の低次の6バイト（値フィールド）は、完全にゼロで構成されています。この場合、2つの属性はタイプフィールドに関係なく同一と見なされ、nullドメイン識別子を表すものと見なされます。
If a VPN-IPv4 route has an OSPF Domain Identifier Extended Communities attribute, we say that that route is in the identified domain. If the value field of the Extended Communities attribute consists of all zeroes, then the identified domain is the NULL domain, and the route is said to belong to the NULL domain. If the route does not have an OSPF Domain Identified Extended Communities attribute, then the route belongs to the NULL domain.
VPN-IPV4ルートにOSPFドメイン識別子拡張コミュニティ属性がある場合、そのルートは識別されたドメインにあると言います。拡張コミュニティの属性の値フィールドがすべてのゼロで構成されている場合、識別されたドメインはnullドメインであり、ルートはnullドメインに属すると言われています。ルートにOSPFドメインが識別された拡張コミュニティ属性を識別していない場合、ルートはnullドメインに属します。
Every OSPF instance is associated with one or more Domain Identifiers, though possibly only with the NULL domain identifier. If an OSPF instance is associated with a particular Domain Identifier, we will say that it belongs to the identified domain.
すべてのOSPFインスタンスは、おそらくNullドメイン識別子にのみ1つ以上のドメイン識別子に関連付けられています。OSPFインスタンスが特定のドメイン識別子に関連付けられている場合、それは識別されたドメインに属していると言います。
If a VPN-IPv4 route is to be redistributed to a particular instance, it must be determined whether that route and that OSPF instance belong to the same domain. A route and an OSPF instance belong to the same domain if and only if one of the following conditions holds:
VPN-IPV4ルートが特定のインスタンスに再配布される場合、そのルートとそのOSPFインスタンスが同じドメインに属するかどうかを決定する必要があります。次の条件のいずれかが保持されている場合にのみ、ルートとOSPFインスタンスが同じドメインに属します。
1. The route and the OSPF instance each belong to the NULL domain.
1. ルートとOSPFインスタンスはそれぞれnullドメインに属します。
2. The domain to which the route belongs is the domain to which the OSPF instance belongs. (That is, the route's Domain Identifier is equal to the OSPF instance's domain identifier, as determined by the definitions given earlier in this section.)
2. ルートが属するドメインは、OSPFインスタンスが属するドメインです。（つまり、ルートのドメイン識別子は、このセクションで前述した定義で決定されるように、OSPFインスタンスのドメイン識別子に等しくなります。）
If the route and the VRF do not belong to the same domain, the route is treated as an external route.
ルートとVRFが同じドメインに属していない場合、ルートは外部ルートとして扱われます。
If an external route is redistributed into an OSPF instance, the route may or may not be advertised to a particular CE, depending on the configuration and on the type of area to which the PE/CE link belongs. If the route is advertised, and the PE/CE link belongs to a NSSA area, it is advertised in a type 7 LSA. Otherwise, if the route is advertised, it is advertised in a type 5 LSA. The LSA will be originated by the PE.
外部ルートがOSPFインスタンスに再配布されている場合、ルートは、構成に応じて、PE/CEリンクが属する領域のタイプに応じて、特定のCEに宣伝されている場合と宣伝されている場合があります。ルートが宣伝され、PE/CEリンクがNSSAエリアに属している場合、タイプ7 LSAで宣伝されています。それ以外の場合、ルートが宣伝されている場合、5型LSAで宣伝されます。LSAはPEによって発信されます。
The DN bit (Section 4.2.5.1) MUST be set in the LSA. The VPN Route Tag (see Section 4.2.5.2) MUST be placed in the LSA, unless the use of the VPN Route Tag has been turned off by configuration.
DNビット（セクション4.2.5.1）は、LSAに設定する必要があります。VPNルートタグ（セクション4.2.5.2を参照）は、VPNルートタグの使用が構成によってオフになっていない限り、LSAに配置する必要があります。
By default, a type 2 metric value is included in the LSA, unless the options field of the OSPF Route Type Extended Communities attribute of the VPN-IPv4 route specifies that the metric should be type 1.
デフォルトでは、VPN-IPv4ルートの拡張コミュニティ属性のOSPFルートタイプのオプションフィールドが、メトリックがタイプ1であることを指定しない限り、タイプ2メトリック値がLSAに含まれます。
By default, the value of the metric is taken from the MED attribute of the VPN-IPv4 route. If the MED is not present, a default metric value is used. (The default type 1 metric and the default type 2 metric MAY be different.)
デフォルトでは、メトリックの値はVPN-IPV4ルートのMED属性から取得されます。MEDが存在しない場合、デフォルトのメトリック値が使用されます。（デフォルトのタイプ1メトリックとデフォルトのタイプ2メトリックは異なる場合があります。）
Note that this way of handling external routes makes every PE appear to be an ASBR attached to all the external routes. In a multihomed site, this can result in a number of type 5 LSAs containing the same information.
外部ルートを処理するこの方法により、すべてのPEがすべての外部ルートに接続されているASBRのように見えることに注意してください。マルチホームサイトでは、同じ情報を含む多くのタイプ5 LSAをもたらす可能性があります。
If a route and the VRF into which it is imported belong to the same domain, then the route should be treated as if it had been received in an OSPF type 3 LSA. This means that the PE will report the route in a type 3 LSA to the CE. (Note that this case is possible even if the VPN-IPv4 route carries an area number identical to that of the CE router. This means that if an area is "partitioned" such that the two pieces are connected only via the VPN backbone, it appears to be two areas, with inter-area routes between them.)
ルートとそれがインポートされるVRFが同じドメインに属している場合、ルートはOSPFタイプ3 LSAで受信されたかのように扱う必要があります。これは、PEがタイプ3 LSAのルートをCEに報告することを意味します。（VPN-IPV4ルートにCEルーターと同じ面積番号がある場合でも、このケースは可能であることに注意してください。これは、2つのピースがVPNバックボーンを介してのみ接続されるように領域が「分割」されている場合、2つの領域のように見え、エリア間のルートがそれらの間にルートがあります。）
NSSA routes are treated the same as external routes, as described in Section 4.2.8.1.
NSSAルートは、セクション4.2.8.1で説明されているように、外部ルートと同じように扱われます。
Section 11 of [EXTCOMM] calls upon IANA to create a registry for BGP Extended Communities Type Field and Extended Type Field values. Section 4.2.6 of this document assigns new values for the BGP Extended Communities Extended Type Field. These values all fall within the range of values that [EXTCOMM] states "are to be assigned by IANA, using the 'First Come, First Served' policy defined in RFC 2434".
[Extcomm]のセクション11は、IANAに、BGP拡張コミュニティタイプフィールドと拡張タイプフィールド値のレジストリを作成するよう呼びかけます。このドキュメントのセクション4.2.6は、BGP拡張コミュニティの拡張タイプフィールドに新しい値を割り当てます。これらの値はすべて、[extcomm]が「最初に来る、最初に提供される」ポリシーでRFC 2434で定義されたポリシーを使用して、[Extcomm]と述べている値の範囲内にあります。
The BGP Extended Communities Extended Type Field values assigned in Section 4.2.6 of this document are as follows:
このドキュメントのセクション4.2.6で割り当てられたBGP拡張コミュニティ拡張タイプのフィールド値は次のとおりです。
- OSPF Domain Identifier: Extended Types 0005, 0105, and 0205.
- OSPFドメイン識別子：拡張タイプ0005、0105、および0205。
- OSPF Route Type: Extended Type 0306
- OSPFルートタイプ：拡張タイプ0306
- OSPF Router ID: Extended Type 0107
- OSPFルーターID：拡張タイプ0107
Security considerations that are relevant in general to BGP/MPLS IP VPNS are discussed in [VPN] and [VPN-AS]. We discuss here only those security considerations that are specific to the use of OSPF as the PE/CE protocol.
一般にBGP/MPLS IP VPNに関連するセキュリティ上の考慮事項は、[VPN]および[VPN-AS]で説明されています。ここでは、PE/CEプロトコルとしてのOSPFの使用に固有のセキュリティ上の考慮事項のみについて説明します。
A single PE may be running OSPF as the IGP of the SP backbone network, as well as running OSPF as the IGP of one or more VPNs. This requires the use of multiple, independent OSPF instances, so that routes are not inadvertently leaked between the backbone and any VPN. The OSPF instances for different VPNs must also be independent OSPF instances, to prevent inadvertent leaking of routes between VPNs.
単一のPEは、SPバックボーンネットワークのIGPとしてOSPFを実行し、1つ以上のVPNのIGPとしてOSPFを実行している場合があります。これには、複数の独立したOSPFインスタンスを使用する必要があるため、バックボーンとVPNの間にルートが不注意に漏れないようにします。さまざまなVPNのOSPFインスタンスは、VPN間のルートの不注意な漏れを防ぐために、独立したOSPFインスタンスである必要があります。
OSPF provides a number of procedures that allow the OSPF control messages between a PE and a CE to be authenticated. OSPF "cryptographic authentication" SHOULD be used between a PE and a CE. It MUST be implemented on each PE.
OSPFは、PEとCEの間のOSPF制御メッセージを認証できるようにする多くの手順を提供します。OSPF「暗号化認証」は、PEとCEの間で使用する必要があります。各PEに実装する必要があります。
In the absence of such authentication, it is possible that the CE might not really belong to the VPN to which the PE assigns it. It may also be possible for an attacker to insert spoofed messages on the PE/CE link, in either direction. Spoofed messages sent to the CE could compromise the routing at the CE's site. Spoofed messages sent to the PE could result in improper VPN routing, or in a denial-of-service attack on the VPN.
このような認証がない場合、CEがPEが割り当てるVPNに実際に属していない可能性があります。また、攻撃者がどちらの方向にもPE/CEリンクにスプーフィングされたメッセージを挿入することも可能です。CEに送信されたスプーフィングされたメッセージは、CEのサイトのルーティングを損なう可能性があります。PEに送信されたスプーフィングされたメッセージは、不適切なVPNルーティング、またはVPNに対するサービス拒否攻撃につながる可能性があります。
Major contributions to this work have been made by Derek Yeung and Yakov Rekhter.
この作業への主要な貢献は、デレク・ヨンとヤコフ・レクターによって行われました。
Thanks to Ross Callon, Ajay Singhal, Russ Housley, and Alex Zinin for their review and comments.
ロス・カロン、アジャイ・シンハル、ラス・ヒューズリー、アレックス・ジニンのレビューとコメントに感謝します。
[EXTCOMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.
[Extcomm] Sangli、S.、Tappan、D。、およびY. Rekhter、「BGP拡張コミュニティ属性」、RFC 4360、2006年2月。
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPFV2] Moy、J。、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[OSPF-DN] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4576, June 2006.
[OSPF-DN] Rosen、E.、Psenak、P。、およびP. Pillay-Esnault、「Link State Advertisement（LSA）オプションを使用してBGP/MPLS IP仮想ネットワーク（VPNS）（VPNS）を防ぐ」、RFC4576、2006年6月。
[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月。
[VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[VPN] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）」、RFC 4364、2006年2月。
[BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[BGP] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RIP] Malkin、G。、「RIPバージョン2」、STD 56、RFC 2453、1998年11月。
[VPN-AS] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4365, February 2006.
[VPN-AS] Rosen、E。、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）のアプリケーションステートメント」、RFC 4365、2006年2月。
Authors' Addresses
著者のアドレス
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
エリックC.ローゼンシスコシステムズ、1414マサチューセッツアベニューボックスボロー、マサチューセッツ州01719
EMail: erosen@cisco.com
Peter Psenak Cisco Systems BA Business Center, 9th Floor Plynarenska 1 Bratislava 82109 Slovakia
Peter Psenak Cisco Systems BA Business Center、9階のPlynarenska 1 Bratislava 82109スロバキア
EMail: ppsenak@cisco.com
Padma Pillay-Esnault Cisco Systems 3750 Cisco Way San Jose, CA 95134
Padma Pillay-Esnault Cisco Systems 3750 Cisco Way San Jose、CA 95134
EMail: ppe@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。