idnits 2.17.1 draft-chen-spring-segment-list-id-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 : ---------------------------------------------------------------------------- ** There are 18 instances of too long lines in the document, the longest one being 23 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 12, 2015) is 3090 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) -- Looks like a reference, but probably isn't: '100' on line 173 -- Looks like a reference, but probably isn't: '200' on line 173 == Missing Reference: 'SL-SID' is mentioned on line 271, but not defined -- Looks like a reference, but probably isn't: '300' on line 366 -- Looks like a reference, but probably isn't: '103' on line 357 -- Looks like a reference, but probably isn't: '106' on line 366 -- Looks like a reference, but probably isn't: '102' on line 357 == Unused Reference: 'I-D.ietf-ospf-segment-routing-extensions' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-mpls' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'RFC3031' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'RFC3032' is defined on line 428, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-ospf-segment-routing-extensions-05 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-01 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group Ran. Chen 3 Internet-Draft Ting. Liao 4 Intended status: Standards Track ZTE Corporation 5 Expires: April 14, 2016 October 12, 2015 7 Spring Segment List ID 8 draft-chen-spring-segment-list-id-01 10 Abstract 12 Segment Routing allows a node to steer a packet through an ordered 13 list of instructions, called segments. The ingress node prepends a 14 SR header to a packet containing a set of "segments". A segment can 15 represent any instruction topological or service-based. 17 The Segment Routing architecture can be implemented using MPLS with 18 no change to the forwarding plane. A segment is encoded as an MPLS 19 label. An ordered list of segments is encoded as a stack of labels, 20 but it has implications on label stack depth. 22 This document describes how to decrease the depth of the label stack 23 in order to do effective Segment Routing operation. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 14, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions used in this document . . . . . . . . . . . . . . 3 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Solutions considered . . . . . . . . . . . . . . . . . . . . 3 63 4.1. Jointing method . . . . . . . . . . . . . . . . . . . . . 3 64 4.1.1. Forwarding Mechanisms . . . . . . . . . . . . . . . . 5 65 4.2. Translation segment list to label stack method . . . . . 5 66 4.2.1. Forwarding Mechanisms . . . . . . . . . . . . . . . . 8 67 5. Distribution of a binding Segment list ID for segment list 68 information using BGP-LS or PCEP . . . . . . . . . . . . . . 9 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 8.1. Normative references . . . . . . . . . . . . . . . . . . 10 73 8.2. Informative references . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 Segment Routing (SR), as described in Draft 79 [I-D.ietf-spring-segment-routing]allows a node to steer a packet 80 through an ordered list of instructions, called segments. This can 81 be directly applied to the MPLS with no change on the forwarding 82 plane. A segment is encoded as an MPLS label. An ordered list of 83 segments is encoded as a stack of labels, but it has implications on 84 label stack depth. 86 There may be many specified nodes or links included in the path based 87 on policy, and this will greatly increase the stack depth. If the 88 label stack depth exceeds the LSR label stack processing 89 capabilities, the hardware should be upgrade to support a deeper 90 label stack capability. 92 This document describes how to decrease the depth of the label stack 93 in order to do effective Segment Routing operation. It does not need 94 to upgrade the hardware. 96 2. Conventions used in this document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC2119. 102 3. Terminology 104 SR:Segment Routing 106 SID:Segment Identifier 108 SLID: Segment List Identifier, a segment list is identified by a 109 Segment list ID (SLID). 111 SRLD:specific Readable Label Depth 113 4. Solutions considered 115 There are two solutions described in the draft, both of them do not 116 need to upgrade the hardware. 118 In this document, we define the Segment List Identifier (SLID). The 119 segment list is identified by a Segment list ID (SLID). 121 Segment list ID (SLID) is allocated by the controller. The segment 122 list and the SLID can be advertised to the related nodes. The 123 related nodes would be the jointing nodes, or all the segment nodes 124 that contained in the segment list, or only be advertised to the 125 ingress node. 127 o In the first case, the jointing nodes need to maintain the MPLS 128 forwarding entry for the SLID. 130 o In the second case, each segment node needs to maintain the MPLS 131 forwarding entry for the SLID. 133 o In the last case, the ingress node floods the SLID via the IGP to 134 all the SR nodes in the SR domain and the SR node should maintain 135 the SR list and the SLID mapping. Each segment nodes that 136 contained in the segment list would maintain the MPLS forwarding 137 entry for the SLID. 139 4.1. Jointing method 141 The jointing method is based on the stack processing capability of 142 each node. The controller should have the capability to acquire the 143 stack processing capability of each node. It may be analyzed from 144 the chip's version or from the node advertising. 146 In the proposed mechanism, an unused ID from the SRGB is allocated by 147 the controller to identify the segment list which is out of the stack 148 processing capability. 150 +----------------------+ 151 /- _| Controller | _ 152 / / +----------------------+_ \ 153 / / | | | | | \ \ \ 154 / / | | | | | \ \ \ 155 +---+ / +---+ | | +---+ | +---+ \ \+---+ 156 -------- |R1 |---/---|R3 |--|---|--|R5 |---|-|R7 |---\-- |R9 | 157 +---+ / +---+ | | +---+ | +---+ \ +---+ 158 | / | / \ | \ | \ | 159 | / | / \ | \ | \ | 160 +---+ +---+ +---+ +---+ +---+ 161 |R2 |-------|R4 |--------|R6 |-----|R8 |-------|R10|----------- 162 +---+ +---+ +---+ +---+ +---+ 164 Figure 1 166 In this example, we assumes that: 168 o Each node's chip version is the same, and the stack processing 169 capability is 5. 171 o All nodes are SR capable. 173 o All SR nodes have the same SRGB consisting of: [100, 200] 175 o The operator (likely via the SDN Controller) as provisioned the 176 Node-SIDs 101, 102, 103, 104, 105, 106, 107, 108, 109,and 110 177 respectively at nodes R1, R2, R3, R4, R5, R6, R7, R8, R9 and R10. 179 o The controller computes a list for: {R1, R2, R4, R3, R5, R6, R8, 180 R7, R9, and R10}, and allocates an unused ID 100 to identify the 181 segment list. 183 o The controller advertises the binding Segment list ID (SLID) 100 184 for segment list {R1, R2, R4, R3, R5, R6, R8, R7, R9, and R10} to 185 the jointing nodes R1 and R5, or advertises the binding Segment 186 list ID (SLID) 100 for partitioned segment list {R1, R2, R4, R3, 187 and R5} to the jointing nodes R1 and Segment list ID (SLID) 100 188 for partitioned segment list {R6, R8, R7, R9, and R10} to R5. 190 4.1.1. Forwarding Mechanisms 192 Node R1 maintains the following LIB entry: 193 Incoming Label: NULL 194 Label Operation: PUSH 195 Outgoing Label: {102,104,103,105,100} 196 Outgoing interface: port to R2 198 Node R5 maintains the following LIB entry: 199 Incoming Label: 105 &100 200 Ingress Operation: POP and PUSH 201 Outgoing Label: {106,108,107,109,110} 202 Outgoing interface: R6 204 Node R10 maintains the following LIB entry: 205 Incoming Label: 110 206 Ingress Operation: POP 207 Outgoing Label: NULL 208 Outgoing interface: NULL 210 Other nodes are simple as following (i.e.R7): 211 Incoming Label: 107&109 212 Ingress Operation: POP and SWAP 213 Outgoing Label: 109 214 Outgoing interface: port to R9 216 The following shows the progression of the packet as it enters and 217 leaves the SR domain when the SLID is used. 219 R1 encapsulates the SR header list{102,104,103,105,100}. R5 receives 220 the packet, and converts 100 to the following list 221 sequence{106,108,107,109,110}.R5 refreshs the SR header 222 list{106,108,107,109,110}, and then the packet is transited to 223 R6-R8-R7-R9-R10. 225 4.2. Translation segment list to label stack method 227 In this proposed mechanism, Segment list ID (SLID) is allocated by 228 the controller. The segment list and the SLID can be advertised to 229 all the segment nodes that contained in the segment list, or only be 230 advertised to the ingress node. 232 A node N (Not the last segment node) maintains the following LIB entry: 233 Incoming Active Segment: SRGB_Node_N[SL-SID] 234 Label Operation: SWAP and PUSH (i.e. SWAP with SRGB_Node_N+1[SL-SID] 235 and PUSH the outer-label destination to next segment 236 Node_N+1) 237 Outgoing interface: the interface towards the next-hop along the 238 shortest-path to Node_N+1 240 Especially, if next segment is not a node segment but an adjacency 241 segment, the label operation would only be SWAP (i.e. SWAP with 242 SRGB_Node_N+1[SL-SID], Node_N+1 is adjacency to Node_N.), and 243 outgoing interface is determined by the adjacency. 245 The last segment node M maintains the following LIB entry: 246 Incoming Active Segment: SRGB_Node_M[SL-SID] 247 Label Operation: POP 248 Outgoing interface: NULL 250 Entire outgoing label stack of the packet in Node N from outer to 251 inner is as follows: 253 +-----------------------------------+ 254 | SRGB_nexthop[Node_N+1-SID] | 255 +-----------------------------------+ 256 | SRGB_Node_N+1[SL-SID] | 257 +-----------------------------------+ 259 Entire outgoing label stack in ingress node from outer to inner is as 260 follows: 262 +-----------------------------------+ 263 | SRGB_nexthop[Node_ 1-SID] | 264 +-----------------------------------+ 265 | SRGB_Node_1 [SL-SID] | 266 +-----------------------------------+ 268 Note:Node 1 is the first node segment. 270 Especially, if the first segment is not a node segment but an 271 adjacency segment, the label stack would only be SRGB_Node_1 [SL- 272 SID]. Node_1 is adjacency to ingress node. 274 Then, any length of the segment list can be encoded as two-level 275 label stacks. 277 Let us analyze the following example: 279 +----------------------+ 280 /- _| Controller | _ 281 / / +----------------------+_ \ 282 / / | | \ \ 283 / / | | \ \ 284 +---+ / +---+ | +---+ +---+ \ \+---+ 285 -------- |R0 |---/---|A1 |-----|--|R1 |-----|A2 |---\-- |R2 | 286 +---+ / +---+ | +---+ +---+ \ +---+ 287 | / \ | \ | 288 | / \ | \ | 289 +---+ +---+ +---+ 290 |R3 |--------------------|R4 |-----------------|R5 |----------- 291 +---+ +---+ +---+ 293 Figure 2 295 An SDN Controller (SC) is connected to the network and is able to 296 retrieve the topology and traffic information. 298 We assume that: 300 o The operator (likely via the SDN Controller) as provisioned the 301 Node-SIDs 101, 102, 103, 104, 105,and 106 respectively at nodes 302 R0, R1, R2, R3, R4 and R5. 304 o The controller can steer the traffic from R0 to R5 an explicit 305 path R1R2R5. The controller allocates a binding Segment list ID 306 (SLID) 300 for segment list {R1, R2, and R5}. 308 o The controller advertises the binding Segment list ID (SLID) 300 309 for segment list {R1, R2, and R5} to all the segment nodes (i.e. 310 R1, R2, and R5) that contained in the segment list. Those 311 extensions would be described in section 5. 313 o In this example, all nodes are SR capable, including A1/A2/A3. 315 o Each SR node may have a different SRGB. 317 o The next-hop along the shortest-path from R0 to R1 is A1. A1 can 318 also be LDP/ RSVP-TE/BGP capable (optional). The next-hop along 319 the shortest-path from R1 to R2 is A2. A2 is either an SR node or 320 LDP/RSVP-TE/BGP node. The next-hop along the shortest-path from 321 R2 to R5 is A3. A3 is either an SR node or LDP/RSVP-TE/BGP node. 323 o Any length of the segment list is encoded as two-level label 324 stacks. 326 4.2.1. Forwarding Mechanisms 328 Then, Node R1 maintains the following LIB entry: 329 Incoming Label: SRGB_R1 [300] 330 Label Operation: SWAP and PUSH 331 Outgoing Label: SRGB_R2 [300], SRGB_A2[103] 332 Outgoing interface: port to A2 334 Node R2 maintains the following LIB entry: 335 Incoming Label: SRGB_R2[300] 336 Label Operation: SWAP and PUSH 337 Outgoing Label: SRGB_R5 [300], SRGB_A3[106] 338 Outgoing interface: port to A2 340 or simple as following (because R2 knows it is the penultimate segment of the segment list): 341 Incoming Label: SRGB_R2 [300] 342 Ingress Operation: SWAP 343 Outgoing Label: SRGB_A 3[106] 344 Outgoing interface: port to A3 346 Node R5 maintains the following LIB entry: 347 Incoming Label: SRGB_R5 [106] 348 Ingress Operation: POP 349 Outgoing Label: NULL 350 Outgoing interface: NULL 352 The following shows the progression of the packet as it enters and 353 leaves the SR domain when the SLID is used. 355 Packets sent by ingress R0 Packets sent by A1 Packets sent by R1 356 +---------------+ +----------------+ 357 | SRGB_A1[102] | | SRGB_A2[103] | 358 +---------------+ +----------------+ +----------------+ 359 | SRGB_R1[300] |------> | SRGB_R1[300] |------> | SRGB_R2[300] |-------> 360 ++=============++ ++==============++ ++==============++ 361 || Packet || || Packet || || Packet || 362 ++=============++ ++==============++ ++==============++ 364 Packets sent by A2 Packets sent by R2 Packets sent by A3 365 +---------------+ +----------------+ +----------------+ 366 | SRGB_R2[300] |------> | SRGB_A3[106] |------> | SRGB_R5[106] | 367 ++=============++ ++==============++ ++==============++-------> 368 || Packet || || Packet || || Packet || 369 ++=============++ ++==============++ ++==============++ 371 Packets sent by R5 372 ++=============++ 373 || Packet || 374 ++=============++ 376 As an optional solution, the ingress node can also encode the label 377 stack according to the global specific Readable label depth (SRLD). 378 Also, the LIB entry (for SL-SID) in each segment node can swap the 379 label stack according to SRLD. This option will be specified in a 380 future version. The global SRLD can be configured, or it can be 381 minimum Readable label depth of all the SR nodes. The RLD has been 382 specified in [I-D.kini-mpls-spring-entropy-label]. 384 The minimum Readable label depth of all the SR nodes can be learned 385 via protocols. 387 5. Distribution of a binding Segment list ID for segment list 388 information using BGP-LS or PCEP 390 TBD. 392 6. IANA Considerations 394 TBD. 396 7. Security Considerations 398 TBD. 400 8. References 402 8.1. Normative references 404 [I-D.ietf-ospf-segment-routing-extensions] 405 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 406 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 407 Extensions for Segment Routing", draft-ietf-ospf-segment- 408 routing-extensions-05 (work in progress), June 2015. 410 [I-D.ietf-spring-segment-routing] 411 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 412 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 413 ietf-spring-segment-routing-05 (work in progress), 414 September 2015. 416 [I-D.ietf-spring-segment-routing-mpls] 417 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 418 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 419 and E. Crabbe, "Segment Routing with MPLS data plane", 420 draft-ietf-spring-segment-routing-mpls-01 (work in 421 progress), May 2015. 423 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 424 Label Switching Architecture", RFC 3031, 425 DOI 10.17487/RFC3031, January 2001, 426 . 428 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 429 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 430 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 431 . 433 8.2. Informative references 435 [I-D.kini-mpls-spring-entropy-label] 436 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 437 Shakir, R., Xu, X., Henderickx, W., and J. Tantsura, 438 "Entropy labels for source routed stacked tunnels", draft- 439 kini-mpls-spring-entropy-label-03 (work in progress), 440 March 2015. 442 Authors' Addresses 443 Ran Chen 444 ZTE Corporation 445 No.50 Software Avenue,Yuhuatai District 446 Nanjing, Jiangsu Province 210012 447 China 449 Phone: +86 025 88014636 450 Email: chen.ran@zte.com.cn 452 Ting Liao 453 ZTE Corporation 454 No.50 Software Avenue,Yuhuatai District 455 Nanjing, Jiangsu Province 210012 456 China 458 Email: liao.ting@zte.com.cn