MPLS Working Group                                          L. Andersson
Internet-Draft                                  Bronze Dragon Consulting
Intended status: Standards Track                             J. Guichard
Expires: August 24, 2019                                         H. Song
                                                               S. Bryant
                                                     Huawei Technologies
                                                       February 20, 2019


           MPLS Label Operations in MPLS EH capable networks
           draft-andersson-mpls-eh-label-stack-operations-00

Abstract

   Extension Headers (EH) carry information on in-network services and
   functions in an MPLS network.  This document describes the operations
   on the MPLS label stack when an EH is found in the packet.

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 August 24, 2019.

Copyright Notice

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

   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




Andersson, et al.        Expires August 24, 2019                [Page 1]


Internet-Draft         EH Label Stack Opedrations          February 2019


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirement Language  . . . . . . . . . . . . . . . . . .   3
   2.  Operations on an MPLS Label Stack in an EH capable network  .   3
     2.1.  Physical Topology . . . . . . . . . . . . . . . . . . . .   3
     2.2.  A day in the life of a packet . . . . . . . . . . . . . .   5
       2.2.1.  Non-VPN Case  . . . . . . . . . . . . . . . . . . . .   6
         2.2.1.1.  Non-VPN with the EH in the packet . . . . . . . .   6
         2.2.1.2.  Non-VPN without an EH in the packet . . . . . . .   7
     2.3.  The VPN case  . . . . . . . . . . . . . . . . . . . . . .   8
       2.3.1.  VPN with EH in the packet . . . . . . . . . . . . . .   8
       2.3.2.  VPN without EH in the packet  . . . . . . . . . . . .   9
     2.4.  RSVP-TE Tunnel case . . . . . . . . . . . . . . . . . . .  10
       2.4.1.  RSVP Tunnel and EH present in the packet  . . . . . .  11
       2.4.2.  RSVP Tunnel and no EH present in the packet . . . . .  12
       2.4.3.  EH capable RSVP-TE tunnel . . . . . . . . . . . . . .  13
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   This document provides the operating procedures for EH-capable and
   non-EH-capable LSRs where MPLS Extension Headers (EH) are carried
   below the MPLS label stack.  Further we show that MPLS EHs can be
   gradually introduced into an existing MPLS network.  The capability
   to handle EHs is announced throughout the MPLS network, and LSRs that
   don't understand this information simply ignore it.

   The extension headers are carried after the MPLS Label Stack, and the
   presence of EHs are indicate in the label stack by a Extetended
   Spewcial Purpose label called Extention Headder Indicator (EHI) in
   the label stack.

   Extension headers may for example be used when it is required that
   the packet carry some metadata, more details will be found in
   [I-D.song-mpls-extension-header].  Examples of such cases are In-situ
   OAM, Network Telemetry and Measurement and Network Security.





Andersson, et al.        Expires August 24, 2019                [Page 2]


Internet-Draft         EH Label Stack Opedrations          February 2019


   Only EH capable LSRs will process EHs, LSRs that are EH non-capable
   will ignore the EH and forward the packet as if the information was
   not there.

1.1.  Requirement 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.

2.  Operations on an MPLS Label Stack in an EH capable network

   This document provides a set of examples to show the operations
   performed on MPLS encapsulated packets in a network where MPLS EHs
   are used.  The document does also illustrated the procedures for
   processing of the information carried within the MPLS label stack to
   indicate the presence of EHs below the label stack.  For the purpose
   of illustration, we will assume that the indicator used to point to
   EHs is a G-ACh Generic Associated Channel Label (GAL) [RFC5586] +
   G-Ach Associated Channel Header (ACH)[RFC5586] with a set of new ACH
   types to indicate the EH types carried below the MPLS label stack.

   As discussed in [I-D.andersson-mpls-eh-architecture],
   [I-D.song-mpls-extension-header] and [I-D.song-mpls-eh-indicator]
   there are alternatives to the use of GAL as the indicator; for
   example an Extension Label (XL) [RFC7274] + one or more Extended
   Special Purpose Labels (eSPLs) [RFC7274] could also be used.

2.1.  Physical Topology

   Assume a physical topology that includes both EH capable LSRs and
   non-EH capable LSRs.  The topology is intentionall kept quite simple.

















Andersson, et al.        Expires August 24, 2019                [Page 3]


