summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3468.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3468.txt')
-rw-r--r--doc/rfc/rfc3468.txt619
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]
+