doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc3468.txt b/doc/rfc/rfc3468.txt
new file mode 100644
index 0000000..02f95ca
--- /dev/null
+++ b/doc/rfc/rfc3468.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                       L. Andersson
+Request for Comments: 3468                                    Consultant
+Category: Informational                                       G. Swallow
+                                                           Cisco Systems
+                                                           February 2003
+
+
+         The Multiprotocol Label Switching (MPLS) Working Group
+                 decision on MPLS signaling protocols
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document documents the consensus reached by the Multiprotocol
+   Label Switching (MPLS) Working Group within the IETF to focus its
+   efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions to
+   RSVP for Label-Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS
+   signalling protocol for traffic engineering applications and to
+   undertake no new efforts relating to "Constraint-Based LSP Setup
+   using Label Distribution Protocol (LDP)" (RFC 3212).  The
+   recommendations of section 6 have been accepted by the IESG.
+
+Conventions used in this document
+
+    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson & Swallow          Informational                      [Page 1]
+
+RFC 3468          Decision on MPLS Signaling Protocols     February 2003
+
+
+Table of Contents
+
+   1.  Introduction ................................................. 2
+        1.1  Objectives of document ................................. 2
+        1.2  Nomenclature ........................................... 2
+   2.  Background ................................................... 3
+   3.  CCAMP implementation study ................................... 4
+   4.  MPLS Working Group discussion ................................ 4
+        4.1  Phase 1 ................................................ 4
+        4.2  IETF process ........................................... 5
+        4.3  Relationship to other standards organizations .......... 5
+        4.4  Phase 2 ................................................ 5
+   5.  MPLS Working Group consensus ................................. 7
+   6.  Recommendation to the IESG ................................... 8
+   7.  Security Considerations ...................................... 8
+   8.  IANA Considerations .......................................... 8
+   9.  References ................................................... 8
+        9.1  Normative .............................................. 8
+        9.2  Informative ............................................ 9
+   10. Authors' Addresses ...........................................10
+   11. Full Copyright Statement .....................................11
+
+1. Introduction
+
+1.1  Objectives of document
+
+   This document documents the MPLS Working group consensus to continue
+   to develop RFC 3209 [RFC3209] as the signalling protocol for MPLS
+   signaling for Traffic Engineering applications.
+
+   This document also documents the MPLS working group consensus to not
+   undertake any new work related to RFC 3212 [RFC3212], e.g., there are
+   no plans to progress RFC 3212 beyond proposed standard.  No other
+   actions are taken relative the document status of RFC 3212 [RFC3212]
+   or RFCs that specify extensions to RFC 3212.
+
+   Section 6 summarizes the consensus of the MPLS working group on this
+   issue.  This consensus has been accepted by the IESG.  All other
+   sections are documentation of the consensus process.
+
+1.2 Nomenclature
+
+   This document uses the term "CR-LDP related working group drafts" to
+   refer to a group of Internet Drafts that specify changes or
+   extensions to [RFC3212] and the term "CR-LDP related RFCs" to discuss
+   the group of RFCs that specify the protocol and the applicability of
+   [RFC3212].
+
+
+
+
+Andersson & Swallow          Informational                      [Page 2]
+
+RFC 3468          Decision on MPLS Signaling Protocols     February 2003
+
+
+      The CR-LDP related working group drafts are:
+         "Multi Protocol Label Switching Label Distribution Protocol
+          Query Message Description" [QUERY]
+         "Improving Topology Data Base Accuracy with Label Switched
+          Path Feedback in Constraint Based Label Distribution
+          Protocol [FEED]
+         "Signalling Unnumbered Links in CR-LDP" [UNNUM]
+         "Fault Tolerance for the Label Distribution Protocol
+          (LDP)" [FT]
+         "Generalized MPLS Signaling - CR-LDP Extensions" [RFC3472]
+         "Generalized Multi-Protocol Label Switching Extensions for
+          SONET and SDH Control" [SONET]
+         "Generalized MPLS Signalling Extensions for G.709 Optical
+          Transport Networks Control" [G709]
+         "Generalized Multiprotocol Label Switching Extensions to
+          Control Non-Standard SONET and SDH Features" [SDH]
+
+   CR-LDP related RFCs
+
+            The CR-LDP related RFCs are:
+              RFC 3212, "Constraint-Based LSP Setup using LDP"
+              RFC 3213, "Applicability Statement for CR-LDP"
+              RFC 3214, "LSP Modification Using CR-LDP"
+
+   No further updates of the CR-LDP related RFCs, beyond their current
+   statuses are planned within the MPLS Working Group.
+
+2. Background
+
+   Very early (1997) in the MPLS standardization it was clear that a
+   protocol would be needed that would enable providers to setup LSPs
+   that took other information (e.g., various QoS parameters) into
+   account.
+
+   Development of this type of signalling protocol took two different
+   tracks:
+
+   -  extensions to RSVP for setting up MPLS tunnels [RFC3209]
+
+   -  extensions to LDP for setting constraint based LSPs [RFC3212]
+
+   The motivation for the choice of protocol in both cases was
+   straightforward.  Extending RSVP-TE to do in an MPLS environment what
+   it already was doing (handling QoS information and reserving
+   resources) in an IP environment is comprehensible; you only have to
+   add the label distribution capability.  Extending a native MPLS
+
+
+
+
+
+Andersson & Swallow          Informational                      [Page 3]
+
+RFC 3468          Decision on MPLS Signaling Protocols     February 2003
+
+
+   protocol like LDP, which was designed to do label distribution, to
+   handle some extra TLVs with QoS information is also not
+   revolutionary.
+
+   The MPLS group never reached a consensus on which way to go.  Both
+   protocols were progressed to proposed standard.
+
+3.  CCAMP implementation study
+
+   An implementation survey of GMPLS implementations was published in
+   June 2002 [GMPLS].  The survey includes responses from 22 different
+   implementers.  Twenty-one of 22 implementations include the GMPLS
+   signalling based on [RFC3209], while only 3 include signalling based
+   on [RFC3212].
+
+4.  MPLS Working Group discussion
+
+4.1 Phase 1
+
+   The GMPLS implementation report prompted questions asking if it was
+   reasonable to have two different protocols for the same thing.  The
+   discussion was brought to the MPLS Working Group at the meeting in
+   Yokohama in July 2002.  After discussion at the meeting it was
+   decided to "bring this to the list" and also invite comments from the
+   other Sub-IP Area Working Groups.
+
+   The following question sent to the mailing lists:
+
+   "As there are issues with having two similar standards (potentially
+   diverging), and it generates duplicate work in several IETF working
+   groups, the question was asked whether we should make CR-LDP
+   informational (which still make it available and possible to work
+   with) and progress only RSVP-TE on the standards track."
+
+   The response to this question was largely positive, but some problems
+   were immediately pointed out:
+
+   -  there are non-IETF standards which reference RFC 3212.  Taking
+      CR-LDP off the standards track would cause un-necessary problems
+      for those organizations and should be done only after co-
+      ordinating with those organizations
+
+   -  there is, e.g., in RFC 2026 [RFC2026], no documented process
+      according to which a document on the standards track may be move
+      to a status that is non-standards track
+
+
+
+
+
+
+Andersson & Swallow          Informational                      [Page 4]
+
+RFC 3468          Decision on MPLS Signaling Protocols     February 2003
+
+
+   Each of these arguments is by themselves strong and would have led to
+   some reformulation of the proposal to move CR-LDP to informational.
+   Moreover, in combination it was clear that the original proposal was
+   not viable.
+
+   On the other hand the support for doing additional development of
+   CR-LDP as an IETF standards track alternative to RSVP-TE was
+   extremely small.
+
+4.2 IETF process
+
+   The current IETF process for managing changes in RFC status does not
+   include any information on how to move an existing standard track RFC
+   to a non-standard track status, nor does it include a prohibition of
+   such an action.  It has been shown that such actions have been
+   previously taken e.g., RFCs 2673 and 2874 were moved from Proposed
+   Standard to Experimental.  Though the cases are not exactly parallel
+   to the MPLS signalling case it shows that the IETF and IESG are
+   prepared to take such decisions given that the arguments are
+   sufficiently strong.
+
+4.3  Relationship to other standards organizations
+
+   The relationship with other standard organizations is an important
+   part of IETF work.  We are dependent on their work and they make use
+   of our technology; each organization has their own area of expertise.
+   It is therefore necessary that both sides handle their standards
+   documentation in such a way that no unnecessary updates or revisions
+   are introduced simply by sloppy handling of documents.
+
+   Consequently we need to keep CR-LDP referenceable, i.e., on the
+   standards track, for the foreseeable future.  The implication of this
+   is not that we need to progress it further, or need to undertake
+   further work in the area.  One implication however is that standards
+   organizations which reference the document, need to be notified of
+   our decision so that they (at their own pace) can change their
+   references to more appropriate documents.  It is also expected that
+   they will notify us when they no longer have a need to normative
+   reference to CR-LDP.
+
+4.4 Phase 2
+
+   Based on the feed back from this first discussion the question to the
+   working group were reformulated as:
+
+   "Should the MPLS WG focus its efforts on a signalling protocol for
+   traffic engineering applications on RSVP-TE, and hence the WG effort
+   with CR-LDP be discontinued?  This would not involve any change in
+
+
+
+Andersson & Swallow          Informational                      [Page 5]
+
+RFC 3468          Decision on MPLS Signaling Protocols     February 2003
+
+
+   document status for CR-LDP, nor would it hinder continued individual
+   contributions in the CR-LDP space.  It would involve a change in the
+   MPLS WG charter to reflect this."
+
+   It was pointed out that "nor would it hinder continued individual
+   contributions" is too weak.  We actually discourage, while it is not
+   prohibited, continued work in the CR-LDP area.  That is the whole
+   point with taking this decision.
+
+   It was also pointed out that while it is quite acceptable to not
+   accept further working group documents, it would also be appropriate
+   to take the existing CR-LDP related working group Internet Drafts
+   through the process to proposed standard or informational as
+   intended.  This is applicable to the following documents, since much
+   of the work has already been completed on them:
+
+      - in MPLS WG
+       -- Multi Protocol Label Switching Label Distribution Protocol
+          Query Message Description
+       -- Improving Topology Data Base Accuracy with Label Switched Path
+       -- Feedback in Constraint Based Label Distribution Protocol
+       -- Signalling Unnumbered Links in CR-LDP
+       -- Fault Tolerance for the Label Distribution Protocol (LDP)
+      - in CCAMP WG
+       -- Generalized MPLS Signaling - CR-LDP Extensions
+       -- Generalized Multi-Protocol Label Switching Extensions for
+          SONET and SDH Control
+       -- Generalized MPLS Signalling Extensions for G.709 Optical
+          Transport Networks Control
+       -- Generalized Multiprotocol Label Switching Extensions to
+          Control Non-Standard SONET and SDH Features
+
+   Some of the documents listed above are not in themselves extensions
+   to CR-LDP, but in one way or another are deemed to be "equally
+   applicable to CR-LDP".  For those documents it will be fully
+   appropriate to progress them beyond proposed standard in the future
+   if they meet the requirements.
+
+   RFCs that are extensions to CR-LDP, e.g., RFCs 3213 and 3214, will
+   remain proposed standard documents.
+
+   After this compromise was proposed a good consensus quickly formed
+   supporting the proposal.  Close to 90% of the people participating
+   discussion said that they support or at least accept this outcome of
+   the working group discussion.
+
+
+
+
+
+
+Andersson & Swallow          Informational                      [Page 6]
+
+RFC 3468          Decision on MPLS Signaling Protocols     February 2003
+
+
+5.  MPLS Working Group consensus
+
+   In a message to the working group (date) the working groups chairs
+   stated that consensus had been reached on:
+
+   -  that the MPLS WG needs to focus its efforts on RSVP-TE (RFC 3209)
+      as protocol for traffic engineering signalling.
+
+   -  that the Working Group will undertake no new work related to
+      CR-LDP.
+
+   -  that the WG charter should be updated to reflect this.
+
+   -  that the WG will recommend that CR-LDP (RFC 3212) remain a
+      proposed standard.
+
+   -  that the WG will recommend that RFCs 3213 and 3214, which are
+      closely related to CR-LDP, remain proposed standard.
+
+   -  that existing Working Group drafts related to or updating/changing
+      CR-LDP will be progressed through the standards process to
+      proposed standard or informational RFCs as appropriate.
+
+   - that "the existing cr-ldp working group documents" are:
+      -- Multi Protocol Label Switching Label Distribution Protocol
+         Query Message Description
+      -- Improving Topology Data Base Accuracy with Label Switched Path
+         Feedback in Constraint Based Label Distribution Protocol
+         Signalling Unnumbered Links in CR-LDP
+      -- Fault Tolerance for the Label Distribution Protocol (LDP)
+      -- Generalized MPLS Signaling - CR-LDP Extensions
+      -- Generalized Multi-Protocol Label Switching Extensions for SONET
+         and SDH Control
+      -- Generalized MPLS Signalling Extensions for G.709 Optical
+         Transport Networks Control
+      -- Generalized Multiprotocol Label Switching Extensions to Control
+         Non-Standard SONET and SDH Features
+
+   -  that the MPLS working group will take on no new Working Group
+      documents related to CR-LDP.
+
+   -  that the MPLS working group will entertain no efforts to promote
+      CR-LDP beyond proposed standard.
+
+   -  that individual contributions related to CR-LDP area are not
+      prohibited, but discouraged.
+
+
+
+
+
+Andersson & Swallow          Informational                      [Page 7]
+
+RFC 3468          Decision on MPLS Signaling Protocols     February 2003
+
+
+   -  that a message will be sent to the relevant standards
+      organizations notifying them of this change of focus on MPLS
+      signalling protocols.
+
+6.  Recommendation to the IESG
+
+   Based on the consensus in the MPLS working group we recommend the
+   IESG to:
+
+      -  confirm the MPLS Working Group consensus to undertake no new
+         work on CR-LDP and focus on RSVP-TE as signalling protocol for
+         traffic engineering applications for MPLS, as described in this
+         document
+
+      -  adopt as an IETF policy to refrain from entertaining work that
+         intends to progress RFC 3212 or related RFCs beyond proposed
+         standard
+
+      -  adopt as an IETF policy to refrain from entertaining new
+         working group documents that are extensions to RFC 3212
+
+      -  review the IETF process with respect to management of documents
+         that needs to be moved from standards track to any other status
+
+      -  publish this document as Informational RFC
+
+7. Security Considerations
+
+   This document only discusses a refocusing of the MPLS Working Group
+   work and consequently brings no new security considerations.
+
+8. IANA Considerations
+
+   This document brings no IANA considerations.
+
+9. References
+
+9.1 Normative
+
+   [RFC2026] Bradner, S. "The Internet Standards Process -- Revision 3",
+             BCP 9, RFC 2026,  October 1996.
+
+   [RFC2119] Bradner, S. "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+Andersson & Swallow          Informational                      [Page 8]
+
+RFC 3468          Decision on MPLS Signaling Protocols     February 2003
+
+
+   [RFC3212] Jamoussi, B., Ed., Andersson, R., Callon, R., Dantu, R.,
+             Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A.,
+             Girish, M., Gray, E., Heinanen, J., Kitly, T. and A. Malis,
+             "Constraint-Based LSP Setup using LDP", RFC 3212, January
+             2002.
+
+   [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
+             and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+             Tunnels", RFC 3209, December 2001.
+
+9.2 Informative
+
+   [RFC3213] Jamoussi, B., Ash, J., Girish, M., Gray, B. and G. Wright,
+             "Applicability Statement for CR-LDP", RFC 3213, January
+             2002.
+
+   [RFC3214] Jamoussi, B., Ash, J., Lee, Y., Ashwood-Smith, P., Fedyk,
+             D., Shalecki, D. and L. Li, "LSP Modification Using CR-LDP"
+             RFC 3214, January 2002.
+
+   [RFC3472] Ashwood-Smith, P. and L. Berger, Eds., "Generalized Multi-
+             Protocol Label Switching (GMPLS) Signaling Constraint-based
+             Routed Label Distribution Protocol (CR-LDP) Extensions",
+             RFC 3472, January 2003.
+
+   [GMPLS]   Rekhther, Y. and L. Berger, "Generalized MPLS
+             Signaling - Implementation Survey",
+             http://www.ietf.org/IESG/Implementations/
+             MPLS-SIGNALING-Implementation.txt, June 2002.
+
+   [QUERY]   Ashwood-Smith P. and A. Paraschiv, "Multi Protocol Label
+             Switching Label Distribution Protocol Query Message
+             Description", Work in Progress.
+
+   [FEED]    Jamoussi, B., et al., "Improving Topology Data Base
+             Accuracy with LSP Feedback in CR-LDP", Work in Progress.
+
+   [RFC3480] Kompella, K., Rekhter, Y. and A. Kullberg, "Signalling
+             Unnumbered Links in CR-LDP (Constraint-Routing Label
+             Distribution Protocol)", RFC 3480, February 2003.
+
+   [RFC3479] Farrel, A., Ed., "Fault Tolerance for the Label
+             Distribution Protocol (LDP)", RFC 3479, February 2003.
+
+   [SONET]   Mannie, E. and D. Papadimitriou, "Generalized Multiprotocol
+             Label Switching Extensions for SONET and SDH Control", Work
+             in Progress.
+
+
+
+
+Andersson & Swallow          Informational                      [Page 9]
+
+RFC 3468          Decision on MPLS Signaling Protocols     February 2003
+
+
+   [G709]    Papadimitriou, D., Ed., "Generalized MPLS Signalling
+             Extensions for G.709 Optical Transport Networks Control",
+             Work in Progress.
+
+   [SDH]     "Generalized Multiprotocol Label Switching Extensions to
+             Control Non-Standard SONET and SDH Features"  Work in
+             Progress.
+
+10. Authors' Addresses
+
+   Loa Andersson
+
+   EMail: loa@pi.se
+
+
+   George Swallow
+   Cisco Systems, Inc.
+   250 Apollo Drive
+   Chelmsford, MA 01824
+
+   EMail: swallow@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson & Swallow          Informational                     [Page 10]
+
+RFC 3468          Decision on MPLS Signaling Protocols     February 2003
+
+
+11. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andersson & Swallow          Informational                     [Page 11]
+