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)
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（ラベル配布プロトコル）によって満たされているか文書化することです。具体的には、この報告書は、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によって満たされたか文書化することです。具体的には、この報告書は、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].
自民党は当初、それはIETFのMPLSワーキンググループによって作成されたと共同でロア・アンダーソン、ポールDoolan、ナンシー・フェルドマン、アンドレFredette、ボブトーマスによって書かれた2001年1月[RFC3036]として発行されました。それ以来、[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は、機密性を要求して、受け取りました。調査結果は、機密性を維持するために要約されています。調査対象のネットワークが地理的に異なる場所にまたがる：US、ヨーロッパ、およびアジア。両方の学術および商用ネットワークは、調査に回答しました。
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の展開のうち八つは、エッジとエッジのみにコア、2つだけのコア内の1つにLDPを使用します。
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つの隣接）はセッションごとに維持されます。 4応答、20-50：10下：4つの応答、及び80上：反応1 LSRにLDPセッションの平均数は10の下からわずか80上の応答は次のように広がっている範囲です。
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.
調査対象のネットワークでは、時間自民党は4年以上にわたり、1歳未満からの範囲が展開されています。次のように応答が広がっている：1歳未満：3つの応答、2年：2つの応答、3年：3件の回答：3つの応答、および4年間で。
Nine of the 11 responses list Layer 3 Virtual Private Networks (L3VPNs) as the application driving the LDP deployment in the network.
11件の回答リストレイヤ3個の仮想プライベートネットワーク（L3VPNs）の九アプリケーションは、ネットワーク内のLDPの配備を駆動するように。
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.
ラベルに基づいて4、フォワーディング：L3VPNs：9、スードワイヤ：4の電流（一の計画展開）のL2VPN 2、及びBGP-フリーコア：アプリケーションのリストは以下の通りです。
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間の主な相違点の一つは、自民党にはないながら、RSVP-TEは、トラフィックエンジニアリングをサポートしているということです。ラベル配布プロトコルとして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
5 - O機器ベンダーはLDPをサポートしています
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
1 - Oサービスプロバイダのサービス提供に必要な
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転送等価クラスの数（のFEC）は、アドバタイズとLDP経路は、2つのカテゴリのいずれかに入るインストール：おおよそネットワーク内のLSRの数と同じと1）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 helloを確保するための仕組みの欠如に対する事業者の一つで育てられました。
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は、複数の実装（および四つの異なるものと同数）が同じネットワーク内に展開された状態。
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.
ラベルをアドバタイズするためのFECを選んでO異なり柔軟性。
o Different flexibility in setting transport and LDP router-id addresses.
輸送およびLDPルータIDアドレスを設定する際にO異なり柔軟性。
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.
トラフィックの解決のためのLDPラベルのO異なるデフォルトの使用率。他のベンダーのみVPNトラフィックが自民党を経由して解決することができながら、いくつかのベンダーは、VPNとIPv4トラフィック転送の両方にLDPを使用しています。課題は、混合ベンダー環境でVPNトラフィックにLDPラベルの利用を制限することです。
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.ベンダーのバグ。これらは、トラフィックのブラックホール、不要なラベルの引き出しや変更、セッションのリセット、および技術の旧バージョンからの移行の問題が含まれます。ほとんどのレポートは、報告された問題は、実装の初期のバージョンで発生したと述べました。
- 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との間に必要な同期化は、主プロトコルの問題として記載されていました。二つの問題が報告された：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.
シェーンAmante、ニクラスComstedt、ブルーノDecraene、Mourad Kaddache、カム・リーヤップ、レイ王、そしてオットー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.
編集者は、調査票への入力のためのラジブPapneja、Halit Ustundag、及びロア・アンダーソンに感謝したいと思います。
[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]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.、およびB.トーマス、 "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.ルチアーニは、 "マルチプロトコルラベルのための管理オブジェクトの定義は、スイッチング（MPLS）、ラベル配布プロトコル（LDP）"、RFC 3815、2004年6月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036]アンデション、L.、Minei、I.、およびB.トーマス、 "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.、アトラス、A.、およびL.牙、 "LDP IGP同期"、進歩、2007年7月の作業。
Editors' Addresses
エディタのアドレス
Loa Andersson Acreo AB Isafjordsgatan 22 Kista, Sweden EMail: loa.andersson@acreo.se loa@pi.se
ロア・アンダーソン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
伊那Mineiジュニパーネットワークス1194 N.Mathildaアベニューサニーベール、CA 94089 Eメール：ina@juniper.net
Bob Thomas Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 EMail: rhthomas@cisco.com
ボブトーマスシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 Eメール：rhthomas@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。