SRv6 Underlay tunnel Programming
draft-han-spring-srv6-underlay-tunnel-programming-00

SPRING                                                            L. Han
Internet-Draft                                                   M. Wang
Intended status: Standards Track                            China mobile
Expires: 9 January 2023                                          R. Chen
                                                                  A. Liu
                                                         ZTE Corporation
                                                             8 July 2022

                    SRv6 Underlay tunnel Programming
          draft-han-spring-srv6-underlay-tunnel-programming-00

Abstract

   This document defines a new SRv6 Endpoint behavior which can be used
   for SRv6 underlay tunnel (e.g.L1 channel) Programming, called
   END.BXC, this behavior are used to bind an underlay tunnel.

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 9 January 2023.

Copyright Notice

   Copyright (c) 2022 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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Han, et al.              Expires 9 January 2023                 [Page 1]
Internet-Draft    Underlay tunnel Programming with SRv6        July 2022

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  Problems and Solutions  . . . . . . . . . . . . . . . . . . .   2
     3.1.  Problems  . . . . . . . . . . . . . . . . . . . . . . . .   2
     3.2.  END.BXC Function  . . . . . . . . . . . . . . . . . . . .   3
       3.2.1.  Option 1: . . . . . . . . . . . . . . . . . . . . . .   4
       3.2.2.  Option 2: . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.3.  Procedures  . . . . . . . . . . . . . . . . . . . . .   5
   4.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The Segment Routing over IPv6 (SRv6) Network Programming framework
   enables a network operator or an application to specify a packet
   processing program by encoding a sequence of instructions in the IPv6
   packet header as described in [RFC8986].

   Each instruction is implemented on one or several nodes in the
   network and identified by an SRv6 Segment Identifier in the packet.

   This document defines a new SRv6 Endpoint behavior which can be used
   for SRv6 underlay tunnel (e.g.L1 channel) Programming, called
   END.BXC, this behavior are used to bind an underlay tunnel.

2.  Requirements Language

   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 RFC 2119 [RFC2119].

3.  Problems and Solutions

3.1.  Problems

Han, et al.              Expires 9 January 2023                 [Page 2]
Internet-Draft    Underlay tunnel Programming with SRv6        July 2022

     +---------------------------------------------------------------------------+
     |          E2E SRv6 Policy                                                  |
   +-+-+                             +-+-+         +-+-+                       +-+-+
   |PE1+-----------------------------+PE2|---------|PE3+-----------------------+PE4|
   +-+-+                             +-+-+         +-+-+                       +-+-+
     |                                                                           |
     +---------------------------------------------------------------------------+

         +---------------------------------+              +--------------------------+
     |       MTN/FGU Channel           |              |      SRv6 Policy         |
   +-+-+   +--+    +--+    +--+      +-+-+          +-+-+    +--+    +--+      +-+-+
   |PE1+---+P1+----+P2+--- +P3+----->+PE2|--------->|PE3+----+P4+----+P5+----->+PE4|
   +-+-+   +--+    +--+    +--+      +-+-+          +-+-+    +--+    +--+      +-+-+
     |         Network A               |              |     Network B            |
     +---------------------------------+              +--------------------------+

                               Figure 1

   Usecase1:

   The above Figure shows two different network domains.  Network A
   deploy ITU-T MTN/OTN, and Network B deploy SRv6.  Due to network
   evolution requirements, The edge nodes of the Network A are upgraded
   to support SRv6,but the forwarding node not upgraded.

   Services are running between PE1 and PE4.  The operator need to
   deploy E2E SRv6 Policy across network A and network B.

   Since the forwarding nodes of Network A are not forwarded based on
   packet based, and it is also invisible to the end to end controller,
   so it cannot be programmed into the SRv6 Policy.  The edge nodes of
   the Network A upgraded to SRv6 can be programmed into SRv6 Policy,
   and through the END.BXC behavior defined in this document, so E2E
   SRv6 can traverses the ITU-T MTN/OTN network.

   Usecase2:

   Network A deploy multiple Forwarding technology (like SRv6 and MTN,
   etc.), and Network B deploy SRv6.  However, customers require meet
   some SLA (like low latency, etc.) in the network A.  The E2E SRv6
   Policy which programmed the SRv6 END.BXC to the segment list can meet
   some customer's SLA.

3.2.  END.BXC Function

   The SID format is defined in [RFC8986].  An SRv6 SID cosisits of
   three parts: LOC:FUNCT:ARG, The format of an SRv6 SID is shown below.

Han, et al.              Expires 9 January 2023                 [Page 3]
Internet-Draft    Underlay tunnel Programming with SRv6        July 2022

     +------------------------------------------------------------------+
     |     Locator          |        Function     |         ARG         |
     +------------------------------------------------------------------+

                               Figure 2

   END.BXC is a variant of the End behavior.  This is a SRv6
   instantiation of a Binding SID.  Any SID instance of this behavior is
   associated with an underlay tunnel(e.g.L1 channel).  Typical types of
   the L1 channel include MTN, and OTN.

   This section provides two definitions of END.BXC.

