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
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.
本备忘录的目的是记录LDP（标签分发协议）如何满足RFC 1264中规定的一些要求，这些要求用于推进IETF路由区域内工作组制定的协议，以起草标准。具体而言，本报告记录了RFC 1264第5.0节要求5中LDP的运行经验。
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
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.
本备忘录的目的是记录LDP如何满足[RFC1264]中规定的某些要求，以推进IETF路由区域内工作组制定的协议，以起草标准。具体而言，本报告记录了RFC 1264第5.0节要求5中LDP的运行经验。
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，两个部署在边缘，一个部署在核心中。
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.
会话存在于通过基本和扩展发现机制发现的对等方。在一半的情况下，每个会话维护一个以上的邻接（多达四个邻接）。LSR上的LDP会话平均数量从10个以下到80多个不等。回答分布如下：低于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个将第3层虚拟专用网络（L3VPN）列为驱动网络中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.
应用程序列表如下：L3VPN:9、伪线：4个当前（和一个计划部署）、L2VPN: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）。两者之间的关键区别之一是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).
调查的所有部署都使用下游未经请求的标签分发模式。除一个部署外，所有部署都使用自由标签保留（一个使用保守标签保留）。
LSP setup is established with both independent and Ordered Control. Five of the deployments use both control modes in the same network.
LSP设置是通过独立和有序控制建立的。其中五种部署在同一网络中使用这两种控制模式。
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路由的数量分为两类：1）与网络中的LSR数量大致相同，2）与网络中的IGP路由数量大致相同。在收到的8份答复中，6份属于第一类，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的机制。
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路由器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标签的不同默认利用率。一些供应商将LDP用于VPN和IPv4流量转发，而其他供应商仅允许通过LDP解析VPN流量。挑战是在混合供应商环境中限制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:
报告的运营问题分为三类：
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之间所需的同步被列为主要协议问题。报告了两个问题：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., and B. Thomas, "LDP Specification", RFC 3036, January 2001.translate error, please retry
[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 Kista，瑞典电子邮件：Loa。andersson@acreo.se loa@pi.se
Ina Minei Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 EMail: ina@juniper.net
Ina Minei Juniper Networks 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.马萨诸塞州Boxborough大道1414号，邮编01719电子邮件：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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.