SRv6 for Inter-Layer Network Programming

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 27 April 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

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

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

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

Authors' Addresses