Internet-Draft         EH Label Stack Opedrations          February 2019


      +---+      +---+      +---+      +---+      +---+      +---+
      |   |      |   |      |   |      |   |      |   |      |   |
      | A +------+ b +------+ c +------+ D +------+ E +------+ F +
      |   |      |   |      |   |      |   |      |   |      |   |
      +---+      +---+      +---+      +---+      +---+      +---+


   Legend:
   A, D, E, and F are EH capable LSRs

   b and c are non-EH capable LSRs.




                           Figure 1: EH topology

   LDP Downstream on Demand (DoD) or Downstream Unsolicited (DU), RSVP-
   TE, an IGP or a centralized controller could be used to create the
   label mappings between the LSRs in an EH capable network.  Referring
   to Figure 1, and using LDP DU for illustration, creation of an EH
   path used by A to send MPLS encapsulated packets with MPLS EHs to F
   is as show below.

   For prefix F reachable at LSR F:

   o  F advertises labels F:[ldp: implicit-null, EH-FEC: implicit-null]
      to E

   o  E advertises labels F:[ldp: 101, EH-FEC: 201] to D

   o  D advertises label F:[ldp: 102] to c

   o  c advertises label F:[ldp: 103] to b

   o  b advertises label F:[ldp: 104] to A

   This will result in installed labels as shown in Figure 2.













Andersson, et al.        Expires August 24, 2019                [Page 4]


Internet-Draft         EH Label Stack Opedrations          February 2019


       +---+       +---+       +---+       +---+       +---+       +---+
       |   |..104..|   |..103..|   |..102..|   |..101..|   |..php..|   |
       | A +-------+ b +-------+ c +-------+ D +-------+ E +-------+ F +
       |   |       |   |       |   |       |   |..201..|   |..php..|   |
       +---+       +---+       +---+       +---+       +---+       +---+

       Legend:
       A, D, E and F are EH capable nodes.
       b and are non-EH capable nodes.




                           Figure 2: EH topology

2.2.  A day in the life of a packet

   This section provides examples of forwarding for some common
   scenarios in networks with a mix of EH-capable and non-EH-capable
   LSRs and packets with and without EHs following the MPLS label stack.

   All the information processed in the examples below is not strictly a
   part of the "label stack"; ACH, EHL, HEH, EH and Payload are carried
   after the last entry in the label stack.



























Andersson, et al.        Expires August 24, 2019                [Page 5]


Internet-Draft         EH Label Stack Opedrations          February 2019


   For reference the following shows the full MPLS EH stack, i.e.
   including also the EH specific information and the payload.
   0                                  31
   +--------+--------+--------+--------+
   |         MPLS Label Stack          |
   +--------+--------+--------+--------+
   |          GAL (s-bit = 1)          | * If eSPL then replace GAL
   +--------+--------+--------+--------+   with XL+EHL
   |    ACH Type = (EH E2E/HBH/BOTH)   | * If SPL then ACH not required;
   +--------+--------+--------+--------+    HEH follows XL+EHL directly
   | Header of Extension Headers (HEH) |
   +--------+--------+--------+--------+
   |                                   |
   ~      Extension Header (EH) 1      ~
   |                                   |
   +--------+--------+--------+--------+
   |                                   |
   ~      Extension Header (EH) N      ~
   |                                   |
   +--------+--------+--------+--------+
   |                                   |
   ~   Upper Layer Protocols/Payload   ~
   |                                   |
   +--------+--------+--------+--------+




                Figure 3: MPLS Extension Header (EH) Stack

2.2.1.  Non-VPN Case

   For non-VPN there are two variants, either the EH is present or it is
   not.

2.2.1.1.  Non-VPN with the EH in the packet

   o  A sends packet to b

      *  stack = [104, GAL, ACH, HEH, EH, IP]

   o  b is a legacy router so just swaps [104] to [103], and sends the
      packet to c

      *  stack = [103, GAL, ACH, HEH, EH, IP]

   o  c is a legacy router so just swaps [103] to [102], and sends the
      packet to D



Andersson, et al.        Expires August 24, 2019                [Page 6]


