Skip to main content

Number of Generic Associated Channel Labels in the MPLS Label Stack
draft-many-mpls-multiple-gal-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Greg Mirsky , Huub van Helvoort , Stewart Bryant , Sasha Vainshtein , Italo Busi
Last updated 2021-04-28
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-many-mpls-multiple-gal-00
MPLS Working Group                                             G. Mirsky
Internet-Draft                                                 ZTE Corp.
Updates: 5586 (if approved)                              H. van Helvoort
Intended status: Standards Track                  Individual Contributor
Expires: 30 October 2021                                       S. Bryant
                                             Futurewei Technologies Inc.
                                                           A. Vainshtein
                                              Ribbon Communications Inc.
                                                                 I. Busi
                                                                  Huawei
                                                           28 April 2021

  Number of Generic Associated Channel Labels in the MPLS Label Stack
                    draft-many-mpls-multiple-gal-00

Abstract

   This document describes the requirements for using multiple Generic
   Associated Channel Labels (GALs) in an MPLS label stack.  As a
   result, the document updates RFC 5586 by removing the restriction
   imposed on the usage of GAL that limits the number of GAL in the MPLS
   label stack to one.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 30 October 2021.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Mirsky, et al.           Expires 30 October 2021                [Page 1]
Internet-Draft                Multiple GAL                    April 2021

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  Number of GAL in the MPLS Label Stack . . . . . . . . . . . .   3
   4.  Processing GAL when not at the Bottom of the Label Stack  . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   4
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   4
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   [RFC5085] defined the associated channel mechanism and the Associated
   Channel Header (ACH) for exchange of control, management, and
   Operations, Administration, and Maintenance (OAM) messages in
   Pseudowires (PWs).  [RFC5586] generalized that associated channel
   mechanism and the ACH for use in Sections, Label Switched Paths
   (LSPs), and PWs as the Generic Associated Channel (G-ACh) and
   introduced the generalized label-based exception mechanism using the
   Generic Associated Channel Label (GAL).

   [RFC5586] restricted the number of GALs present in the MPLS label
   stack to not more than one appearance.  This document updates
   [RFC5586] by removing that restriction for non-MPLS-TP networks.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Mirsky, et al.           Expires 30 October 2021                [Page 2]
Internet-Draft                Multiple GAL                    April 2021

3.  Number of GAL in the MPLS Label Stack

   [RFC5586] has limited the number of GALs in an MPLS label stack:

      Furthermore, when present, the GAL MUST NOT appear more than once
      in the label stack.

   In some MPLS networks, e.g., when realizing Service Function Chaining
   with MPLS-based forwarding plane [RFC8595], putting more than a
   single GAL in the MPLS label stack can simplify the processing of OAM
   packets and, as a result, improve the performance.  An extension of
   the MPLS Echo Request and Reply protocol [RFC8029] in such an
   environment is discussed in [I-D.lm-mpls-sfc-path-verification].
   Because it is expected that a general Service Function does not
   support processing of MPLS echo request messages, a GAL being used
   within a basic unit of MPLS label stack to indicate that the payload
   is ACH-encapsulated OAM message.  And in the label-stacking case,
   multiple basic units on the MPLS label stack, and, consequently, GALs
   could be placed in an MPLS label stack.  Thus, this document removes
   the limit on the number of GALs present in an MPLS label stack by
   changing the statement in [RFC5586] as follows:

      Furthermore, in non-MPLS-TP networks, when present, the GAL MAY
      appear more than once in the label stack.

   [RFC5586] requires that when GAL is at the bottom of the label stack,
   it is followed by an ACH:

      Where the GAL is at the bottom of the label stack (i.e., S bit set
      to 1), then it MUST always be followed by an ACH.

   This document updates [RFC5586] by extending that requirement for
   environments when GAL is not at the bottom of the label stack as
   follows:

      Where GAL is present in the label stack, the label element at the
      bottom of the label stack (i.e., S bit set to 1) MUST always be
      followed by an ACH.

4.  Processing GAL when not at the Bottom of the Label Stack

   [Ed.note: Describe GAL processing by transit and egress nodes.
   Illustrate the transformation of the MPLS label stack as a packet
   transits through the domain.]

Mirsky, et al.           Expires 30 October 2021                [Page 3]
Internet-Draft                Multiple GAL                    April 2021

5.  IANA Considerations

   This document has no requests for IANA, and this section can be
   removed before the publication.

6.  Security Considerations

   There are no further security considerations than those in [RFC5586].

7.  Acknowledgments

   TBA

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5085]  Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
              Circuit Connectivity Verification (VCCV): A Control
              Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
              December 2007, <https://www.rfc-editor.org/info/rfc5085>.

   [RFC5586]  Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
              "MPLS Generic Associated Channel", RFC 5586,
              DOI 10.17487/RFC5586, June 2009,
              <https://www.rfc-editor.org/info/rfc5586>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8595]  Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based
              Forwarding Plane for Service Function Chaining", RFC 8595,
              DOI 10.17487/RFC8595, June 2019,
              <https://www.rfc-editor.org/info/rfc8595>.

8.2.  Informative References

Mirsky, et al.           Expires 30 October 2021                [Page 4]
Internet-Draft                Multiple GAL                    April 2021

   [I-D.lm-mpls-sfc-path-verification]
              Yao, L. and G. Mirsky, "MPLS-based Service Function
              Path(SFP) Consistency Verification", Work in Progress,
              Internet-Draft, draft-lm-mpls-sfc-path-verification-02, 21
              February 2021, <https://tools.ietf.org/html/draft-lm-mpls-
              sfc-path-verification-02>.

   [RFC8029]  Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
              Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
              Switched (MPLS) Data-Plane Failures", RFC 8029,
              DOI 10.17487/RFC8029, March 2017,
              <https://www.rfc-editor.org/info/rfc8029>.

Authors' Addresses

   Greg Mirsky
   ZTE Corp.

   Email: gregory.mirsky@ztetx.com, gregimirsky@gmail.com

   Huub van Helvoort
   Individual Contributor

   Email: huubatwork@gmail.com

   Stewart Bryant
   Futurewei Technologies Inc.

   Email: sb@stewartbryant.com

   Alexander Vainshtein
   Ribbon Communications Inc.

   Email: Alexander.Vainshtein@rbbn.com

   Italo Busi
   Huawei

   Email: italo.busi@huawei.com

Mirsky, et al.           Expires 30 October 2021                [Page 5]