RFC 3468

The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols

📅 published February 2003, from ietf

RFC 3468 🎀 Network Working Group

The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols 💅

Authors: L. Andersson (Consultant) and G. Swallow (Cisco Systems) 🫶 Category: Informational 🌸 Date: February 2003 🍓 Obsoletes/Updates: The header doesn't list anything this document obsoletes or updates 🙈

Status of this Memo ✨

okay so this memo is here to give info to the Internet community. it does NOT specify an Internet standard of any kind 🫣 and distribution of it is unlimited 🦋

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract 🌈

this doc records the consensus the Multiprotocol Label Switching (MPLS) Working Group reached inside the IETF. the group decided to focus 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. they also agreed to undertake no new efforts on "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].

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

okay so this document documents the MPLS Working group consensus to keep developing RFC 3209 [RFC3209] as the signalling protocol for MPLS signaling for Traffic Engineering applications 🔥

this doc also records 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 to the document status of RFC 3212 [RFC3212] or RFCs that specify extensions to RFC 3212.

section 6 is the summary of the MPLS working group's consensus on this issue, and the IESG has accepted it. every other section is documentation of how the consensus process went 📝

1.2. Nomenclature

this doc uses the term "CR-LDP related working group drafts" to refer to a group of Internet Drafts that specify changes or extensions to [RFC3212]. it uses "CR-LDP related RFCs" to talk about the group of RFCs that specify the protocol and the applicability of [RFC3212] 🦋

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]

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 on, back in 1997, it was clear that MPLS standardization would need a protocol that let providers set up LSPs that took other information (e.g., various QoS parameters) into account ✨

development of this type of signalling protocol went down two different tracks:

  • extensions to RSVP for setting up MPLS tunnels [RFC3209]
  • extensions to LDP for setting constraint based LSPs [RFC3212]

the reasoning behind the protocol choice in both cases was pretty straightforward 🧠 extending RSVP-TE to do in an MPLS environment what it already did (handling QoS information and reserving resources) in an IP environment makes total sense. you only have to add the label distribution capability. extending a native MPLS 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 got people asking whether 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 was 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 was largely positive, but a few problems got pointed out right away 👀

  • 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 moved to a status that is non-standards track

each of these arguments is strong by itself and would have led to some reformulation of the proposal to move CR-LDP to informational. put together, it was clear the original proposal was not viable 🚫

on the other hand, 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 doesn't say how to move an existing standards track RFC to a non-standards track status. it doesn't ban that either 🤷‍♀️ such actions have been taken before, e.g., RFCs 2673 and 2874 were moved from Proposed Standard to Experimental. the cases aren't exactly parallel to the MPLS signalling case, but it shows that the IETF and IESG are prepared to make these decisions when the arguments are strong enough 💪

4.3. Relationship to other standards organizations

the relationship with other standards organizations is a huge part of IETF work 🌍 we depend on their work, they use our technology, and each organization has its own area of expertise. both sides have to handle their standards documentation carefully so that no unnecessary updates or revisions get introduced just because of sloppy document handling 🫶

so we need to keep CR-LDP referenceable, i.e., on the standards track, for the foreseeable future. that doesn't mean we need to progress it further or do more work in the area ✨ what it does mean is that standards organizations which reference the document need to be notified of our decision, so they can change their references to more appropriate documents at their own pace. it's also expected that they'll let us know when they no longer need a normative reference to CR-LDP 💖

4.4 Phase 2 💅

okay so after that first chat, the WG went back with a sharper question, bestie 🧠✨:

"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 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."

Someone then pointed out that "nor would it hinder continued individual contributions" is way too weak 🙈 Like, we actually discourage continued work in the CR-LDP area. It's not prohibited, but that's the whole point of making this decision. We're not being subtle about it 💀

Someone also noted that while it's totally fine to stop accepting new working group documents, it would also make sense to push the existing CR-LDP related WG Internet-Drafts through to proposed standard or informational, as originally intended. These are the ones that get the green light, since most of the work on them is already done 🌸:

  • 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 these aren't extensions to CR-LDP in themselves, but they're considered "equally applicable to CR-LDP" 🦋. For those, it will be completely appropriate to move them beyond proposed standard later on, if they meet the requirements.

RFCs that are extensions to CR-LDP, like RFCs 3213 and 3214, will stay as proposed standard documents ⭐.

After this compromise was put forward, a strong consensus formed really fast. Close to 90% of the people participating in the discussion said they support it, or at least accept the outcome of the working group discussion 🎀🫶

5. MPLS Working Group consensus 👑

In a message to the working group (date), the working groups chairs said that consensus had been reached on the following:

  • 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.
  • 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 MPLS working group consensus, we're recommending that the IESG:

  • 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
Heads up: these are recommendations to the IESG, not new rules for implementers. The IESG gets to make the final call 💅

7. Security Considerations 🔐

This document only discusses a refocusing of the MPLS Working Group work, so it consequently brings no new security considerations. Zero new security drama, periodt 💖

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.

[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.

[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

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. 🦋✨

📦 where this page comes from