[要約] RFC 5037は、Label Distribution Protocol（LDP）の経験に関する情報を提供するものです。このRFCの目的は、LDPの実装と運用に関する洞察を共有し、ネットワークのラベル配布に関するプロトコルの改善を促進することです。
Network Working Group L. Andersson, Ed.
Request for Comments: 5037 Acreo AB
Category: Informational I. Minei, Ed.
Juniper Networks
B. Thomas, Ed.
Cisco Systems, Inc.
October 2007
Experience with the Label Distribution Protocol (LDP)
ラベル分布プロトコル（LDP）の経験
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
The purpose of this memo is to document how some of the requirements specified in RFC 1264 for advancing protocols developed by working groups within the IETF Routing Area to Draft Standard have been satisfied by LDP (Label Distribution Protocol). Specifically, this report documents operational experience with LDP, requirement 5 of section 5.0 in RFC 1264.
このメモの目的は、IETFルーティング領域内のワーキンググループによって開発されたプロトコルの進歩についてRFC 1264で指定された要件の一部が、LDP（ラベル分布プロトコル）によって満たされていることを文書化することです。具体的には、このレポートは、RFC 1264のセクション5.0の要件5での運用経験を文書化しています。
Table of Contents
目次
1. Introduction ....................................................2
2. Operational Experience ..........................................2
2.1. Environment and Duration ...................................2
2.2. Applications and Motivation ................................3
2.3. Protocol Features ..........................................3
2.4. Security Concerns ..........................................4
2.5. Implementations and Inter-Operability ......................4
2.6. Operational Experience .....................................4
3. Security Considerations .........................................5
4. Acknowledgments .................................................5
5. References ......................................................6
5.1. Normative References .......................................6
5.2. Informative References .....................................6
The purpose of this memo is to document how some of the requirements specified in [RFC1264] for advancing protocols developed by working groups within the IETF Routing Area to Draft Standard have been satisfied by LDP. Specifically, this report documents operational experience with LDP, requirement 5 of section 5.0 in RFC 1264.
このメモの目的は、IETFルーティング領域内のワーキンググループが開発したプロトコルの進歩に関する[RFC1264]で指定された要件の一部が、LDPによって満たされていることを文書化することです。具体的には、このレポートは、RFC 1264のセクション5.0の要件5での運用経験を文書化しています。
LDP was originally published as [RFC3036] in January 2001. It was produced by the MPLS Working Group of the IETF and was jointly authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette, and Bob Thomas. It has since been obsoleted by [RFC5036].
LDPはもともと2001年1月に[RFC3036]として公開されました。IETFのMPLSワーキンググループによって生産され、Loa Andersson、Paul Doolan、Nancy Feldman、Andre Fredette、Bob Thomasが共同で執筆しました。その後、[RFC5036]によって廃止されました。
This section discusses operational experience with the protocol. The information is based on a survey sent to the MPLS Working Group in October 2004. The questionnaire can be found in the MPLS Working Group mail archives for October 2004.
このセクションでは、プロトコルでの運用体験について説明します。この情報は、2004年10月にMPLSワーキンググループに送信された調査に基づいています。アンケートは、2004年10月のMPLSワーキンググループアーカイブに記載されています。
11 responses were received, all but 2 requesting confidentiality. The survey results are summarized to maintain confidentiality. The networks surveyed span different geographic locations: US, Europe, and Asia. Both academic and commercial networks responded to the survey.
11回の回答が受信され、2回を除くすべてが機密性を要求しました。調査結果は、機密性を維持するために要約されています。調査したネットワークは、米国、ヨーロッパ、アジアのさまざまな地理的場所にまたがっています。アカデミックネットワークと商業ネットワークの両方が調査に回答しました。
The size of the deployments ranges from less than 20 Label Switching Routers (LSRs) to over 1000 LSRs. Eight out of the 11 deployments use LDP in the edge and the core, two on the edge only, and one in the core only.
展開のサイズは、20未満のラベルスイッチングルーター（LSR）から1000以上のLSRの範囲です。11の展開のうち8つは、エッジとコアでLDP、エッジのみに2つ、コアのみに1つを使用します。
Sessions exist to peers discovered via both the basic and the extended discovery mechanisms. In half the cases, more than one adjacency (and as many as four adjacencies) are maintained per session. The average number of LDP sessions on an LSR ranges from under 10 to just over 80. The responses are spread out as follows: under 10: 4 responses, 20-50: 4 responses, and over 80: 1 response.
基本的な発見メカニズムと拡張された発見メカニズムの両方を介して発見されたピアにセッションが存在します。半分のケースでは、セッションごとに複数の隣接（および4つの隣接）が維持されています。LSRのLDPセッションの平均数は、10歳未満の範囲です。応答は次のように広がります。10：4の回答、20-50：4の応答、80：1の応答。
In the surveyed networks, the time LDP has been deployed ranges from under 1 year to over 4 years. The responses are spread out as follows: under 1 year: 3 responses, 2 years: 2 responses, 3 years: 3 responses, and over 4 years: 3 responses.
調査対象のネットワークでは、LDPが展開された時間は1年未満から4年以上の範囲です。回答は次のように広がります：1年未満：3回の回答、2年：2回の回答、3年：3回の回答、4年以上：3回の応答。
Nine of the 11 responses list Layer 3 Virtual Private Networks (L3VPNs) as the application driving the LDP deployment in the network.
11の応答のうち9つは、ネットワークでのLDP展開を促進するアプリケーションとして、3つの仮想プライベートネットワーク（L3VPNS）をリストします。
The list of applications is as follows: L3VPNs: 9, pseudowires: 4 current (and one planned deployment), L2VPNs: 4, forwarding based on labels: 2, and BGP-free core: 1.
アプリケーションのリストは次のとおりです。L3VPNS：9、PSEUDOWIRES：4電流（および1つの計画展開）、L2VPNS：4、ラベルに基づく転送：2、およびBGPフリーコア：1。
There are two major options for label distribution protocols, LDP and Resource Reservation Protocol-Traffic Engineering (RSVP-TE). One of the key differences between the two is that RSVP-TE has support for traffic engineering, while LDP does not. The reasons cited for picking LDP as the label distribution protocol are:
ラベル分布プロトコル、LDPとリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）には2つの主要なオプションがあります。2つの主要な違いの1つは、RSVP-TEがトラフィックエンジニアリングをサポートしていることですが、LDPはそうではありません。ラベル分布プロトコルとしてLDPを選択した理由は次のとおりです。
o The deployment does not require traffic engineering - 6
o 展開にはトラフィックエンジニアリングは必要ありません-6
o Inter-operability concerns if a different protocol is used - 5
o 異なるプロトコルが使用されている場合、相互作用性の懸念-5
o Equipment vendor only supports LDP - 5
o 機器ベンダーはLDP -5のみをサポートしています
o Ease of configuration - 4
o 構成の容易さ-4
o Ease of management - 3
o 管理の容易さ-3
o Scalability concerns with other protocols - 3
o 他のプロトコルに対するスケーラビリティの関心-3
o Required for a service offering of the service provider - 1
o サービスプロバイダーのサービス提供に必要-1
All deployments surveyed use the Downstream Unsolicited Label Distribution mode. All but one deployment use Liberal Label retention (one uses conservative).
調査対象のすべての展開は、下流の未承諾ラベル分布モードを使用します。1つを除くすべての展開は、リベラルラベル保持を使用しています（1つは保守派を使用します）。
LSP setup is established with both independent and Ordered Control. Five of the deployments use both control modes in the same network.
LSPセットアップは、独立した制御と秩序化された制御の両方で確立されています。展開の5つは、同じネットワーク内の両方の制御モードを使用しています。
The number of LDP Forwarding Equivalence Classes (FECs) advertised and LDP routes installed falls in one of two categories: 1) roughly the same as the number of LSRs in the network and 2) roughly the same as the number of IGP routes in the network. Of the 8 responses that were received, 6 were in the first category and 2 in the second.
LDP転送等価クラス（FECS）の宣伝とインストールされたLDPルートの数は、2つのカテゴリのいずれかにあります。1）ネットワーク内のLSRの数とほぼ同じ、2）ネットワーク内のIGPルートの数とほぼ同じ。受信された8つの回答のうち、6つは最初のカテゴリに、2つは2つの回答でした。
A security concern was raised by one of the operators with respect to the lack of a mechanism for securing LDP Hellos.
LDP Hellosを保護するためのメカニズムの欠如に関して、オペレーターの1人によってセキュリティ上の懸念が提起されました。
Eight of the 11 responses state that more than one implementation (and as many as four different ones) are deployed in the same network.
11の回答のうち8つは、同じネットワークに複数の実装（および4つの異なるもの）が展開されていると述べています。
The consensus is that although implementations differ, no inter-operability issues exist. The challenges listed by providers running multiple implementations are:
コンセンサスは、実装が異なるが、操作性間の問題は存在しないということです。複数の実装を実行しているプロバイダーがリストする課題は次のとおりです。
o Different flexibility in picking for which FECs to advertise labels.
o FECがラベルを宣伝するピッキングにおけるさまざまな柔軟性。
o Different flexibility in setting transport and LDP router-id addresses.
o トランスポートとLDP Router-IDアドレスの設定における柔軟性が異なります。
o Different default utilization of LDP labels for traffic resolution. Some vendors use LDP for both VPN and IPv4 traffic forwarding, while other vendors allow only VPN traffic to resolve via LDP. The challenge is to restrict the utilization of LDP labels to VPN traffic in a mixed-vendor environment.
o トラフィック解決のためのLDPラベルの異なるデフォルト使用率。一部のベンダーは、VPNとIPv4トラフィック転送の両方にLDPを使用していますが、他のベンダーではVPNトラフィックのみがLDPを介して解決します。課題は、混合ベンダー環境でのLDPラベルのVPNトラフィックへの利用を制限することです。
o Understanding the differences in the implementations.
o 実装の違いを理解する。
In general, operators reported stable implementations and steady improvement in resiliency to failure and convergence times over the years. Some operators reported that no issues were found with the protocol since deploying.
一般に、オペレーターは安定した実装と、長年にわたって故障と収束時間の回復力の着実な改善を報告しました。一部のオペレーターは、展開以来プロトコルで問題が発見されていないと報告しました。
The operational issues reported fall in three categories:
報告された運用上の問題は、3つのカテゴリにあります。
1. Configuration issues. Both the session and adjacency endpoints must be allowed by the firewall filters. Misconfiguration of the filters causes sessions to drop (if already established) or not to establish.
1. 構成の問題。セッションと隣接のエンドポイントの両方が、ファイアウォールフィルターによって許可される必要があります。フィルターの誤解により、セッションが低下します（すでに確立されている場合）または確立しません。
2. Vendor bugs. These include traffic blackholing, unnecessary label withdrawals and changes, session resets, and problems migrating from older versions of the technology. Most reports stated that the problems reported occurred in early versions of the implementations.
2. ベンダーバグ。これらには、トラフィックブラックホール、不要なラベルの引き出しと変更、セッションリセット、およびテクノロジーの古いバージョンから移行する問題が含まれます。ほとんどのレポートは、報告された問題は実装の初期バージョンで発生したと述べました。
3. Protocol issues.
3. プロトコルの問題。
- The synchronization required between LDP and the IGP was listed as the main protocol issue. Two issues were reported: 1) slow convergence, due to the fact that LDP convergence time is tied to the IGP convergence time, and 2) traffic blackholing on a link-up event. When an interface comes up, the LDP session may come up slower than the IGP session. This results in dropping MPLS traffic for a link-up event (not a failure but a restoration). This issue is described in more detail in [LDP-SYNC].
- LDPとIGPの間に必要な同期は、主要なプロトコルの問題としてリストされました。2つの問題が報告されました。1）LDP収束時間がIGP収束時間に結び付けられているという事実と2）リンクアップイベントでのトラフィックブラックホリングのために、収束が遅いことが報告されました。インターフェイスが発生すると、LDPセッションがIGPセッションよりも遅くなる可能性があります。これにより、リンクアップイベントのMPLSトラフィックが削除されます（障害ではなく、復元）。この問題については、[LDP-Sync]で詳細に説明します。
- Silent failures. Failure not being propagated to the head end of the LSP when setting up LSPs using independent control.
- サイレント失敗。独立したコントロールを使用してLSPをセットアップするときに、LSPのヘッドエンドに障害が伝播されません。
This document is a survey of experiences from deployment of LDP implementations; it does not specify any protocol behavior. Thus, security issues introduced by the document are not discussed.
このドキュメントは、LDP実装の展開による経験の調査です。プロトコルの動作は指定されていません。したがって、ドキュメントによって導入されたセキュリティの問題については説明しません。
The editors would like to thank the operators who participated in the survey for their valuable input: Shane Amante, Niclas Comstedt, Bruno Decraene, Mourad Kaddache, Kam Lee Yap, Lei Wang, and Otto Kreiter. Not all who participated are listed here, due to confidentiality requests. Those listed have given their consent.
編集者は、Shane Amante、Niclas Comstedt、Bruno Decraene、Mourad Kaddache、Kam Lee Yap、Lei Wang、およびOtto Kreiterなど、貴重な意見について調査に参加したオペレーターに感謝したいと思います。参加したすべての人が、機密性の要求のためにここにリストされているわけではありません。リストされている人は彼らの同意を与えました。
Also, a big thank you to Scott Bradner, who acted as an independent third party ensuring anonymity of the responses.
また、反応の匿名性を確保する独立した第三者として行動したスコット・ブラッドナーに感謝します。
The editors would like to thank Rajiv Papneja, Halit Ustundag, and Loa Andersson for their input to the survey questionnaire.
編集者は、調査アンケートへの入力について、Rajiv Papneja、Halit Ustundag、およびLoa Anderssonに感謝します。
[RFC1264] Hinden, R., "Internet Engineering Task Force Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991.
[RFC1264] Hinden、R。、「インターネットエンジニアリングタスクフォースインターネットルーティングプロトコル標準化基準」、RFC 1264、1991年10月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036] Andersson、L.、Doolan、P.、Feldman、N.、Fredette、A。、およびB. Thomas、「LDP仕様」、RFC 3036、2001年1月。
[RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004.
[RFC3815] Cucchiara、J.、Sjostrand、H。、およびJ. Luciani、「マルチプロトコルラベルスイッチング（MPLS）の管理オブジェクトの定義、ラベル分布プロトコル（LDP）」、RFC 3815、2004年6月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Minei、I。、およびB. Thomas、「LDP仕様」、RFC 5036、2007年10月。
[LDP-SYNC] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", Work in Progress, July 2007.
[LDP-Sync] Jork、M.、Atlas、A。、およびL. Fang、「LDP IGP同期」、2007年7月、進行中の作業。
Editors' Addresses
編集者のアドレス
Loa Andersson Acreo AB Isafjordsgatan 22 Kista, Sweden EMail: loa.andersson@acreo.se loa@pi.se
loa andersson acreo ab isafjordsgatan 22キスタ、スウェーデンのメール：loa.andersson@acreo.se loa@pi.se
Ina Minei Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 EMail: ina@juniper.net
ina misei juniperネットワーク1194 N.Mathilda Ave Sunnyvale、CA 94089メール：ina@juniper.net
Bob Thomas Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 EMail: rhthomas@cisco.com
Bob Thomas Cisco Systems、Inc。1414 Massachusetts Ave Boxborough、MA 01719メール：rhthomas@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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への情報をお問い合わせください。