SRv6 for Inter-Layer Network Programming
draft-dong-spring-srv6-inter-layer-programming-02

Document Type Active Internet-Draft (individual)
Authors Jie Dong  , Zongpeng Du 
Last updated 2021-10-24
Stream (None)
Intended RFC status (None)
Formats plain text html xml pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
SPRING Working Group                                             J. Dong
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                                   Z. Du
Expires: April 27, 2022                                     China Mobile
                                                        October 24, 2021

                SRv6 for Inter-Layer Network Programming
           draft-dong-spring-srv6-inter-layer-programming-02

Abstract

   This document defines a new SRv6 network function which can be used
   for SRv6 inter-layer network programming.  It is a variant of the
   End.X function.  Instead of pointing to an L3 adjacency, this
   function points to an underlay interface.  Such a interface can stand
   for a underlay link or path/connection between two routers, which may
   be invisible in the L3 topology.

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 April 27, 2022.

Copyright Notice

   Copyright (c) 2021 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

Dong & Du                Expires April 27, 2022                 [Page 1]
Internet-Draft    SRv6 Inter-Layer Network Programming      October 2021

   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 and Terminology . . . . . . . . . . . .   3
   3.  END.XU Function . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Use Case for SRv6 Underlay Interface Function . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   In many scenarios, operator owns a multi-layered network.  In that
   case, cross-layer design and optimization mechanisms are more
   efficient in resource utilization and SLA assurance, but normally are
   also considered more complicated.  As an IP/MPLS based technology,
   Segment Routing (SR) normally does not need to care about the network
   layers beneath the IP layer.  One exception is as described in
   [RFC8668], IS-IS is extended to advertise the link attributes and
   Segment Identifiers (SIDs) of Layer 2 (L2) bundle members, so that
   operator can control traffic flows to traverse a particular
   individual L2 link which comprises the L2 bundle interface

   In [RFC8986], it is described that for an outgoing interface bundle
   made of 10 member links, up to 11 End.X local SIDs for that bundle
   need to be allocated.  One END.X for the bundle itself and then up to
   one END.X for each member link.  However, there are some differences
   between the normal END.X function for the bundle and the END.X
   function for the member link, as they are not at the same network
   layer.  Moreover, besides the L2 bundle use case, there are other
   types of underlay interfaces or connections, which can be integrated
   and programmed using SRv6.  This document aims to define a unified
   SRv6 function to support those inter-layer network programming in
   SRv6.

   As another example, the underlay of the IP network can be an optical
   network.  In many today's IP and optical transport networks, IP
   network and optical network are maintained separately, and in most
   cases, the optical network works as an underlay which is invisible to
   the IP network.  However, the optical path resource and the IP path
   resource may not be one-to-one mapped so that some resource in

Dong & Du                Expires April 27, 2022                 [Page 2]
Internet-Draft    SRv6 Inter-Layer Network Programming      October 2021

   optical network can not be fully used.  In some cases, there may be
   some optical paths that is not visible in the L3 IP topology, and
   thus they can not be used to carry IP traffic.

   Following the SRv6 network programming concept in [RFC8986], we can
   use a new SRv6 function to identify a specific optical path, and put
   the corresponding SRv6 SID into an integrated SRv6 SID list.  The
   optical path can be either OTN based or DWDM based.  Besides the
   optical paths, it is also possible to use the SRv6 function to
   identify other underlay paths/connenctions, such as a back-to-back
   Ethernet connection, or some pre-configured tunnels.

   The SRv6 function mentioned above can be considered as a variant of
   the END.X function defined in [RFC8986], so that it is suggested to
   define a new SRv6 function for it.  This document defines the
   operation of this new SRv6 function, and describes some use cases of
   this SRv6 underlay interface function.

2.  Requirements Language and Terminology

   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
   [RFC2119] when they appear in ALL CAPS.  When these words are not in
   ALL CAPS (such as "should" or "Should"), they have their usual
   English meanings, and are not to be interpreted as [RFC2119] key
   words.

