Internet DRAFT - draft-dong-spring-srv6-inter-layer-programming

draft-dong-spring-srv6-inter-layer-programming







SPRING Working Group                                              L. Han
Internet-Draft                                              China Mobile
Intended status: Standards Track                                 J. Dong
Expires: 2 September 2024                            Huawei Technologies
                                                                   Z. Du
                                                                 M. Wang
                                                            China Mobile
                                                            1 March 2024


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

Abstract

   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.

   Following the SRv6 Network Programming concept, this document defines
   an SRv6 based mechanism for inter-layer network programming, which
   can help to integrate the packet network layer with its underlying
   layers efficiently.  A new SRv6 behavior called End.XU is introduced,
   which is a variant of the SRv6 End.X behavior.  Instead of pointing
   to an interface with layer-3 adjacency, the End.XU behavior points to
   an underlay interface which connects to a remote layer-3 node via
   underlying links or connections that are invisible in the L3 network
   topology.  The applicability of the End.XU behavior in typical inter-
   layer network programming scenarios is also illustrated.

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 2 September 2024.




Han, et al.             Expires 2 September 2024                [Page 1]

Internet-Draft    SRv6 Inter-Layer Network Programming        March 2024


Copyright Notice

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Use Cases of SRv6 Inter-Layer Programming . . . . . . . . . .   3
     2.1.  IP and Optical Inter-layer Programming  . . . . . . . . .   3
     2.2.  IP and MTN Inter-layer Programming  . . . . . . . . . . .   4
   3.  SRv6 END.XU Behavior  . . . . . . . . . . . . . . . . . . . .   4
   4.  Application of SRv6 End.XU  . . . . . . . . . . . . . . . . .   6
     4.1.  IP and Optical Integration  . . . . . . . . . . . . . . .   6
     4.2.  IP and MTN Integration  . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   In many network scenarios, operator owns a multi-layered network.  In
   layer-3, the technology has converged to IP, while there can be
   different technologies in layer-2 and below.  In such networks, the
   cross-layer planning and optimization is considered more efficient
   than independent planning and operation of the layer-3 and the
   underlying networks in terms of resource utilization and SLA
   assurance, but it is also considered more complicated.  Thus a
   mechanism for flexible and efficient inter-layer network integration
   is desired.

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



Han, et al.             Expires 2 September 2024                [Page 2]

Internet-Draft    SRv6 Inter-Layer Network Programming        March 2024


   does not consider about the network layers under the IP layer.
   However, with the capability of SRv6 network programming, it is
   possible to achieve seamless integration between IP (layer-3) and the
   underlying (layer-2 and below) networks.

   Following the SRv6 network programming concept, a new SRv6 behavior
   called End.XU is defined for sending packets through an underlay
   interface, which connects to a remote layer-3 node via underlying
   links or connections.  The SRv6 End.XU behavior can be considered as
   a variant of the SRv6 END.X behavior as defined in [RFC8986].  Unlike
   an L3 adjacency, the underlying links or connections can be
   unidirectional and does not require bidirectional check.  Thus the
   underlay links or connections are invisible in the L3 topology and
   will not be used for IP distributed route computation (e.g.  SPF).
   However, this may just be the expected behavior in inter-layer
   programming where the underlay links or connections are provisioned
   for traffic engineering for specific types of services.  Such
   underlying links or connections may be realized using either Metro
   Transport Network (MTN) paths [ITU-T_G.8310], or ODUk or DWDM
   connections.  The SRv6 End.XU SIDs can be used together with other
   types of SRv6 SIDs to build SRv6 SID lists for inter-layer network
   programming.

   This document first describes the typical use cases of inter-layer
   network programming, then a new SRv6 End.XU behavior for inter-layer
   network programming is introduced.  The applicability of SRv6 End.XU
   behavior in typical inter-layer network programming scenarios is also
   illustrated.

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

2.  Use Cases of SRv6 Inter-Layer Programming

2.1.  IP and Optical Inter-layer Programming

   In many network scenarios, the underlay of the IP network is an
   optical network.  The IP network and optical network are usually
   managed separately, the optical network works as an underlay which is
   normally invisible to the IP network.  In some cases, the optical
   path resources and the IP path resources may not be one-to-one
   mapping, which makes the redundant optical paths not fully used by
   the IP layer.  In some other cases, there may be optical paths



Han, et al.             Expires 2 September 2024                [Page 3]

