idnits 2.17.1 draft-li-spring-tunnel-segment-01.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 (March 13, 2016) is 2965 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-07 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 N. Wu 4 Intended status: Informational Huawei 5 Expires: September 14, 2016 March 13, 2016 7 Tunnel Segment in Segment Routing 8 draft-li-spring-tunnel-segment-01 10 Abstract 12 This document introduces a new type of segment, Tunnel Segment, for 13 the segment routing (SR). Tunnel segment can be used to reduce SID 14 stack depth of SR path, span the non-SR domain or provide 15 differentiated services. Forwarding mechanisms and requirements of 16 control plane and data models for tunnel segments are also defined. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 14, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 3. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Reducing SID Stack Depth . . . . . . . . . . . . . . . . 3 62 3.2. Passing through Non-SR Domain . . . . . . . . . . . . . . 4 63 3.3. Differentiated Services . . . . . . . . . . . . . . . . . 5 64 4. Comparison with Agency Segment . . . . . . . . . . . . . . . 6 65 5. Forwarding Mechanisms . . . . . . . . . . . . . . . . . . . . 6 66 6. Requirement of Control Plane and Yang Models . . . . . . . . 7 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 9.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Segment Routing (SR), introduced by 77 [I-D.ietf-spring-segment-routing], leverages the source routing 78 paradigm. A packet can be steered through an ordered list of 79 instructions, which are also called segments. The node segment, 80 adjacency segment, etc. have been proposed for different usecases. 82 This document introduces a new type of segment, Tunnel Segment, for 83 the segment routing. Tunnel segment can be used to reduce SID stack 84 depth of SR path, span the non-SR domain or provide differentiated 85 services. Forwarding mechanisms and requirements of control plane 86 and data models for tunnel segments are also defined. 88 2. Terminology 90 o SID: Segment ID 92 o SR: Segment Routing 94 o SR Path: Segment Routing Path 96 o SR-TE Path: Segment Routing Traffic Engineering Path 97 o MSD: Maximally SID Depth 99 The terms "Tunnel Segment" and "Tunnel SID" are the generic names for 100 a segment attached to a specific tunnel. A tunnel segment can be 101 used to steer traffic into the corresponding tunnel along the SR 102 path. 104 3. Usecases 106 3.1. Reducing SID Stack Depth 108 It is possible that a SR path has to take an explicit path with 109 multiple hops instead of the shortest path for the purpose of traffic 110 engineering. As a result, the ingress node has to push lots of 111 segments to steer the packet, which could be a challenge for the 112 forwarding plane, since the depth of this segment stack may be beyond 113 the capability of their forwarding engines. The tunnel segment 114 introduced in this document will be helpful to mitigate the pain in 115 these scenarios. 117 Taking Figure 1 below as an example, the SR-TE path is created from 118 SR-Node-1(ingress) to SR-Node-2(egress). The original SID stack, {A, 119 B, X, E, F, G, H, Y, J, K}, is too overwhelming for the path MSD. 120 With help of the tunnel segment, the tunnel from Gateway-Node-1 to 121 Gateway-Node-2 can be represented by a dedicated SID, saying Z. So 122 the SR-TE path can be represented as {A, B, X, Z, J, K}. Comparing 123 with the original SR-TE path, the SID stack depth is reduced. 125 The SR-TE tunnel can be created through two ways: 127 1. Manually configure on ingress node (Gateway-Node-1) and designate 128 the SID binding to it. This binding relationship needs to be 129 propagated to PCE/controller or advertised to other nodes in the 130 network. 132 2. With the knowledge of all MSD along the path, a PCE/controller 133 can calculate SR-TE tunnels using for reduce SID stack depth and 134 determine ingress/egress gateway nodes dynamically. Those SR-TE 135 tunnels can be created through PCE initiated style. The 136 corresponding tunnel segment and the binding relationship can be 137 propagated to ingress nodes and other nodes if necessary. As 138 shown in Figure 1, ingress (SR-Node-1) can receive update 139 messages from PCE/controller about the binding relationship. And 140 SR-Node-1 can calculate the SR-TE path with the SR-TE tunnel 141 segment without the help of PCE/controller in a centralized 142 manner. 144 SID stack +------------+ 145 {A, B, X, Z, J, K}| PCE/ | 146 +--------------| Controller | 147 | +------------+ 148 | ^ Tunnel Binding 149 | | SID (Z) 150 | | .-----. 151 | | ( ) 152 V V .--( )--. 153 +------+ +-------+ ( ) +-------+ +------+ 154 | SR |_(...)_|Gateway|_( SR Network )_|Gateway|_(...)_ | SR | 155 |Node 1| (...) |Node-1 | ( ================> ) |Node-2 | (...) |Node 2| 156 +------+ +-------+ ( SR-TE Tunnel ) +-------+ +------+ 157 '--( )--' 158 ( ) 159 '-----' 161 {A,B} {X} {E, F, G, H} {Y} {J,K} 163 Figure 1 Usecase for Reducing SID Stack Depth 165 3.2. Passing through Non-SR Domain 167 The tunnel segment can also be used in those scenarios that traffic 168 has to pass through non-SR domains. In another word, tunnel segment 169 can be used to connect SR islands. 171 As shown in Figure 2, traffic from SR-Node-1 to SR-Node-2 has to pass 172 through a traditional IP/MPLS network. Usually a RSVP-TE tunnel or 173 IP tunnel will be created between two gateway nodes. By allocating 174 SID for this tunnel, saying Z, the SR path from SR-Node-1 to SR- 175 Node-2 can be represented as {A, B, X, Z, J, K}. 177 In this scenario, the RSVP-TE tunnel or IP tunnel can be involved 178 into SR networks through two ways: 180 1. Manually configure on ingress node (Gateway-Node-1) and designate 181 the SID binding to it. This binding relationship needs to be 182 propagated to PCE/controller or advertised to other nodes in the 183 network. 185 2. With the knowledge of topology of non-SR domain, a PCE/controller 186 can calculate RSVP-TE tunnels or IP tunnels and determine 187 ingress/egress gateway nodes dynamically. Those RSVP-TE tunnels 188 or IP tunnels can be created through PCE initiated style. The 189 corresponding tunnel segment and the binding relationship can be 190 propagated to ingress nodes and other nodes if necessary. As 191 shown in Figure 2, ingress (SR-Node-1) can receive update 192 messages from PCE/controller about the binding relationship. And 193 SR-Node-1 can calculate the SR-TE path which can pass through 194 non-SR domain without the help of PCE/controller in a centralized 195 manner. 197 SID stack +------------+ 198 {A, B, X, Z, J, K}| PCE/ | 199 +--------------| Controller | 200 | +------------+ 201 | ^ Tunnel Binding 202 | | SID (Z) 203 | | .-----. 204 | | ( ) 205 V V .--( )--. 206 +------+ +-------+ ( ) +-------+ +------+ 207 | SR |_(...)_|Gateway|_( IP/MPLS Network )_|Gateway|_(...)_ | SR | 208 |Node 1| (...) |Node-1 | ( ================> ) |Node-2 | (...) |Node 2| 209 +------+ +-------+ (MPLS TE/IP Tunnel) +-------+ +------+ 210 '--( )--' 211 ( ) 212 '-----' 214 {A,B} {X} {E, F, G, H} {Y} {J,K} 216 Figure 2 Usecase for Passing through Non-SR Domain 218 3.3. Differentiated Services 220 It is necessary to create multiple tunnels between the same pair of 221 gateway nodes to support different services, since different tunnels 222 can have different attributes. As a result, different SIDs have to 223 be assigned per tunnel. Then an End-to-End SR path can choose 224 different SIDs at ingress according to the service requirement when 225 passing through the network between gateway nodes. 227 As depicted in Figure 3, two RSVP-TE tunnels, say RSVP-TE-tunnel1 and 228 RSVP-TE-tunnel2, are created in MPLS network to provide different 229 bandwidth guarantee services. And two SIDs, Z1 and Z2, are allocated 230 and mapped to these two tunnels separately. These two SIDs can be 231 utilized by a PCE/controller when defining the SR path at ingress. 232 Since different traffic will transport through different tunnels, 233 differentiated services can be guaranteed. 235 SID stack 236 {A, B, X, Z1, J, K}+------------+ 237 {A, B, X, Z2, J, K}| PCE/ | 238 +---------------| Controller | 239 | +------------+ 240 | ^ Tunnel Binding 241 | | SID (Z) 242 | | .-----. 243 | | ( ) 244 V V .--( )--. 245 +------+ +-------+ (MPLS TE Tunnel 1 ) +-------+ +------+ 246 | SR |_(...)_|Gateway|_( ================> )_|Gateway|_(...)_ | SR | 247 |Node 1| (...) |Node-1 | ( ================> ) |Node-2 | (...) |Node 2| 248 +------+ +-------+ (MPLS TE Tunnel 2 ) +-------+ +------+ 249 '--( )--' 250 ( ) 251 '-----' 253 {A,B} {X} {E, F, G, H} {Y} {J,K} 255 Figure 3 Usecase for Differentiated Services 257 4. Comparison with Agency Segment 259 As described in [I-D.ietf-spring-segment-routing], a tunnel can be 260 represented by an Adj-SID or as a Forwarding Adjacency. One obvious 261 benefit of the method is to unify the process. But it may be 262 necessary to differentiate a tunnel segment from other adjacency 263 segment in some scenarios since there are more attributes attached to 264 a tunnel. 266 By introducing the tunnel segment, this document expects not only to 267 inform the binding relationship between a tunnel and a SID but also 268 to learn tunnel information as much as possible. For example, it 269 will be helpful for SR-capable nodes to know the detail of an 270 explicit path that passes through non-SR networks. 272 In addition, one tunnel will need an IP address if handled as an 273 adjacency (a borrowed IP address at least). While a tunnel binding 274 to a Tunnel-SID does not have to contain an IP address, only an 275 ingress node and an egress node is enough. 277 5. Forwarding Mechanisms 279 In the gateway node, when received the packet with the tunnel segment 280 SID as the topmost SID, it will use the forwarding mechanism shown in 281 the following figure to steering the traffic to the corresponding 282 tunnel. 284 +--------+ +------------------------+ 285 | SID |--->| Tunnel Forwarding Info | 286 +--------+ +------------------------+ 288 SID: Segment ID 290 Figure 4 Forwarding Mechanisms for Tunnel Segment 292 6. Requirement of Control Plane and Yang Models 294 According to the procedures of the above usecases, following 295 requirements of control plane and Yang models for Tunnel Segment are 296 proposed: 298 o REQ 01: IGP extensions SHOULD be introduced to advertise the 299 binding relationship between a SID/label and the corresponding 300 tunnel. Attributes of the tunnel MAY be carried optionally. 302 o REQ 02: BGP Link-State extension SHOULD be introduced to advertise 303 the binding relationship between a label and the corresponding 304 tunnel. Attributes of the tunnel MAY be carried optionally. 306 o REQ 03: PCEP extensions SHOULD be introduced to advertise the 307 binding relationship between a SID/label and the corresponding 308 tunnel from a PCC to a PCE. Attributes of the tunnel MAY be 309 carried optionally. 311 o REQ 04: PCE SHOULD support initiated IP tunnel. 313 o REQ 05: PCE SHOULD support to allocate SID/label for the 314 corresponding tunnel dynamically. 316 o REQ 06: PCEP extensions SHOULD be introduced to distribute the 317 binding relationship between a SID/label and the corresponding 318 tunnel from a PCE to a PCC. Attributes of the tunnel MAY be 319 carried optionally. 321 o REQ 07: An I2RS interface SHOULD be available for allocating SID/ 322 label to the corresponding tunnel. And augmentation on segment 323 routing YANG models SHOULD be introduced. 325 7. IANA Considerations 327 This document makes no request of IANA. 329 8. Security Considerations 331 This document does not introduce new security threat. 333 9. References 335 9.1. Normative References 337 [I-D.ietf-spring-segment-routing] 338 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 339 and R. Shakir, "Segment Routing Architecture", draft-ietf- 340 spring-segment-routing-07 (work in progress), December 341 2015. 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 Nan Wu 361 Huawei 362 Huawei Bld., No.156 Beiqing Rd. 363 Beijing 100095 364 China 366 Email: eric.wu@huawei.com