doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc5037.txt b/doc/rfc/rfc5037.txt
new file mode 100644
index 0000000..449499e
--- /dev/null
+++ b/doc/rfc/rfc5037.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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.
+
+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
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.            Informational                      [Page 1]
+
+RFC 5037            Experience with the LDP Protocol        October 2007
+
+
+1.  Introduction
+
+   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 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].
+
+2.  Operational Experience
+
+   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.
+
+   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.
+
+2.1.  Environment and Duration
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Andersson, et al.            Informational                      [Page 2]
+
+RFC 5037            Experience with the LDP Protocol        October 2007
+
+
+2.2.  Applications and Motivation
+
+   Nine of the 11 responses list Layer 3 Virtual Private Networks
+   (L3VPNs) as the application driving the LDP deployment in the
+   network.
+
+   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.
+
+   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:
+
+      o  The deployment does not require traffic engineering - 6
+
+      o  Inter-operability concerns if a different protocol is used - 5
+
+      o  Equipment vendor only supports LDP - 5
+
+      o  Ease of configuration - 4
+
+      o  Ease of management - 3
+
+      o  Scalability concerns with other protocols - 3
+
+      o  Required for a service offering of the service provider - 1
+
+2.3.  Protocol Features
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+Andersson, et al.            Informational                      [Page 3]
+
+RFC 5037            Experience with the LDP Protocol        October 2007
+
+
+2.4.  Security Concerns
+
+   A security concern was raised by one of the operators with respect to
+   the lack of a mechanism for securing LDP Hellos.
+
+2.5.  Implementations and Inter-Operability
+
+   Eight of the 11 responses state that more than one implementation
+   (and as many as four different ones) are deployed in the same
+   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.
+
+      o  Different flexibility in setting transport and LDP router-id
+         addresses.
+
+      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  Understanding the differences in the implementations.
+
+2.6.  Operational Experience
+
+   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.
+
+      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.
+
+
+
+Andersson, et al.            Informational                      [Page 4]
+
+RFC 5037            Experience with the LDP Protocol        October 2007
+
+
+      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, 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].
+
+         -  Silent failures.  Failure not being propagated to the head
+            end of the LSP when setting up LSPs using independent
+            control.
+
+3.  Security Considerations
+
+   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.
+
+4.  Acknowledgments
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.            Informational                      [Page 5]
+
+RFC 5037            Experience with the LDP Protocol        October 2007
+
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC1264]  Hinden, R., "Internet Engineering Task Force Internet
+              Routing Protocol Standardization Criteria", RFC 1264,
+              October 1991.
+
+   [RFC3036]  Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
+              B. Thomas, "LDP Specification", RFC 3036, January 2001.
+
+   [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.
+
+5.2.  Informative References
+
+   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
+              Specification", RFC 5036, October 2007.
+
+   [LDP-SYNC] Jork, M., Atlas, A., and L. Fang, "LDP IGP
+              Synchronization", Work in Progress, July 2007.
+
+Editors' Addresses
+
+   Loa Andersson
+   Acreo AB
+   Isafjordsgatan 22
+   Kista, Sweden
+   EMail: loa.andersson@acreo.se
+          loa@pi.se
+
+   Ina Minei
+   Juniper Networks
+   1194 N.Mathilda Ave
+   Sunnyvale, CA 94089
+   EMail: ina@juniper.net
+
+   Bob Thomas
+   Cisco Systems, Inc.
+   1414 Massachusetts Ave
+   Boxborough, MA 01719
+   EMail: rhthomas@cisco.com
+
+
+
+
+
+
+
+Andersson, et al.            Informational                      [Page 6]
+
+RFC 5037            Experience with the LDP Protocol        October 2007
+
+
+Full Copyright Statement
+
+   Copyright (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.
+
+   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.
+
+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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson, et al.            Informational                      [Page 7]
+