Internet-Draft    SRv6 Inter-Layer Network Programming        March 2024


   between non-adjacent IP nodes thus they are not visible in the L3
   topology, thus they can not be used for carrying traffic based on IP
   routing.  However, such optical paths may be used for inter-layer
   traffic engineering.

2.2.  IP and MTN Inter-layer Programming

   The architecture of Metro Transport Network (MTN) is defined in
   [ITU-T_G.8310].  In an MTN based network, network nodes can support
   two forwarding modes: per-hop IP packet forwarding and the MTN Path
   (MTNP) layer cross-connect.  An MTN path is a multi-hop underlay
   transport path which may be established between any two nodes in the
   MTN network, and the intermediate nodes on the MTN path will forward
   the traffic based on the pre-established MTN cross-connect without IP
   table lookup.  Thus an MTN path is considered as an underlay
   connection between two remote MTN nodes.  Although in some cases it
   is possible to set up a layer-3 adjacency between the two endpoints
   of the MTN path, it will make the provisioning of MTN path
   complicated.  Moreover, in some cases the two endpoints may reside in
   different IGP areas or ASes, which makes a layer-3 adjacency between
   them more challenging.  Last but not the least, the MTN path may be
   provisioned unidirectionally, which cannot pass the bidirectional
   connectivity check required for a layer-3 link.  Since the MTN paths
   are usually not visible in the L3 topology, it is difficult to
   compute and establish an end-to-end inter-layer path which consists
   of both the layer-3 network segments and the MTN paths.

3.  SRv6 END.XU Behavior

   This section defines a new SRv6 behavior for the underlay cross-
   connect.

   The "Endpoint with Underlay cross-connect" behavior ("End.XU" for
   short) is a variant of the End.X behavior defined in [RFC8986].  Its
   main use is for SRv6 based inter-layer network programming and
   traffic engineering.

   Any SID instance of this behavior is associated with an underlay
   interface, which connects to one or more underlay links or
   connections.

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








Han, et al.             Expires 2 September 2024                [Page 4]

Internet-Draft    SRv6 Inter-Layer Network Programming        March 2024


   S01. When an SRH is processed {
   S02.   If (Segments Left == 0) {
   S03.      Stop processing the SRH, and proceed to process the next
                header in the packet, whose type is identified by
                the Next Header field in the routing header.
   S04.   }
   S05.   If (IPv6 Hop Limit <= 1) {
   S06.      Send an ICMP Time Exceeded message to the Source Address
                with Code 0 (Hop limit exceeded in transit),
                interrupt packet processing, and discard the packet.
   S07.   }
   S08.   max_LE = (Hdr Ext Len / 2) - 1
   S09.   If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
   S10.      Send an ICMP Parameter Problem to the Source Address
                with Code 0 (Erroneous header field encountered)
                and Pointer set to the Segments Left field,
                interrupt packet processing, and discard the packet.

   S11.   }
   S12.   Decrement IPv6 Hop Limit by 1
   S13.   Decrement Segments Left by 1
   S14.   Update IPv6 DA with Segment List[Segments Left]
   S15.   Send the packet through one of the underlay links associated
          with the underlay interface identified by S.
   S16.   }


   Note that the underlay interface and the associated links in step 15
   SHOULD be established before the associated End.XU SID is announced
   into the network.

   When forwarding packets through the underlay interface towards the
   remote endpoint node, the information required for layer-2
   encapsulation may be provisioned via mechanisms such as static
   Neighbor Discovery (ND) Cache.  The details are out of the scope of
   this document.

   End.XU SIDs MAY be announced using IGP or BGP-LS in a similar way to
   the announcement of the End.X SIDs, while the information about the
   underlay connections and the associated End.XU SIDs need to be
   distinguished from the layer-3 links and the End.X SIDs.  The
   detailed protocol extensions will be described in a separate
   document.  With the collected information of End.XU SIDs, the network
   controller or headend nodes could use the End.XU SIDs together with
   other types of SRv6 SIDs to build SRv6 SID lists for inter-layer TE
   paths.





Han, et al.             Expires 2 September 2024                [Page 5]

Internet-Draft    SRv6 Inter-Layer Network Programming        March 2024


4.  Application of SRv6 End.XU