3.  END.XU Function

   This section defines the new SRv6 underlay interface function.

   The "Endpoint with cross-connect to an underlay interface" function
   (End.XU for short) is a variant of the End.X function defined in
   [RFC8986].

   When N receives a packet destined to S and S is a local End.XU SID, N
   does:

      1.  IF NH=SRH and SL > 0
      2.     decrement SL
      3.     update the IPv6 DA with SRH[SL]
      4.     forward to underlay interface bound to the SID S
      5.  ELSE IF NH!=SRH
      6.     Send an ICMP parameter problem message; drop the packet
      7.  ELSE
      8.     drop the packet

Dong & Du                Expires April 27, 2022                 [Page 3]
Internet-Draft    SRv6 Inter-Layer Network Programming      October 2021

   Note that the underlay interface or connection in step 4 SHOULD be
   established before this function and the associated SID is announced
   into the network.

   This End.XU function can be announced using IGP or BGP-LS in a
   similar way to the announcement of END.X function.  The detailed
   protocol extension will be described in a separate document.

4.  Use Case for SRv6 Underlay Interface Function

   Assuming that an operator owns both the IP and optical network, and
   the operator needs to deploy E2E service across IP and optical
   network, with traditional approaches the planning and service
   provisioning would be complex and time consuming due of the manual
   synergy needed between the operator's IP team and optical team.  With
   the popularity of SR and SRv6, one straightforward way is to use a
   SID list that integrates the path in both the IP layer and the
   optical layer.

   As the optical layer is not packet based, normally source routing
   mechanism can not be directly used in the optical network.  However,
   we can expose the abstracted optical path and its associated
   attribute and resource information into the network control system of
   the IP network, by using the SRv6 End.XU function defined in this
   document, so that E2E inter-layer paths can be programmed to meet
   some specific traffic's SLA, such as low latency.

Dong & Du                Expires April 27, 2022                 [Page 4]
Internet-Draft    SRv6 Inter-Layer Network Programming      October 2021

                -----          -----          -----
               |  P1 |--------|  P2 |--------|  P3 |
                -----          -----          -----
               /  |.             |.             |.  \
       -----  /   | .            | .            | .  \ -----
      |  P7 |     |  .           |  .           |  .  |  P8 |
       ----- \    |   .          |   .          |   ./ -----
              \   |    .         |    .         |  / .
                -----   .      -----   .      -----   .
               |  P4 |-------|  P5 |--------|  P6 |   .
                -----    .     -----     .    -----     .
                  .      .       .       .      .       .
                  .    =====      .     =====    .     =====
                   .  |  O1 |----------|  O2 |--------|  O3 |
                    .  =====        .   =====      .   =====
                     .    |          .    |         .    |
                      .   |           .   |          .   |
                       .  |            .  |           .  |
                        . |             . |            . |
                         .|              .|             .|
                       =====            =====          =====
                      |  O4 |----------|  O5 |--------|  O6 |
                       =====            =====          =====
             Figure 1. IP and Optical Layered Network Topology

   In Figure 1, P1 to P8 are IP nodes, and O1 to O6 are optical nodes.
   Assume we need to deploy a low latency path between P7 and P8.
   According to traditional segment routing in IP layer, perhaps we can
   choose the path along {P7, P1, P2, P3, P8}. But if an optical path
   from O1 to O3 exists, and the End.XU function defined in this
   document is used to announce this path into the IP domain with
   specific attributes, the headend node or controller in IP domain can
   choose the path along {P7, P1, END.XU, P3, P8} which provides lower
   latency than the normal paths.

   The creation of the optical path from O1 to O3 may be requested
   either by the headend IP node P7 or the IP network controller (not
   shown in the Figure).  The creation should be done by the optical
   network controller (not shown in the Figure), so that P7 or IP
   network controller needs to inform the path requirements to the
   optical network controller.  The details of the process are out of
   scope of this document, and may refer to
   [I-D.ietf-teas-actn-poi-applicability].

   We can also use the topology in Figure 1 to show another use case.
   Assume there are two optical paths between P1 and P2.  One is {O1,
   O2} , and the other is {O1, O4, O5, O2}. We can assign two End.XU
   functions for these two underlay paths separately.  One is P1::C2 for