Internet-Draft         EH Label Stack Opedrations          February 2019


      *  stack = [102, GAL, ACH, HEH, EH, IP]

   o  D is an EH capable LSR and receives the packet with [102] on top
      of the stack; D scans the packet for an EH; D finds EH and
      processes and then swaps the top label to [101] and then sends the
      packet on to E

      i   Note: this goes on the standard FEC because we only announce
          in the packet there is NO EH.  In this case EH is present.

      *  stack = [101, GAL, ACH, HEH, EH, IP]

   o  E receives [101] and scans the packet for EH; finds EH and
      processes and then pops the top lael and send the packet to F

      *  stack = [GAL, ACH, HEH, EH, IP]

         +  Note: E is the penultimate hop router so it pops the
            standard LDP label, and send on the standard FEC to F.

   o  F receives the packet and scans the packet for EH; finds EH and
      processes it.  As F is the ultimate hop it pops GAL, and removes
      ACH, HEH and EH, processes IP and forwards the packet.

2.2.1.2.  Non-VPN without an EH in the packet

   In this example there is no EH present in the packet.

   o  A sends packet to b

      *  stack = [104, IP]

   o  b receives the packet, b is a legacy router so it just swaps [104]
      to [103] and sends the packet to c

      *  stack = [103, IP]

   o  c receives the packet, c is a legacy router so it just swaps [103]
      to [102], and sends the packet to D

      *  stack = [102, IP]

   o  D receives the packet, D is an EH capable router, D searches the
      packet for an EH but finds no EH, D swaps [102] to [201], and
      sends the packet to E

      *  stack = [201, IP]




Andersson, et al.        Expires August 24, 2019                [Page 7]


Internet-Draft         EH Label Stack Opedrations          February 2019


         +  Note: in this case D sends the packet using the EH-FEC as EH
            is *not* present.

         +  Note: If downstream is not EH capable then D sends the
            packet on the standard FEC.

   o  E receives the packet [201] and bypasses EH processing (received
      on the "no EH present" FEC; E is penultimate node so it pops EH-
      FEC label; and send the packet to F.

      *  stack = [IP]; not exactly a "label stack", but listed here for
         symmetry

   o  F receives [IP] and routes the packet

2.3.  The VPN case

   In these two examples there is VPN information in the label stack, in
   the first there also EHs in the packet.

2.3.1.  VPN with EH in the packet

   o  A sends packet to b

      *  stack = [104, VPN, GAL, ACH, HEH, EH, IP]

   o  b receives the packet; b is a legacy router and just swaps [104]
      to [103] and sends the packet to c

      *  stack = [103, VPN, GAL, ACH, HEH, EH, IP]

   o  c receives the packet; c is a legacy router and just swaps [103]
      to [102] and sends the packet to D

      *  stack = [102, VPN, GAL, ACH, HEH, EH, IP]

   o  D receives the packet; D is EH capable LSR; D will search the
      packet for EH and will find and process the EH; D will then swap
      [102] to [101] and sends the packet to E

      *  stack = [101, VPN, GAL, ACH, HEH, EH, IP]

         +  Note: This packet will be sent normal IP standard FEC; only
            packets that does not include an EH will be sent on the "no
            EH present" FEC.






Andersson, et al.        Expires August 24, 2019                [Page 8]


Internet-Draft         EH Label Stack Opedrations          February 2019


   o  E receives the packet; E is EH capable LSR; E will search the
      packet for EH and will find and process the EH; E will then pop
      [101] and sends the packet to F

      *  stack = VPN, GAL, ACH, HEH, EH, IP]

         +  Note: E is penultimate hop so pops the LDP label and send
            the packet on normal IP standard FEC; only packets that does
            not include an EH will be sent on the "no EH present" FEC.

   o  F receives and scans the packet for EH; finds EH and processes it.
      As F is the ultimate hop it pops the GAL, and removes ACH, HEH and
      EH, processes the VPN label and forwards the packet.

