idnits 2.17.1 draft-li-spring-tunnel-segment-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 14, 2021) is 1107 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft C. Li 4 Intended status: Standards Track N. Wu 5 Expires: October 16, 2021 Huawei 6 April 14, 2021 8 Tunnel Segment in Segment Routing 9 draft-li-spring-tunnel-segment-02 11 Abstract 13 This document introduces a new type of segment, Tunnel Segment, for 14 the segment routing (SR). Tunnel segment can be used to reduce SID 15 stack depth of SR path, span the non-SR domain or provide 16 differentiated services. 18 Forwarding mechanisms and requirements of control plane and data 19 models for tunnel segments are also defined. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on October 16, 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 3. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. Reducing SID Stack Depth . . . . . . . . . . . . . . . . 3 65 3.2. Passing through Non-SR Domain . . . . . . . . . . . . . . 4 66 3.3. Differentiated Services . . . . . . . . . . . . . . . . . 5 67 4. Comparison with Agency Segment . . . . . . . . . . . . . . . 6 68 5. Forwarding Mechanisms . . . . . . . . . . . . . . . . . . . . 6 69 6. Requirement of Control Plane and Yang Models . . . . . . . . 7 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 9.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 Segment Routing (SR), introduced by [RFC8402], leverages the source 80 routing paradigm. A packet can be steered through an ordered list of 81 instructions, which are also called segments. The node segment, 82 adjacency segment, etc. have been proposed for different usecases. 84 This document introduces a new type of segment, Tunnel Segment, for 85 the segment routing. Tunnel segment can be used to reduce SID stack 86 depth of SR path, span the non-SR domain or provide differentiated 87 services. Forwarding mechanisms and requirements of control plane 88 and data models for tunnel segments are also defined. 90 2. Terminology 92 o SID: Segment ID 94 o SR: Segment Routing 96 o SR Path: Segment Routing Path 97 o SR-TE Path: Segment Routing Traffic Engineering Path 99 o MSD: Maximally SID Depth 101 The terms "Tunnel Segment" and "Tunnel SID" are the generic names for 102 a segment attached to a specific tunnel. A tunnel segment can be 103 used to steer traffic into the corresponding tunnel along the SR 104 path. 106 3. Usecases 108 3.1. Reducing SID Stack Depth 110 It is possible that a SR path has to take an explicit path with 111 multiple hops instead of the shortest path for the purpose of traffic 112 engineering. As a result, the ingress node has to push lots of 113 segments to steer the packet, which could be a challenge for the 114 forwarding plane, since the depth of this segment stack may be beyond 115 the capability of their forwarding engines. The tunnel segment 116 introduced in this document will be helpful to mitigate the pain in 117 these scenarios. 119 Taking Figure 1 below as an example, the SR-TE path is created from 120 SR-Node-1(ingress) to SR-Node-2(egress). The original SID stack, {A, 121 B, X, E, F, G, H, Y, J, K}, is too overwhelming for the path MSD. 122 With help of the tunnel segment, the tunnel from Gateway-Node-1 to 123 Gateway-Node-2 can be represented by a dedicated SID, saying Z. So 124 the SR-TE path can be represented as {A, B, X, Z, J, K}. Comparing 125 with the original SR-TE path, the SID stack depth is reduced. 127 The SR-TE tunnel can be created through two ways: 129 1. Manually configure on ingress node (Gateway-Node-1) and designate 130 the SID binding to it. This binding relationship needs to be 131 propagated to PCE/controller or advertised to other nodes in the 132 network. 134 2. With the knowledge of all MSD along the path, a PCE/controller 135 can calculate SR-TE tunnels using for reduce SID stack depth and 136 determine ingress/egress gateway nodes dynamically. Those SR-TE 137 tunnels can be created through PCE initiated style. The 138 corresponding tunnel segment and the binding relationship can be 139 propagated to ingress nodes and other nodes if necessary. As 140 shown in Figure 1, ingress (SR-Node-1) can receive update 141 messages from PCE/controller about the binding relationship. And 142 SR-Node-1 can calculate the SR-TE path with the SR-TE tunnel 143 segment without the help of PCE/controller in a centralized 144 manner. 146 SID stack +------------+ 147 {A, B, X, Z, J, K}| PCE/ | 148 +--------------| Controller | 149 | +------------+ 150 | ^ Tunnel Binding 151 | | SID (Z) 152 | | .-----. 153 | | ( ) 154 V V .--( )--. 155 +------+ +-------+ ( ) +-------+ +------+ 156 | SR |_(...)_|Gateway|_( SR Network )_|Gateway|_(...)_ | SR | 157 |Node 1| (...) |Node-1 | ( ================> ) |Node-2 | (...) |Node 2| 158 +------+ +-------+ ( SR-TE Tunnel ) +-------+ +------+ 159 '--( )--' 160 ( ) 161 '-----' 163 {A,B} {X} {E, F, G, H} {Y} {J,K} 165 Figure 1 Usecase for Reducing SID Stack Depth 167 3.2. Passing through Non-SR Domain 169 The tunnel segment can also be used in those scenarios that traffic 170 has to pass through non-SR domains. In another word, tunnel segment 171 can be used to connect SR islands. 173 As shown in Figure 2, traffic from SR-Node-1 to SR-Node-2 has to pass 174 through a traditional IP/MPLS network. Usually a RSVP-TE tunnel or 175 IP tunnel will be created between two gateway nodes. By allocating 176 SID for this tunnel, saying Z, the SR path from SR-Node-1 to SR- 177 Node-2 can be represented as {A, B, X, Z, J, K}. 179 In this scenario, the RSVP-TE tunnel or IP tunnel can be involved 180 into SR networks through two ways: 182 1. Manually configure on ingress node (Gateway-Node-1) and designate 183 the SID binding to it. This binding relationship needs to be 184 propagated to PCE/controller or advertised to other nodes in the 185 network. 187 2. With the knowledge of topology of non-SR domain, a PCE/controller 188 can calculate RSVP-TE tunnels or IP tunnels and determine 189 ingress/egress gateway nodes dynamically. Those RSVP-TE tunnels 190 or IP tunnels can be created through PCE initiated style. The 191 corresponding tunnel segment and the binding relationship can be 192 propagated to ingress nodes and other nodes if necessary. As 193 shown in Figure 2, ingress (SR-Node-1) can receive update 194 messages from PCE/controller about the binding relationship. And 195 SR-Node-1 can calculate the SR-TE path which can pass through 196 non-SR domain without the help of PCE/controller in a centralized 197 manner. 199 SID stack +------------+ 200 {A, B, X, Z, J, K}| PCE/ | 201 +--------------| Controller | 202 | +------------+ 203 | ^ Tunnel Binding 204 | | SID (Z) 205 | | .-----. 206 | | ( ) 207 V V .--( )--. 208 +------+ +-------+ ( ) +-------+ +------+ 209 | SR |_(...)_|Gateway|_( IP/MPLS Network )_|Gateway|_(...)_ | SR | 210 |Node 1| (...) |Node-1 | ( ================> ) |Node-2 | (...) |Node 2| 211 +------+ +-------+ (MPLS TE/IP Tunnel) +-------+ +------+ 212 '--( )--' 213 ( ) 214 '-----' 216 {A,B} {X} {E, F, G, H} {Y} {J,K} 218 Figure 2 Usecase for Passing through Non-SR Domain 220 3.3. Differentiated Services 222 It is necessary to create multiple tunnels between the same pair of 223 gateway nodes to support different services, since different tunnels 224 can have different attributes. As a result, different SIDs have to 225 be assigned per tunnel. Then an End-to-End SR path can choose 226 different SIDs at ingress according to the service requirement when 227 passing through the network between gateway nodes. 229 As depicted in Figure 3, two RSVP-TE tunnels, say RSVP-TE-tunnel1 and 230 RSVP-TE-tunnel2, are created in MPLS network to provide different 231 bandwidth guarantee services. And two SIDs, Z1 and Z2, are allocated 232 and mapped to these two tunnels separately. These two SIDs can be 233 utilized by a PCE/controller when defining the SR path at ingress. 234 Since different traffic will transport through different tunnels, 235 differentiated services can be guaranteed. 237 SID stack 238 {A, B, X, Z1, J, K}+------------+ 239 {A, B, X, Z2, J, K}| PCE/ | 240 +---------------| Controller | 241 | +------------+ 242 | ^ Tunnel Binding 243 | | SID (Z) 244 | | .-----. 245 | | ( ) 246 V V .--( )--. 247 +------+ +-------+ (MPLS TE Tunnel 1 ) +-------+ +------+ 248 | SR |_(...)_|Gateway|_( ================> )_|Gateway|_(...)_ | SR | 249 |Node 1| (...) |Node-1 | ( ================> ) |Node-2 | (...) |Node 2| 250 +------+ +-------+ (MPLS TE Tunnel 2 ) +-------+ +------+ 251 '--( )--' 252 ( ) 253 '-----' 255 {A,B} {X} {E, F, G, H} {Y} {J,K} 257 Figure 3 Usecase for Differentiated Services 259 4. Comparison with Agency Segment 261 As described in [RFC8402], a tunnel can be represented by an Adj-SID 262 or as a Forwarding Adjacency. One obvious benefit of the method is 263 to unify the process. But it may be necessary to differentiate a 264 tunnel segment from other adjacency segment in some scenarios since 265 there are more attributes attached to a tunnel. 267 By introducing the tunnel segment, this document expects not only to 268 inform the binding relationship between a tunnel and a SID but also 269 to learn tunnel information as much as possible. For example, it 270 will be helpful for SR-capable nodes to know the detail of an 271 explicit path that passes through non-SR networks. 273 In addition, one tunnel will need an IP address if handled as an 274 adjacency (a borrowed IP address at least). While a tunnel binding 275 to a Tunnel-SID does not have to contain an IP address, only an 276 ingress node and an egress node is enough. 278 5. Forwarding Mechanisms 280 In the gateway node, when received the packet with the tunnel segment 281 SID as the topmost SID, it will use the forwarding mechanism shown in 282 the following figure to steering the traffic to the corresponding 283 tunnel. 285 +--------+ +------------------------+ 286 | SID |--->| Tunnel Forwarding Info | 287 +--------+ +------------------------+ 289 SID: Segment ID 291 Figure 4 Forwarding Mechanisms for Tunnel Segment 293 6. Requirement of Control Plane and Yang Models 295 According to the procedures of the above usecases, following 296 requirements of control plane and Yang models for Tunnel Segment are 297 proposed: 299 o REQ 01: IGP extensions SHOULD be introduced to advertise the 300 binding relationship between a SID/label and the corresponding 301 tunnel. Attributes of the tunnel MAY be carried optionally. 303 o REQ 02: BGP Link-State extension SHOULD be introduced to advertise 304 the binding relationship between a label and the corresponding 305 tunnel. Attributes of the tunnel MAY be carried optionally. 307 o REQ 03: PCEP extensions SHOULD be introduced to advertise the 308 binding relationship between a SID/label and the corresponding 309 tunnel from a PCC to a PCE. Attributes of the tunnel MAY be 310 carried optionally. 312 o REQ 04: PCE SHOULD support initiated IP tunnel. 314 o REQ 05: PCE SHOULD support to allocate SID/label for the 315 corresponding tunnel dynamically. 317 o REQ 06: PCEP extensions SHOULD be introduced to distribute the 318 binding relationship between a SID/label and the corresponding 319 tunnel from a PCE to a PCC. Attributes of the tunnel MAY be 320 carried optionally. 322 o REQ 07: An I2RS interface SHOULD be available for allocating SID/ 323 label to the corresponding tunnel. And augmentation on segment 324 routing YANG models SHOULD be introduced. 326 7. IANA Considerations 328 This document makes no request of IANA. 330 8. Security Considerations 332 This document does not introduce new security threat. 334 9. References 336 9.1. Normative References 338 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 339 Decraene, B., Litkowski, S., and R. Shakir, "Segment 340 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 341 July 2018, . 343 9.2. Informative References 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, 347 DOI 10.17487/RFC2119, March 1997, 348 . 350 Authors' Addresses 352 Zhenbin Li 353 Huawei 354 Huawei Bld., No.156 Beiqing Rd. 355 Beijing 100095 356 China 358 Email: lizhenbin@huawei.com 360 Cheng Li 361 Huawei 362 Huawei Campus, No. 156 Beiqing Rd. 363 Beijing 100095 364 China 366 Email: c.l@huawei.com 368 Nan Wu 369 Huawei 370 Huawei Bld., No.156 Beiqing Rd. 371 Beijing 100095 372 China 374 Email: eric.wu@huawei.com