Dong & Du                Expires April 27, 2022                 [Page 5]
Internet-Draft    SRv6 Inter-Layer Network Programming      October 2021

   the path {O1, O2}, and the other is P1::C45 for the path {O1, O4, O5,
   O2}. The headend P7 or the IP network controller will be informed
   about the two SRv6 functions and the associated path attributes, so
   that the headend or the controller can program different end-to-end
   inter-layer paths using integrated SID lists for services with
   different SLA requirement.

   Assume the path {O1, O2} is owned by the operator with a higher
   reliability, and the path {O1, O4, O5, O2} is not totally owned by
   the operator, i.e., they are partly rented.  In this use case, for
   the traffic with high reliability requirement, the integrated SID
   list implemented in P7 would be <P1::C2, ... , P8>.  The ellipsis
   means some other possible SRv6 functions can be added along the path.
   For traffic with normal reliability requirement, the integrated SID
   list programmed in P7 can be <P1::C45, ... , P8>.  Before the
   announcement of the two functions, the node P1 needs to map the
   P1::C12 function to the optical path {O1, O2}, and map P1::C45 to the
   optical path {O1, O4, O5, O2}.

5.  Security Considerations

   TBD

6.  IANA Considerations

   This document defines a new SRv6 function called END.XU.

   IANA is requested to allocate four new code points from the "SRv6
   Endpoint Behaviors" sub-registry in the "Segment-routing with IPv6
   data plane (SRv6) Parameters" registry:

           +-------+--------+---------------------------+-----------+
           | Value |  Hex   |     Endpoint function     | Reference |
           +-------+--------+---------------------------+-----------+
           |  TBA  |  TBA   |  End.XU (no PSP, no USP)  | [This.ID] |
           |  TBA  |  TBA   |      End.XU with PSP      | [This.ID] |
           |  TBA  |  TBA   |      End.XU with USP      | [This.ID] |
           |  TBA  |  TBA   |    End.XU with PSP&USP    | [This.ID] |
           +-------+--------+---------------------------+-----------+

7.  Acknowledgements

   The authors would like to thank Xiaodong Chang for his review and
   comments.

Dong & Du                Expires April 27, 2022                 [Page 6]
Internet-Draft    SRv6 Inter-Layer Network Programming      October 2021

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

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              DOI 10.17487/RFC2629, June 1999,
              <https://www.rfc-editor.org/info/rfc2629>.

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

8.2.  Informative References

   [I-D.ietf-teas-actn-poi-applicability]
              Peruzzini, F., Bouquier, J., Busi, I., King, D., and D.
              Ceccarelli, "Applicability of Abstraction and Control of
              Traffic Engineered Networks (ACTN) to Packet Optical
              Integration (POI)", draft-ietf-teas-actn-poi-
              applicability-03 (work in progress), July 2021.

   [RFC8668]  Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri,
              M., and E. Aries, "Advertising Layer 2 Bundle Member Link
              Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668,
              December 2019, <https://www.rfc-editor.org/info/rfc8668>.

Authors' Addresses

   Jie Dong
   Huawei Technologies
   Huawei Campus, No.156 Beiqing Road
   Beijing, 100095
   China

   Email: jie.dong@huawei.com

Dong & Du                Expires April 27, 2022                 [Page 7]
Internet-Draft    SRv6 Inter-Layer Network Programming      October 2021

   Zongpeng Du
   China Mobile
   No.32 XuanWuMen West Street
   Beijing, 100053
   China

   Email: duzongpeng@foxmail.com

Dong & Du                Expires April 27, 2022                 [Page 8]