path: root/doc/rfc/rfc3468.txt

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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L