3.2.1.  Option 1:

   An SRv6 Endpoint behavior may require additional information for its
   processing (e.g., related to the flow or service), This information
   may be encoded in the ARG part of the SID as defined in [RFC8986].
   This section defines the ARG part of the END.BXC SID.  The high bit
   part of ARG is used to encode Channel Type, and the low bit part of
   ARG is used to encapsulate Channel ID.  The Channel is uniquely
   identified by channel type and channel ID.  The format of ARG in
   END.BXC SID is shown in Figure 2.

               +------------------------------------------------+
               |channel Type|    channel ID                     |
               +------------------------------------------------+

                                  Figure 3

   The allocation of the Channel Type and the Channel ID are local to
   the SR Segment Endpoint Node instantiating this behavior.  The ARG
   length is determined by the local configuration and is announced into
   the network.  In addition, the Channel Type length and the Channel ID
   length are also locally configured and is announced into the network.
   The detailed protocol extension will be considered, and will be
   described in other documents.

   When N receives a packet destined to S and S is a local End.BXC SID,
   the line S14 from the End processing defined in [RFC8986] is replaced
   by the following:

   S14.   Get the channel type and channel ID from the lower bit of S.
   S15.   Find channel X based on channel type and channel ID
   S16.   Update IPv6 DA with Segment List[Segments Left]
   S17.   Forward the packet to the new destination via channel X.

Han, et al.              Expires 9 January 2023                 [Page 4]
Internet-Draft    Underlay tunnel Programming with SRv6        July 2022

3.2.2.  Option 2:

   In this option, ARG part are not be used.We only defines END.BXC SID.

   When N receives a packet destined to S and S is a local End.BXC SID,
   the line S15 from the End processing defined in [RFC8986] is replaced
   by the following:

   S15  Forward the packet to the new destination via channel X.

   The END.BXC behavior is advertised to the network.  The detailed
   protocol extension will be considered, and will be described in other
   documents.

3.2.3.  Procedures

   Here we will describe the data plane procedures by taking examples,
   and we will discuss the use-case mentioned under section 3.

   In Figure 1, Network A deploy ITU-T MTN/OTN, and Network B deploy
   SRv6.  PE1,PE2,PE3 and PE4 are deployed SRv6, and PE1, P1 to p3,and
   PE3 are deployed ITU-T MTN/OTN.  One END.BXC SID is assigned for the
   underlay tunnel P1 to P3, so the E2E SRv6 path is <PE1::END.BXC,
   PE2::END.X, PE3::END.B6, PE4::DT6>.

4.  Benefits

   There are some obvious benefits by using the END.BXC function.
   Fisrtly, as shown from the usecases above, with the END.BXC function,
   it can build an end-to-end SRv6 tunnel even across an underlay
   connection (called channel).  Using the END.BXC function, it is
   different with the END.X function, since the END.X just forwards to
   an endpoint with cross-connect to a 'layer-3 adjacency'.  That would
   be more complicated for consistency of end-to-end SRv6 policy.
   Secondly, with the END.BXC function, it defines the separate underlay
   channel ID, this can differentiate the L3 adjacency and underlay
   connection ID to simplify the allocation of SID.  This can also
   maintain a separate underlay ID namespace and reduce the number of L3
   route tables.  Thirdly, if we use the ARGs of the END.BXC option 1,
   it can be more easier for scalability of diversity of underlay
   connections.

5.  Acknowledgements

   TBD.

Han, et al.              Expires 9 January 2023                 [Page 5]
Internet-Draft    Underlay tunnel Programming with SRv6        July 2022

6.  IANA Considerations

   The document defines a new SRv6 Endpoint behavior called End.BXC.

   This I-D requests the IANA to allocate, within the "SRv6 Endpoint
   Behaviors" sub-registry belonging to the top-level "Segment-routing
   with IPv6 dataplane (SRv6) Parameters" registry, the following
   allocations:

          Value      Description                               Reference
      ---------------------------------------------------------------
       TBA1      End.BXC - SRv6 underlay tunnel behavior    [This.ID]

7.  Security Considerations

   TBD.

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

   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
              (SRv6) Network Programming", RFC 8986,
              DOI 10.17487/RFC8986, February 2021,
              <https://www.rfc-editor.org/info/rfc8986>.

Authors' Addresses

   Liuyan Han
   China mobile
   China
   Email: hanliuyan@chinamobile.com

   Minxue Wang
   China mobile
   China
   Email: wangminxue@chinamobile.com

   Ran Chen
   ZTE Corporation
   Nanjing
   China

Han, et al.              Expires 9 January 2023                 [Page 6]
Internet-Draft    Underlay tunnel Programming with SRv6        July 2022

   Email: chen.ran@zte.com.cn

   aihua Liu
   ZTE Corporation
   Shenzhen
   China
   Email: liu.aihua@zte.com.cn

Han, et al.              Expires 9 January 2023                 [Page 7]