2.3.2.  VPN without EH in the packet

   o  A sends packet to b

      *  stack = [104, VPN, IP]

   o  b receives the packet; b is a legacy router and just swaps [104]
      to [103] and sends the packet to c

      *  stack = [103, VPN, IP]

   o  c receives the packet; c is a legacy router and just swaps [103]
      to [102] and sends the packet to D

      *  stack = [102, VPN, IP]

   o  D receives the packet; D is EH capable LSR; D will search the
      packet for EH; D will not find an EH; D will then swap [102] to
      [201] and sends the packet to E on the "no EH present" FEC.  Loa

      *  stack = [101, VPN, IP]

         +  Note: This packet will be sent on the "no EH pesent" FEC;

   o  E receives the packet [201] and bypasses EH processing (received
      on the "no EH present" FEC; E is the penultimate node so it pops
      EH- FEC label; and send the packet to F on the "no EH present"
      FEC.

      *  stack = [VPN, IP]

         +  Note: E is penultimate hop so E pops the "no FEC present"
            label and send the packet to F.




Andersson, et al.        Expires August 24, 2019                [Page 9]


Internet-Draft         EH Label Stack Opedrations          February 2019


   o  F receives and scans the packet for EH; finds no EH and bypasses
      EH processing.  As F is the ultimate hop it processes the VPN
      label and forwards the packet.

2.4.  RSVP-TE Tunnel case

   The RSVP-TE tunnel is not EH capable or the capability has been
   disabled.

   Assume a physical topology that includes both EH capable LSRs and
   non-EH capable LSRs, as in the earlier examples.  This topology also
   includes a low cost RSVP-TE tunnel between b and D.


      +---+      +---+      +---+      +---+      +---+      +---+
      |   |      |   |      |   |      |   |      |   |      |   |
      | A +------+ b +------+ c +------+ D +------+ E +------+ F +
      |   |      |   |      |   |      |   |      |   |      |   |
      +---+      +---+      +---+      +---+      +---+      +---+
                  | |                   | |
                  | |___________________| |
                  |_______________________|


   Legend:
   A, D, E, and F are EH capable LSRs

   b and c are non-EH capable LSRs.

   Nodes that transport the RSVP-TE tunnel are not EH capable, or the EH
   capability is disabled.



                           Figure 4: EH topology

   For this example the following assumptions are made:

   o  An RSVP-TE tunnel has been established between b and D (packets
      will bypass c)

   o  F is reachable at b through RSVP-TE tunnel

   o  LDP is enabled on the RSVP-TE tunnel

   For prefix [F]: The following label mappings are sent by the LSRs in
   the network.




Andersson, et al.        Expires August 24, 2019               [Page 10]


Internet-Draft         EH Label Stack Opedrations          February 2019


   o  F advertises labels F: [ldp: implicit-null, EH-FEC: implicit-null]
      to E

   o  E advertises labels F: [ldp: 101, EH-FEC: 201] to D

   o  D advertises label F: [ldp: 102] to c and F:[ldp: 102] to b

   o  c advertises label F: [ldp: 103] to b

   o  b advertises label F: [ldp: 104] to A

   This will result in label mappings like this.


      +---+       +---+       +---+       +---+       +---+       +---+
      |   |--104..|   |..103..|   |..102..|   |..101..|   |..php..|   |
      | A +-------+ b +-------+ c +-------+ D +-- ----+ E +-------+ F +
      |   |       |   |       |   |       |   |..201..|   |..php..|   |
      +---+  -    +---+       +---+       +---+       +---+       +---+
                   | |                     | |
                   | +---------------------+ |
                   |      [RSVP, 102]        |
                   +-------------------------+


   Legend:
   A, D, E, and F are EH capable LSRs

   b and c are non-EH capable LSRs.

   Nodes that transport the RSVP-TE tunnel are not EH capable, or the EH
   capability is disabled. [RSVP] represents the series of tunnel top
   lables.



                           Figure 5: EH topology

   To describe the label stack operations in this case the VPN label
   stack is used, starting with the case where an EH is present in the
   packet.

2.4.1.  RSVP Tunnel and EH present in the packet

   o  A sends packet to b

         stack = [104, VPN, GAL, ACH, HEH, EH, IP]




Andersson, et al.        Expires August 24, 2019               [Page 11]


Internet-Draft         EH Label Stack Opedrations          February 2019


   o  b receives the packet, since b is a legacy router it swaps [104]
      to [102], the next-hop reachable through the RSVP-TE tunnel; push
      the ingress RSVP-TE tunnel label and send it via the tunnel to the
      tunnel endpoint D

         stack = [RSVP, 102, VPN, GAL, ACH, HEH, EH, IP]

   o  Intermediate tunnel LSRs will forward (swap) based on the RSVP-TE
      label.

   o  D receives the packet, D will pop the last RSVP-TE label; since D
      is a EH capable router it will search the stack and find the EH,
      after processing the EH it will swap [102] to [101], and send the
      packet to E over the normal FEC

         stack = [101, VPN, GAL, ACH, HEH, EH, IP]

            Note: this will be forwarded on the standard FEC because
            since the EH is present in the packet, only packet without
            an EH is forwarded on the "no EH present" FEC.

   o  E receives the packet [101]; since E is a EH capable router it
      will search the stack and find the EH; after processing the EH it
      will pop [101], and send the packet to E over the normal FEC

         stack = [VPN, GAL, ACH, HEH, EH, IP]

            Note: As E is the penultimate hop it will pop the standard
            LDP label.

   o  F receives the packet with the VPN label on top [VPN]; E scans the
      packet for EH; finds EH and processes.  As F is the ultimate hop
      it pops GAL, and removes ACH, HEH and EH, processes VPN label and
      forwards the packet.

2.4.2.  RSVP Tunnel and no EH present in the packet

   o  A sends packet to b

      *  stack = [104, VPN, IP]

   o  b receives the packet [104]; be is legacy router and will not
      search for an EH; b swaps [104] to [102]; pushes [RSVP] sends
      packet to D over the RSVP-TE tunnel.

      *  stack = [RSVP, 102, VPN, IP]





Andersson, et al.        Expires August 24, 2019               [Page 12]


Internet-Draft         EH Label Stack Opedrations          February 2019


   o  Intermediate tunnel LSRs will forward (swap) based on the RSVP-TE
      label.

   o  D receives pops the tunnel label [RSVP], D is EH capable and scans
      the packet for EH; D finds no EH is present; pops RSVP-TE label,
      and then swaps LDP label [102 ]to [201] and sends the packet to E

      *  stack = [201, VPN, IP]

         +  Note: in this case D sends the packet using the "no EH
            present" FEC, since there is no EH in the packet.

         +  Note: If the downstream LSR is not EH capable then D will
            sends the packet on the standard FEC.

   o  E receives [201] and bypasses EH processing since the packet is
      received on the "no EH present" FEC; E is the pen-ultimate hop so
      it EH-FEC label and forward the packet to F

      *  stack = [VPN, IP]

   o  F receives the packet [VPN]; and scans the packet for EH; does not
      find EH, processes VPN label and forwards the packet.

2.4.3.  EH capable RSVP-TE tunnel

   The case where an RSVP-TE tunnel is both EH capable and EH enabled is
   for further study.

3.  Security Considerations

   TBA

4.  IANA Considerations

   There are no requests for IANA actions in this document.

   Note to the RFC Editor - this section can be removed before
   publication.

5.  Acknowledgements

   TBA

   -






Andersson, et al.        Expires August 24, 2019               [Page 13]


Internet-Draft         EH Label Stack Opedrations          February 2019


6.  References

6.1.  Normative References

   [I-D.andersson-mpls-eh-architecture]
              Andersson, L., Guichard, J., Song, H., and S. Bryant,
              "MPLS Extension Header Architecture", draft-andersson-
              mpls-eh-architecture-00 (work in progress), February 2019.

   [I-D.song-mpls-eh-indicator]
              Song, H., Li, Z., Zhou, T., and L. Andersson, "Options for
              MPLS Extension Header Indicator", draft-song-mpls-eh-
              indicator-00 (work in progress), February 2019.

   [I-D.song-mpls-extension-header]
              Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS
              Extension Header", draft-song-mpls-extension-header-02
              (work in progress), February 2019.

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

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

6.2.  Informative References

   [RFC7274]  Kompella, K., Andersson, L., and A. Farrel, "Allocating
              and Retiring Special-Purpose MPLS Labels", RFC 7274,
              DOI 10.17487/RFC7274, June 2014,
              <https://www.rfc-editor.org/info/rfc7274>.

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

Authors' Addresses

   Loa Andersson
   Bronze Dragon Consulting

   Email: loa@pi.nu





Andersson, et al.        Expires August 24, 2019               [Page 14]


Internet-Draft         EH Label Stack Opedrations          February 2019


   James N Guichard
   Huawei Technologies

   Email: james.n.guichard@huawei.com


   Haoyu Song
   Huawei Technologies

   Email: haoyu.song@huawei.com


   Stewart Bryant
   Huawei Technologies

   Email: stewart.bryant@gmail.com



































Andersson, et al.        Expires August 24, 2019               [Page 15]