Network Working Group Z. Li Internet-Draft C. Li Intended status: Standards Track N. Wu Expires: October 16, 2021 Huawei April 14, 2021 Tunnel Segment in Segment Routing draft-li-spring-tunnel-segment-02 Abstract This document introduces a new type of segment, Tunnel Segment, for the segment routing (SR). Tunnel segment can be used to reduce SID stack depth of SR path, span the non-SR domain or provide differentiated services. Forwarding mechanisms and requirements of control plane and data models for tunnel segments are also defined. 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]. 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 October 16, 2021. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. Li, et al. Expires October 16, 2021 [Page 1] Internet-Draft Tunnel Segment in SR April 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Reducing SID Stack Depth . . . . . . . . . . . . . . . . 3 3.2. Passing through Non-SR Domain . . . . . . . . . . . . . . 4 3.3. Differentiated Services . . . . . . . . . . . . . . . . . 5 4. Comparison with Agency Segment . . . . . . . . . . . . . . . 6 5. Forwarding Mechanisms . . . . . . . . . . . . . . . . . . . . 6 6. Requirement of Control Plane and Yang Models . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Segment Routing (SR), introduced by [RFC8402], leverages the source routing paradigm. A packet can be steered through an ordered list of instructions, which are also called segments. The node segment, adjacency segment, etc. have been proposed for different usecases. This document introduces a new type of segment, Tunnel Segment, for the segment routing. Tunnel segment can be used to reduce SID stack depth of SR path, span the non-SR domain or provide differentiated services. Forwarding mechanisms and requirements of control plane and data models for tunnel segments are also defined. 2. Terminology o SID: Segment ID o SR: Segment Routing o SR Path: Segment Routing Path Li, et al. Expires October 16, 2021 [Page 2] Internet-Draft Tunnel Segment in SR April 2021 o SR-TE Path: Segment Routing Traffic Engineering Path o MSD: Maximally SID Depth The terms "Tunnel Segment" and "Tunnel SID" are the generic names for a segment attached to a specific tunnel. A tunnel segment can be used to steer traffic into the corresponding tunnel along the SR path. 3. Usecases 3.1. Reducing SID Stack Depth It is possible that a SR path has to take an explicit path with multiple hops instead of the shortest path for the purpose of traffic engineering. As a result, the ingress node has to push lots of segments to steer the packet, which could be a challenge for the forwarding plane, since the depth of this segment stack may be beyond the capability of their forwarding engines. The tunnel segment introduced in this document will be helpful to mitigate the pain in these scenarios. Taking Figure 1 below as an example, the SR-TE path is created from SR-Node-1(ingress) to SR-Node-2(egress). The original SID stack, {A, B, X, E, F, G, H, Y, J, K}, is too overwhelming for the path MSD. With help of the tunnel segment, the tunnel from Gateway-Node-1 to Gateway-Node-2 can be represented by a dedicated SID, saying Z. So the SR-TE path can be represented as {A, B, X, Z, J, K}. Comparing with the original SR-TE path, the SID stack depth is reduced. The SR-TE tunnel can be created through two ways: 1. Manually configure on ingress node (Gateway-Node-1) and designate the SID binding to it. This binding relationship needs to be propagated to PCE/controller or advertised to other nodes in the network. 2. With the knowledge of all MSD along the path, a PCE/controller can calculate SR-TE tunnels using for reduce SID stack depth and determine ingress/egress gateway nodes dynamically. Those SR-TE tunnels can be created through PCE initiated style. The corresponding tunnel segment and the binding relationship can be propagated to ingress nodes and other nodes if necessary. As shown in Figure 1, ingress (SR-Node-1) can receive update messages from PCE/controller about the binding relationship. And SR-Node-1 can calculate the SR-TE path with the SR-TE tunnel segment without the help of PCE/controller in a centralized manner. Li, et al. Expires October 16, 2021 [Page 3] Internet-Draft Tunnel Segment in SR April 2021 SID stack +------------+ {A, B, X, Z, J, K}| PCE/ | +--------------| Controller | | +------------+ | ^ Tunnel Binding | | SID (Z) | | .-----. | | ( ) V V .--( )--. +------+ +-------+ ( ) +-------+ +------+ | SR |_(...)_|Gateway|_( SR Network )_|Gateway|_(...)_ | SR | |Node 1| (...) |Node-1 | ( ================> ) |Node-2 | (...) |Node 2| +------+ +-------+ ( SR-TE Tunnel ) +-------+ +------+ '--( )--' ( ) '-----' {A,B} {X} {E, F, G, H} {Y} {J,K} Figure 1 Usecase for Reducing SID Stack Depth 3.2. Passing through Non-SR Domain The tunnel segment can also be used in those scenarios that traffic has to pass through non-SR domains. In another word, tunnel segment can be used to connect SR islands. As shown in Figure 2, traffic from SR-Node-1 to SR-Node-2 has to pass through a traditional IP/MPLS network. Usually a RSVP-TE tunnel or IP tunnel will be created between two gateway nodes. By allocating SID for this tunnel, saying Z, the SR path from SR-Node-1 to SR- Node-2 can be represented as {A, B, X, Z, J, K}. In this scenario, the RSVP-TE tunnel or IP tunnel can be involved into SR networks through two ways: 1. Manually configure on ingress node (Gateway-Node-1) and designate the SID binding to it. This binding relationship needs to be propagated to PCE/controller or advertised to other nodes in the network. 2. With the knowledge of topology of non-SR domain, a PCE/controller can calculate RSVP-TE tunnels or IP tunnels and determine ingress/egress gateway nodes dynamically. Those RSVP-TE tunnels or IP tunnels can be created through PCE initiated style. The Li, et al. Expires October 16, 2021 [Page 4] Internet-Draft Tunnel Segment in SR April 2021 corresponding tunnel segment and the binding relationship can be propagated to ingress nodes and other nodes if necessary. As shown in Figure 2, ingress (SR-Node-1) can receive update messages from PCE/controller about the binding relationship. And SR-Node-1 can calculate the SR-TE path which can pass through non-SR domain without the help of PCE/controller in a centralized manner. SID stack +------------+ {A, B, X, Z, J, K}| PCE/ | +--------------| Controller | | +------------+ | ^ Tunnel Binding | | SID (Z) | | .-----. | | ( ) V V .--( )--. +------+ +-------+ ( ) +-------+ +------+ | SR |_(...)_|Gateway|_( IP/MPLS Network )_|Gateway|_(...)_ | SR | |Node 1| (...) |Node-1 | ( ================> ) |Node-2 | (...) |Node 2| +------+ +-------+ (MPLS TE/IP Tunnel) +-------+ +------+ '--( )--' ( ) '-----' {A,B} {X} {E, F, G, H} {Y} {J,K} Figure 2 Usecase for Passing through Non-SR Domain 3.3. Differentiated Services It is necessary to create multiple tunnels between the same pair of gateway nodes to support different services, since different tunnels can have different attributes. As a result, different SIDs have to be assigned per tunnel. Then an End-to-End SR path can choose different SIDs at ingress according to the service requirement when passing through the network between gateway nodes. As depicted in Figure 3, two RSVP-TE tunnels, say RSVP-TE-tunnel1 and RSVP-TE-tunnel2, are created in MPLS network to provide different bandwidth guarantee services. And two SIDs, Z1 and Z2, are allocated and mapped to these two tunnels separately. These two SIDs can be utilized by a PCE/controller when defining the SR path at ingress. Since different traffic will transport through different tunnels, differentiated services can be guaranteed. Li, et al. Expires October 16, 2021 [Page 5] Internet-Draft Tunnel Segment in SR April 2021 SID stack {A, B, X, Z1, J, K}+------------+ {A, B, X, Z2, J, K}| PCE/ | +---------------| Controller | | +------------+ | ^ Tunnel Binding | | SID (Z) | | .-----. | | ( ) V V .--( )--. +------+ +-------+ (MPLS TE Tunnel 1 ) +-------+ +------+ | SR |_(...)_|Gateway|_( ================> )_|Gateway|_(...)_ | SR | |Node 1| (...) |Node-1 | ( ================> ) |Node-2 | (...) |Node 2| +------+ +-------+ (MPLS TE Tunnel 2 ) +-------+ +------+ '--( )--' ( ) '-----' {A,B} {X} {E, F, G, H} {Y} {J,K} Figure 3 Usecase for Differentiated Services 4. Comparison with Agency Segment As described in [RFC8402], a tunnel can be represented by an Adj-SID or as a Forwarding Adjacency. One obvious benefit of the method is to unify the process. But it may be necessary to differentiate a tunnel segment from other adjacency segment in some scenarios since there are more attributes attached to a tunnel. By introducing the tunnel segment, this document expects not only to inform the binding relationship between a tunnel and a SID but also to learn tunnel information as much as possible. For example, it will be helpful for SR-capable nodes to know the detail of an explicit path that passes through non-SR networks. In addition, one tunnel will need an IP address if handled as an adjacency (a borrowed IP address at least). While a tunnel binding to a Tunnel-SID does not have to contain an IP address, only an ingress node and an egress node is enough. 5. Forwarding Mechanisms In the gateway node, when received the packet with the tunnel segment SID as the topmost SID, it will use the forwarding mechanism shown in the following figure to steering the traffic to the corresponding tunnel. Li, et al. Expires October 16, 2021 [Page 6] Internet-Draft Tunnel Segment in SR April 2021 +--------+ +------------------------+ | SID |--->| Tunnel Forwarding Info | +--------+ +------------------------+ SID: Segment ID Figure 4 Forwarding Mechanisms for Tunnel Segment 6. Requirement of Control Plane and Yang Models According to the procedures of the above usecases, following requirements of control plane and Yang models for Tunnel Segment are proposed: o REQ 01: IGP extensions SHOULD be introduced to advertise the binding relationship between a SID/label and the corresponding tunnel. Attributes of the tunnel MAY be carried optionally. o REQ 02: BGP Link-State extension SHOULD be introduced to advertise the binding relationship between a label and the corresponding tunnel. Attributes of the tunnel MAY be carried optionally. o REQ 03: PCEP extensions SHOULD be introduced to advertise the binding relationship between a SID/label and the corresponding tunnel from a PCC to a PCE. Attributes of the tunnel MAY be carried optionally. o REQ 04: PCE SHOULD support initiated IP tunnel. o REQ 05: PCE SHOULD support to allocate SID/label for the corresponding tunnel dynamically. o REQ 06: PCEP extensions SHOULD be introduced to distribute the binding relationship between a SID/label and the corresponding tunnel from a PCE to a PCC. Attributes of the tunnel MAY be carried optionally. o REQ 07: An I2RS interface SHOULD be available for allocating SID/ label to the corresponding tunnel. And augmentation on segment routing YANG models SHOULD be introduced. 7. IANA Considerations This document makes no request of IANA. Li, et al. Expires October 16, 2021 [Page 7] Internet-Draft Tunnel Segment in SR April 2021 8. Security Considerations This document does not introduce new security threat. 9. References 9.1. Normative References [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . 9.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Authors' Addresses Zhenbin Li Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Cheng Li Huawei Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: c.l@huawei.com Nan Wu Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: eric.wu@huawei.com Li, et al. Expires October 16, 2021 [Page 8]