4.1.  IP and Optical Integration

   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 introduction of SRv6 and the End.XU behavior, one simplified
   approach for IP and optical integration is to build a SRv6 SID list
   that integrates the path in both the IP layer and the optical layer.

   As the optical layer is not packet based, source routing mechanism
   can not be directly used in the optical network.  However, the
   abstracted optical paths (e.g., with ODUk or DWDM) could be exposed
   to the control system of the IP network using the SRv6 End.XU SIDs,
   and some of the attributes of the optical paths may also be provided.
   Based on this information, IP-optical inter-layer paths can be
   computed and programmed to meet some specific service requirements,
   such as low latency.

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




Han, et al.             Expires 2 September 2024                [Page 6]

Internet-Draft    SRv6 Inter-Layer Network Programming        March 2024


   In Figure 1, P1 to P8 are IP nodes, and O1 to O6 are optical nodes.
   Assume the operator needs to deploy a low latency path between P7 and
   P8.  With normal segment routing, an IP layer path with the segment
   list {P7, P1, P2, P3, P8} can be used.  But if an optical path from
   O1 to O3 exists, and the End.XU SID defined in this document is used
   to announce this optical path as an underlay connection with specific
   attributes into the IP network, the headend node or the controller in
   IP layer can program an inter-layer TE path along {P7, P1, End.XU
   (O1, O2, O3), P3, P8} which may provide lower latency.

   The optical path between O1 and O3 may be created in advance or as a
   result of the request from the IP layer.  The creation should be done
   by the optical network controller (not shown in the figure).  The
   details of the process are out of scope of this document, and may
   refer to [I-D.ietf-teas-actn-poi-applicability].

   There is also another case of IP and Optical integration.  Assume
   there are two optical paths between P1 and P2.  One is {P1, O1, O2,
   P2} , and the other is {P1, O1, O4, O5, O2, P2}. Two separate End.XU
   SIDs can be allocated for these two underlay connections
   respectively.  One is End.XU P1::C2 for the underlay path {P1, O1,
   O2, P2}, and the other is End.XU P1::C45 for the path {P1, O1, O4,
   O5, O2, P2}. The headend P7 or the IP network controller will be
   informed about these two SRv6 End.XU SIDs and the associated path
   attributes, so that the headend or the controller can program
   different end-to-end inter-layer paths using SRv6 SID lists with
   different End.XU SIDs for services with different SLA requirements.

4.2.  IP and MTN Integration

   Assuming that an operator owns both an MTN network domain and an IP
   network domain.  In the MTN network, each MTN node has both the
   layer-3 functionality and the MTN Path layer functionality.  In
   layer-3, all the MTN nodes are in a layer-3 network topology, which
   connects to the IP network domain.  In the MTN Path Layer, a set of
   MTN paths are provisioned between the selected pairs of MTN nodes for
   traffic engineering.  In the MTN network, different types of services
   may be carried using either a layer-3 path, an end-to-end MTN path,
   or an inter-layer path comprising of both the layer-3 links and the
   MTN paths as segments.  In addition, For some type of services, end-
   to-end paths across the IP domain and the MTN domain are needed,
   which is comprised of both the layer-3 paths and the MTN path as
   different segments.








Han, et al.             Expires 2 September 2024                [Page 7]

Internet-Draft    SRv6 Inter-Layer Network Programming        March 2024


  .......................................... ...........................
  .                                        . .                         .
  .          +----+     +----+     +----+  . . +----+     +----+       .
  .          | M1 |-----| M2 |-----| M3 |------| P1 |-----| P2 |       .
  .          +----+     +----+     +----+  . . +----+     +----+       .
  .         /  |          |          |     . .   |          |  \       .
  . +----+ /   |          |          |     . .   |          |   \+----+.
  . | M7 |/    |          |          |     . .   |          |    | P5 |.
  . +----+\    |          |          |     . .   |          |   /+----+.
  .        \   |          |          |     . .   |          |  /       .
  .         \+----+     +----+     +----+  . . +----+     +----+       .
  .          | M4 |-----| M5 |-----| M6 |------| P3 |-----| P4 |       .
  .          +----+     +----+     +----+  . . +----+     +----+       .
  .                                        . .                         .
  . Layer-3 Topology    MTN Network        . .        IP Network       .
  .                                        . ...........................
  ----------------------------------------------------------------------
  . MTN Path Layer Topology                .
  .                                        .
  .          +----+     +----+     +----+  .
  .          | M1'|################| M3'|  .
  .          +----+ ##  +----+  ## +----+  .
  .                   ##      ##           .
  . +----+              ##  ##             .
  . | M7'|                ##               .
  . +----+              ##  ##             .
  .                   ##      ##           .
  .          +----+ ##  +----+  ## +----+  .
  .          | M4'|################| M6'|  .
  .          +----+     +----+     +----+  .
  .                                        .
  .                                        .
  ..........................................
          .
       Figure 2. A network with MTN Domain and IP Domain
















