draft-ietf-mpls-ldp-experience-00.txt   rfc5037.txt 
Network Working Group Loa Andersson Network Working Group L. Andersson, Ed.
Internet Draft Ina Minei Request for Comments: 5037 Acreo AB
Expiration Date: February 2006 Bob Thomas Category: Informational I. Minei, Ed.
Category: Informational Editors Juniper Networks
B. Thomas, Ed.
August 2005 Cisco Systems, Inc.
October 2007
Experience with the LDP protocol
draft-ietf-mpls-ldp-experience-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Experience with the Label Distribution Protocol (LDP)
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Status of This Memo
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This memo provides information for the Internet community. It does
http://www.ietf.org/shadow.html. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract Abstract
The purpose of this memo is to document how some of the requirements The purpose of this memo is to document how some of the requirements
specified in RFC 1264 for advancing protocols developed by working specified in RFC 1264 for advancing protocols developed by working
groups within the IETF Routing Area to Draft Standard have been groups within the IETF Routing Area to Draft Standard have been
satisfied by LDP (Label Distribution Protocol). Specifically, this satisfied by LDP (Label Distribution Protocol). Specifically, this
report documents operational experience with LDP, requirement 5 of report documents operational experience with LDP, requirement 5 of
section 5.0 in RFC 1264. section 5.0 in RFC 1264.
Table of Contents Table of Contents
1 Introduction .......................................... 3 1. Introduction ....................................................2
2 Operational experience ................................ 3 2. Operational Experience ..........................................2
2.1 Environment and duration .............................. 3 2.1. Environment and Duration ...................................2
2.2 Applications and motivation ........................... 4 2.2. Applications and Motivation ................................3
2.3 Protocol features ..................................... 4 2.3. Protocol Features ..........................................3
2.4 Security concerns ..................................... 4 2.4. Security Concerns ..........................................4
2.5 Implementations and inter-operability ................. 5 2.5. Implementations and Inter-Operability ......................4
2.6 Operational experience ................................ 5 2.6. Operational Experience .....................................4
3 Intellectual Property Statement ....................... 6 3. Security Considerations .........................................5
4 Acknowledgments ....................................... 6 4. Acknowledgments .................................................5
5 References ............................................ 7 5. References ......................................................6
5.1 Normative References .................................. 7 5.1. Normative References .......................................6
5.2 Informative References ................................ 7 5.2. Informative References .....................................6
6 Editors' Addresses .................................... 7
Full Copyright Statement .............................. 8
1. Introduction 1. Introduction
The purpose of this memo is to document how some of the requirements The purpose of this memo is to document how some of the requirements
specified in RFC 1264 for advancing protocols developed by working specified in [RFC1264] for advancing protocols developed by working
groups within the IETF Routing Area to Draft Standard have been sat- groups within the IETF Routing Area to Draft Standard have been
isfied by LDP. Specifically, this report documents operational expe- satisfied by LDP. Specifically, this report documents operational
rience with LDP, requirement 5 of section 5.0 in RFC 1264. experience with LDP, requirement 5 of section 5.0 in RFC 1264.
LDP was originally published as RFC 3036 in January 2001. It was LDP was originally published as [RFC3036] in January 2001. It was
produced by the MPLS Working Group of the IETF and was jointly produced by the MPLS Working Group of the IETF and was jointly
authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre
and Bob Thomas. Fredette, and Bob Thomas. It has since been obsoleted by [RFC5036].
2. Operational experience 2. Operational Experience
This section discusses operational experience with the protocol. The This section discusses operational experience with the protocol. The
information is based on a survey sent to the MPLS Working Group in information is based on a survey sent to the MPLS Working Group in
October 2004. The questionnaire can be found in the MPLS Working October 2004. The questionnaire can be found in the MPLS Working
Group mail archives for October 2004. Group mail archives for October 2004.
11 responses were received, all but two requesting confidentiality. 11 responses were received, all but 2 requesting confidentiality.
The survey results are summarized to maintain confidentiality. The The survey results are summarized to maintain confidentiality. The
networks surveyed span different geographic locations: US, Europe and networks surveyed span different geographic locations: US, Europe,
Asia. Both academic and commercial networks responded to the survey. and Asia. Both academic and commercial networks responded to the
survey.
2.1. Environment and duration 2.1. Environment and Duration
The size of the deployments ranges from less than 20 Label Switching The size of the deployments ranges from less than 20 Label Switching
Routers (LSRs) to over 1000 LSRs. Eight out of the 11 deployments 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 use LDP in the edge and the core, two on the edge only, and one in
core only. the core only.
Sessions exist to peers discovered via both the basic and the Sessions exist to peers discovered via both the basic and the
extended discovery mechanisms. In half the cases, more than one adja- extended discovery mechanisms. In half the cases, more than one
cency (and as many as four adjacencies) are maintained per session. adjacency (and as many as four adjacencies) are maintained per
The average number of LDP sessions on an LSR ranges from under 10 to session. The average number of LDP sessions on an LSR ranges from
just over 80. The responses are spread as follows: under 10: 4 under 10 to just over 80. The responses are spread out as follows:
responses, 20-50: 4 responses, over 80: 1 response. under 10: 4 responses, 20-50: 4 responses, and over 80: 1 response.
In the surveyed networks, the time LDP has been deployed ranges from In the surveyed networks, the time LDP has been deployed ranges from
under one year to over 4 years. The responses are spread out as fol- under 1 year to over 4 years. The responses are spread out as
lows: under 1 year - 3 responses, 2 years - 2 responses, 3 years -3 follows: under 1 year: 3 responses, 2 years: 2 responses, 3 years: 3
responses and over 4 years - 3 responses. responses, and over 4 years: 3 responses.
2.2. Applications and motivation 2.2. Applications and Motivation
Nine out of the 11 responses list L3VPNs as the application driving Nine of the 11 responses list Layer 3 Virtual Private Networks
the LDP deployment in the network. (L3VPNs) as the application driving the LDP deployment in the
network.
The list of applications is as follows. L3VPNs: 9, pseudo-wires: 4 The list of applications is as follows: L3VPNs: 9, pseudowires: 4
current (and one planned deployment), L2VPNs: 4, forwarding based on current (and one planned deployment), L2VPNs: 4, forwarding based on
labels: 2, BGP-free core: 1 labels: 2, and BGP-free core: 1.
There are two major options for label distribution protocols, LDP and There are two major options for label distribution protocols, LDP and
RSVP-TE. One of the key differences between the two is that RSVP-TE Resource Reservation Protocol-Traffic Engineering (RSVP-TE). One of
has support for Traffic Engineering (TE), while LDP does not. The the key differences between the two is that RSVP-TE has support for
reasons cited for picking LDP as the label distribution protocol are: traffic engineering, while LDP does not. The reasons cited for
picking LDP as the label distribution protocol are:
o The deployment does not require traffic engineering - 6 o The deployment does not require traffic engineering - 6
o Inter-operability concerns if a different protocol is used - 5 o Inter-operability concerns if a different protocol is used - 5
o Equipment vendor only supports LDP - 5 o Equipment vendor only supports LDP - 5
o Ease of configuration - 4 o Ease of configuration - 4
o Ease of management - 3 o Ease of management - 3
o Scalability concerns with other protocols - 3 o Scalability concerns with other protocols - 3
o Required for a service offering of the service provider - 1 o Required for a service offering of the service provider - 1
2.3. Protocol features 2.3. Protocol Features
All deployments surveyed use the downstream unsolicited label distri- All deployments surveyed use the Downstream Unsolicited Label
bution mode. All but one deployment use liberal label retention (one Distribution mode. All but one deployment use Liberal Label
uses conservative). retention (one uses conservative).
LSP setup is established with both independent and ordered control. LSP setup is established with both independent and Ordered Control.
Five of the deployments use both control modes in the same network. Five of the deployments use both control modes in the same network.
The number of LDP FECs advertised and LDP routes installed falls in The number of LDP Forwarding Equivalence Classes (FECs) advertised
one of two categories: 1) roughly the same as the number of LSRs in and LDP routes installed falls in one of two categories: 1) roughly
the network and 2) roughly the same as the number of IGP routes in the same as the number of LSRs in the network and 2) roughly the same
the network. Of the 8 responses were received. 6 were in the first as the number of IGP routes in the network. Of the 8 responses that
category and 2 in the second. were received, 6 were in the first category and 2 in the second.
2.4. Security concerns 2.4. Security Concerns
A security concern was raised by one of the operators with respect A security concern was raised by one of the operators with respect to
to the lack of a mechanism for securing LDP Hellos. the lack of a mechanism for securing LDP Hellos.
2.5. Implementations and inter-operability 2.5. Implementations and Inter-Operability
Eight out of the 11 responses state that more than one implementation Eight of the 11 responses state that more than one implementation
(and as many as four different ones) are deployed in the same net- (and as many as four different ones) are deployed in the same
work. network.
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.
The consensus is that although implementations differ, no inter-oper-
ability issues exist. The challenges listed by providers running mul-
tiple implementations are:
o Different flexibility in picking which FECs to advertise labels
for.
o Different flexibility in setting transport and LDP router-id o Different flexibility in setting transport and LDP router-id
addresses. addresses.
o Different default utilization of LDP labels for traffic resolu-
tion. Some vendors use LDP for both VPN and IPv4 traffic forward- o Different default utilization of LDP labels for traffic
ing, while other vendors allow only VPN traffic to resolve via resolution. Some vendors use LDP for both VPN and IPv4 traffic
LDP. The challenge is to restrict the utilization of LDP labels forwarding, while other vendors allow only VPN traffic to
to VPN traffic in a mixed-vendor environment. resolve via LDP. The challenge is to restrict the utilization
of LDP labels to VPN traffic in a mixed-vendor environment.
o Understanding the differences in the implementations. o Understanding the differences in the implementations.
2.6. Operational experience 2.6. Operational Experience
In general, operators reported stable implementations and steady In general, operators reported stable implementations and steady
improvement in resiliency to failure and convergence times over the improvement in resiliency to failure and convergence times over the
years. Some operators reported that no issues were found with the years. Some operators reported that no issues were found with the
protocol since deploying. protocol since deploying.
The operational issues reported fall in three categories: The operational issues reported fall in three categories:
1. Configuration issues. Both the session and adjacency endpoints 1. Configuration issues. Both the session and adjacency endpoints
must be allowed by the firewall filters. Misconfiguration of must be allowed by the firewall filters. Misconfiguration of
the filters causes sessions to drop (if already established) or the filters causes sessions to drop (if already established) or
not to establish. not to establish.
2. Vendor bugs. These include traffic blackholing, unnecessary 2. Vendor bugs. These include traffic blackholing, unnecessary
label withdrawals and changes, session resets and problems label withdrawals and changes, session resets, and problems
migrating from older versions of the technology. Most reports migrating from older versions of the technology. Most reports
stated that the problems reported occurred in early versions of stated that the problems reported occurred in early versions of
the implementations. the implementations.
3. Protocol issues.
- 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. 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 traf-
fic for a link-up event (not a failure but a restoration). This
issue is described in more detail in [LDP-SYNC].
- Silent failures. Failure not being propagated to the head end of 3. Protocol issues.
the LSP when setting up LSPs using independent control.
3. Intellectual Property Statement - 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].
The IETF takes no position regarding the validity or scope of any - Silent failures. Failure not being propagated to the head
Intellectual Property Rights or other rights that might be claimed to end of the LSP when setting up LSPs using independent
pertain to the implementation or use of the technology described in control.
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.
Copies of IPR disclosures made to the IETF Secretariat and any assur- 3. Security Considerations
ances 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.
The IETF invites any interested party to bring to its attention any This document is a survey of experiences from deployment of LDP
copyrights, patents or patent applications, or other proprietary implementations; it does not specify any protocol behavior. Thus,
rights that may cover technology that may be required to implement security issues introduced by the document are not discussed.
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
4. Acknowledgments 4. Acknowledgments
The editors would like to thank the operators who participated in the The editors would like to thank the operators who participated in the
survey for their valuable input: Shane Amante, Niclas Comstedt, Bruno survey for their valuable input: Shane Amante, Niclas Comstedt, Bruno
Decraene, Mourad Kaddache, Kam Lee Yap, Lei Wang and Otto Kreiter. Decraene, Mourad Kaddache, Kam Lee Yap, Lei Wang, and Otto Kreiter.
Not all who participated are listed here, due to confidentiality Not all who participated are listed here, due to confidentiality
requests. Those listed have given their consent. requests. Those listed have given their consent.
Also, a big thank you to Scott Bradner who acted as an independent Also, a big thank you to Scott Bradner, who acted as an independent
third party ensuring anonymity of the responses. third party ensuring anonymity of the responses.
The editors would like to thank Rajiv Papneja, Halit Ustundag and Loa The editors would like to thank Rajiv Papneja, Halit Ustundag, and
Andersson for their input to the survey questionnaire. Loa Andersson for their input to the survey questionnaire.
5. References 5. References
5.1. Normative References 5.1. Normative References
[RFC1264] Hinden, R., "Internet Engineering Task Force Internet Rout- [RFC1264] Hinden, R., "Internet Engineering Task Force Internet
ing Protocol Standardization Criteria", RFC 1264, October 1991. Routing Protocol Standardization Criteria", RFC 1264,
October 1991.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, October 1996.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 3036, January 2001. B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3815] Cucchiara,J., Sjostrand, H. and Luciani, J., "Definitions [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions
of Managed Objects for the Multiprotocol Label Switching (MPLS), of Managed Objects for the Multiprotocol Label Switching
Label Distribution Protocol (LDP)", RFC 3815, June 2004. (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June
2004.
5.2. Informative References 5.2. Informative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
April 1992. Specification", RFC 5036, October 2007.
[LDP-SYNC] Jork, M., Atlas, A. and Fang, L., "LDP IGP Synchroniza- [LDP-SYNC] Jork, M., Atlas, A., and L. Fang, "LDP IGP
tion", draft-jork-ldp-igp-sync-00 Synchronization", Work in Progress, July 2007.
6. Editors' Addresses Editors' Addresses
Loa Andersson Loa Andersson
Acreo AB Acreo AB
Isafjordsgatan 22 Isafjordsgatan 22
Kista, Sweden Kista, Sweden
email: loa.andersson@acreo.se EMail: loa.andersson@acreo.se
loa@pi.se loa@pi.se
Ina Minei Ina Minei
Juniper Networks Juniper Networks
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
e-mail: ina@juniper.net EMail: ina@juniper.net
Bob Thomas Bob Thomas
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Ave 1414 Massachusetts Ave
Boxborough, MA 01719 Boxborough, MA 01719
email: rhthomas@cisco.com EMail: rhthomas@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The IETF Trust (2007).
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Additional copyright notices are not permitted in IETF Documents This document is subject to the rights, licenses and restrictions
except in the case where such document is the product of a joint contained in BCP 78, and except as set forth therein, the authors
development effort between the IETF and another standards development retain all their rights.
organization or the document is a republication of the work of
another standards organization. Such exceptions must be approved on
an individual basis by the IAB.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Intellectual Property
Funding for the RFC Editor function is currently provided by the The IETF takes no position regarding the validity or scope of any
Internet Society. 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.
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.
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.
 End of changes. 63 change blocks. 
170 lines changed or deleted 147 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/