Han, et al.             Expires 2 September 2024                [Page 8]

Internet-Draft    SRv6 Inter-Layer Network Programming        March 2024


   Figure 2 gives an example of a network with a MTN domain and an IP
   domain.  M1 to M7 are MTN nodes, and P1 to P4 are IP nodes.  The same
   set of MTN nodes builds two separate network layers.  The topology in
   the IP layer shows the layer-3 connectivity between the MTN nodes and
   the connectivity with the IP network domain, while the topology in
   the MTN Path layer shows the MTN paths between the selected pair of
   MTN nodes.  An end-to-end path from M7 to P5 can be established in
   layer-3 using an SRv6 SID list representing the layer-3 path {M7, M1,
   M2, M3, P1, P2, P5}. While for services which require low latency, an
   end-to-end path consisting of both the layer-3 segments and MTN paths
   could be established using an SRv6 SID list representing the inter-
   layer path {M7, M1::C3, P1, P2, P5}, where the End.XU SID M1::C3
   represents the MTN path M1'-M3'.

   This shows that it is convenient to use integrated SRv6 SID lists to
   program inter-layer TE paths both within the MTN domain, and across
   the IP and MTN domain using the combination of L3 SRv6 SIDs and the
   End.XU SIDs.

5.  Security Considerations

   TBD

6.  IANA Considerations

   This document defines a new SRv6 Endpoint behavior called END.XU.

   IANA has allocated the following code points for different flavors of
   End.XU from the "SRv6 Endpoint Behaviors" sub-registry in the
   "Segment-routing with IPv6 data plane (SRv6) Parameters" registry:

+------+--------+------------------------------------------+-----------+
| Value|  Hex   |             Endpoint Behavior            | Reference |
+------+--------+------------------------------------------+-----------+
|  150 | 0x0096 | End.XU                                   | [This ID] |
|  151 | 0x0097 | End.XU with PSP                          | [This ID] |
|  152 | 0x0098 | End.XU with USP                          | [This ID] |
|  153 | 0x0099 | End.XU with USD                          | [This ID] |
|  154 | 0x009A | End.XU with PSP, USP & USD               | [This ID] |
|  155 | 0x009B | End.XU with REPPLACE-CSID                | [This ID] |
|  156 | 0x009C | End.XU with REPPLACE-CSID & PSP          | [This ID] |
|  157 | 0x009D | End.XU with REPPLACE-CSID, PSP, USP & USD| [This ID] |
+------+--------+------------------------------------------+-----------+








Han, et al.             Expires 2 September 2024                [Page 9]

Internet-Draft    SRv6 Inter-Layer Network Programming        March 2024


7.  Acknowledgements

   The authors would like to thank Xiaodong Chang, Yongjian Hu,
   Alexander Vainshtein, Ketan Talaulikar and Zhibo Hu for their review
   and comments.

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

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

   [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)", Work in Progress, Internet-Draft,
              draft-ietf-teas-actn-poi-applicability-11, 22 February
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              teas-actn-poi-applicability-11>.

   [ITU-T_G.8310]
              ITU-T, "ITU-T G.8310: Architecture of the metro transport
              network",  https://www.itu.int/rec/T-REC-
              G.8310-202012-I/en, December 2020.

Authors' Addresses

   Liuyan Han
   China Mobile
   No.32 XuanWuMen West Street
   Beijing, 100053
   China



Han, et al.             Expires 2 September 2024               [Page 10]

Internet-Draft    SRv6 Inter-Layer Network Programming        March 2024


   Email: hanliuyan@chinamobile.com


   Jie Dong
   Huawei Technologies
   Huawei Campus, No.156 Beiqing Road
   Beijing, 100095
   China
   Email: jie.dong@huawei.com


   Zongpeng Du
   China Mobile
   No.32 XuanWuMen West Street
   Beijing, 100053
   China
   Email: duzongpeng@foxmail.com


   Minxue Wang
   China Mobile
   No.32 XuanWuMen West Street
   Beijing, 100053
   China
   Email: wangminxue@chinamobile.com


























Han, et al.             Expires 2 September 2024               [Page 11]