idnits 2.17.1 draft-ietf-spring-mpls-path-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 16, 2019) is 1683 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) == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 406, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-22 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 == Outdated reference: A later version (-07) exists of draft-li-pce-sr-bidir-path-06 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Cheng 3 Internet-Draft H. Li 4 Intended status: Standards Track China Mobile 5 Expires: March 19, 2020 M. Chen 6 Huawei 7 R. Gandhi 8 Cisco Systems, Inc. 9 R. Zigler 10 Broadcom 11 September 16, 2019 13 Path Segment in MPLS Based Segment Routing Network 14 draft-ietf-spring-mpls-path-segment-01 16 Abstract 18 A Segment Routing (SR) path is identified by an SR segment list. 19 Only the full segment list identifies the full end-to-end path, and 20 one segment or a partial set of segments from the list cannot 21 identify the SR path and distinguish it from other SR paths that may 22 be partially congruent. But path identification is a pre-requisite 23 for various use-cases such as performance measurement (PM) of an SR 24 path. 26 In SR for MPLS (SR-MPLS) the segment identifiers are stripped from 27 the packet through label popping as the packet transits the network. 28 This means that when a packet reaches the egress of the SR path, it 29 is not possible to determine on which SR path it traversed the 30 network. 32 This document defines a new type of segment that is referred to as 33 Path Segment, which is used to identify an SR path in an SR-MPLS 34 network. When used, it is inserted at the ingress node of the SR 35 path and immediately follows the last segment identifier in the 36 segment list of the SR path. The Path Segment will not be popped off 37 until it reaches the egress node of the SR path. 39 A Path Segment can be used by the egress node to implement path 40 identification hence to support various use-cases including SR path 41 PM, end-to-end 1+1 SR path protection, and bidirectional SR paths 42 correlation. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on March 19, 2020. 61 Copyright Notice 63 Copyright (c) 2019 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (https://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 80 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 81 2. Path Segment . . . . . . . . . . . . . . . . . . . . . . . . 4 82 3. Nesting of Path Segments . . . . . . . . . . . . . . . . . . 5 83 4. Path Segment Allocation . . . . . . . . . . . . . . . . . . . 6 84 5. Path Segment for PM . . . . . . . . . . . . . . . . . . . . . 7 85 6. Path Segment for Bi-directional SR Path . . . . . . . . . . . 7 86 7. Path Segment for End-to-end Path Protection . . . . . . . . . 7 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 88 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 89 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 90 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 93 12.2. Informative References . . . . . . . . . . . . . . . . . 9 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 96 1. Introduction 98 Segment Routing (SR) [RFC8402] is a source routed forwarding method 99 that allows to directly encode forwarding instructions (called 100 segments) in each packet, hence it enables steering traffic through a 101 network without the per-flow states maintained on the transit nodes. 102 Segment Routing can be instantiated on an MPLS data plane or an IPv6 103 data plane. The former is called SR-MPLS 104 [I-D.ietf-spring-segment-routing-mpls], the latter is called SRv6 105 [RFC8402]. SR-MPLS leverages the MPLS label stack to construct SR 106 paths. 108 In an SR-MPLS network, when a packet is transmitted along an SR path, 109 the labels in the MPLS label stack will be swapped or popped. So 110 that no label or only the last label may be left in the MPLS label 111 stack when the packet reaches the egress node. Thus, the egress node 112 cannot determine along which SR path the packet came. 114 However, to support use cases like end-to-end 1+1 path protection 115 (Live-Live case), bidirectional path correlation or performance 116 measurement (PM), the ability to implement path identification is a 117 pre-requisite. More detail can be found in Section 5, 6, and 7. 119 Therefore, this document introduces a new segment that is referred to 120 as the Path Segment. A Path Segment is defined to uniquely identify 121 an SR path in an SR-MPLS network in the context of the egress node. 122 It is normally used by egress nodes for path identification or 123 correlation. 125 1.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in 130 BCP14 [RFC2119][RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 1.2. Abbreviations 135 DM: Delay Measurement. 137 LM: Loss Measurement. 139 MPLS: Multiprotocol Label Switching. 141 PM: Performance Measurement. 143 PSID: Path Segment ID. 145 SID: Segment ID. 147 SL: Segment List. 149 SR: Segment Routing. 151 SR-MPLS: Segment Routing instantiated on MPLS data plane. 153 SRv6: Segment Routing instantiated on IPv6 data plane 155 2. Path Segment 157 A Path Segment is a single label that is assigned from the Segment 158 Routing Local Block (SRLB) or Segment Routing Global Block (SRGB) of 159 the egress node of an SR path. It means that the Path Segment is 160 unique in the context of the egress node of the SR path. When a Path 161 Segment is used, the Path Segment MUST be inserted at the ingress 162 node and MUST immediately follow the last label of the SR path. The 163 Path Segment may be used to identify an SR-MPLS Policy, its 164 Candidate-Path (CP), or a SID List (SL) 165 [I-D.ietf-spring-segment-routing-policy] terminating on an egress 166 node depending on the use-case. 168 The value of the TTL field in the MPLS label stack entry containing 169 the Path Segment MUST be set to the same value as the TTL of the last 170 label stack entry for the last segment in the SR path. If the Path 171 Segment is the bottom label, the S bit MUST be set. 173 Normally, the intermediate nodes will not see the Path Segment label 174 and do not know how to process it. A Path Segment presenting to an 175 intermediate node is an error condition. 177 The egress node MUST pop the Path Segment. The egress node MAY use 178 the Path Segment for further processing. For example, when 179 performance measurement is enabled on the SR path, it can trigger 180 packet counting or timestamping. 182 The label stack with Path Segment is as below (Figure 1): 184 +--------------------+ 185 | ... | 186 +--------------------+ 187 | Label 1 | 188 +--------------------+ 189 | Label 2 | 190 +--------------------+ 191 | ... | 192 +--------------------+ 193 | Label n | 194 +--------------------+ 195 | Path Segment | 196 +--------------------+ 197 | ... | 198 +--------------------+ 200 Figure 1: Label Stack with Path Segment 202 Where: 204 o The Labels 1 to n are the segment label stack used to direct how 205 to steer the packets along the SR path. 207 o The Path Segment identifies the SR path in the context of the 208 egress node of the SR path. 210 3. Nesting of Path Segments 212 Binding SID (BSID) [RFC8402] can be used for SID list compression. 213 With BSID, an end-to-end SR path can be split into several sub-paths, 214 each sub-path is identified by a BSID. Then an end-to-end SR path 215 can be identified by a list of BSIDs, therefore, it can provide 216 better scalability. 218 BSID and Path SID (PSID) can be combined to achieve both sub-path and 219 end-to-end path monitoring. A reference model for such a combination 220 in (Figure 2) shows an end-to-end path (A->D) that spans three 221 domains (Access, Aggregation and Core domain) and consists of three 222 sub-paths, one in each sub-domain (sub-path (A->B), sub-path (B->C) 223 and sub-path (C->D)). Each sub-path is allocated a BSID. For 224 nesting the sub-paths, each sub-path is allocated a PSID. Then, the 225 SID list of the end-to-end path can be expressed as , where the e-PSID is the PSID of the end-to-end 227 path. The SID list of a sub-path can be expressed as , where the s-PSID is the PSID of the sub-path. 230 Figure 2 shows the details of the label stacks when PSID and BSID are 231 used to support both sub-path and end-to-end path monitoring in a 232 multi-domain scenario. 234 /--------\ /--------\ /--------\ 235 / \ / \ / \ 236 A{ Access }B{ Aggregation }C{ Core }D 237 \ / \ / \ / 238 \--------/ \--------/ \--------/ 239 Sub-path(A->B) Sub-path(B->C) Sub-path(C->D) 240 |<--------------->|<-------------->|<-------------->| 241 E2E Path(A->D) 242 |<------------------------------------------------->| 244 +------------+ 245 ~A->B SubPath~ 246 +------------+ +------------+ 247 |s-PSID(A->B)| ~B->C SubPath~ 248 +------------+ +------------+ 249 | BSID(B->C) | |s-PSID(B->C)| 250 +------------+ +------------+ +------------+ 251 | BSID(C->D) | | BSID(C->D) | ~C->D SubPath~ 252 +------------+ +------------+ +------------+ +------------+ 253 |e-PSID(A->D)| |e-PSID(A->D)| |e-PSID(A->D)| |e-PSID(A->D)| 254 +------------+ +------------+ +------------+ +------------+ 256 Figure 2: Nesting of Path Segments 258 4. Path Segment Allocation 260 Several ways can be used to allocate the Path Segment. 262 One way is to set up a communication channel (e.g., MPLS Generic 263 Associated Channel (G-ACh)) between the ingress node and the egress 264 node, and the ingress node of the SR path can directly send a request 265 to the egress node to ask for a Path Segment. 267 Another way is to leverage a centralized controller (e.g., PCE, SDN 268 controller) to assign the Path Segment. PCEP based Path Segment 269 allocation is defined in [I-D.li-pce-sr-path-segment], and SR-policy 270 based path segment allocation is defined in 271 [I-D.li-idr-sr-policy-path-segment-distribution]. 273 A Path Segment can be used in the case of PHP, where some labels MAY 274 be popped off at the penultimate hop of an SR path, but the Path 275 Segment MUST NOT be popped off until it reaches at the egress LSR. 276 In the case of a Path Segment that is assigned by a centralized 277 controller, the controller must make sure (e.g., by some capability 278 discovery mechanisms) that the egress LSR knows and can process the 279 Path Segment. 281 5. Path Segment for PM 283 As defined in [RFC7799], performance measurement can be classified 284 into Active, Passive and Hybrid measurement. For Passive 285 measurement, path identification at the measuring points is the pre- 286 requisite. Path segment can be used by the measuring points (e.g., 287 the ingress/egress nodes of an SR path) or a centralized controller 288 to correlate the packets counts/timestamps that are from the ingress 289 and egress nodes to a specific SR path, then packet loss/delay can be 290 calculated. 292 Performance Delay Measurement (DM) and Loss Measurements (LM) in SR 293 networks with MPLS data plane can be found in 294 [I-D.gandhi-spring-sr-mpls-pm] and [I-D.gandhi-spring-udp-pm]. 296 6. Path Segment for Bi-directional SR Path 298 With the current SR architecture, an SR path is a unidirectional 299 path. In some scenarios, for example, mobile backhaul transport 300 network, there are requirements to support bidirectional paths, and 301 the path is normally treated as a single entity and both directions 302 of the path have the same fate, for example, failure in one direction 303 will result in switching at both directions. 305 MPLS supports this by introducing the concepts of co-routed 306 bidirectional LSP and associated bidirectional LSP. With SR, to 307 support bidirectional paths, a straightforward way is to bind two 308 unidirectional SR paths to a single bidirectional path. Path 309 Segments can be used to correlate the two unidirectional SR paths at 310 both ends of the paths. 312 [I-D.li-pce-sr-bidir-path] defines how to use PCEP and Path segment 313 to initiate a bidirectional SR path, and 314 [I-D.li-idr-sr-policy-path-segment-distribution] defines how to use 315 SR policy and Path segment to initiate a bidirectional SR path. 317 7. Path Segment for End-to-end Path Protection 319 For end-to-end 1+1 path protection (i.e., Live-Live case), the egress 320 node of an SR path needs to know the set of paths that constitute the 321 primary and the secondaries, in order to select the primary packet 322 for onward transmission, and to discard the packets from the 323 secondaries. 325 To do this, each path needs a path identifier that is unique at the 326 egress node. Depending on the design, this is a single unique path 327 segment label chosen by the egress PE. 329 There then needs to be a method of binding this path identifiers into 330 equivalence groups such that the egress PE can determine the set of 331 packets that represent a single path and its secondary. 333 It is obvious that this group can be instantiated in the network by 334 an SDN controller and that the Path Segment achieves the desired 335 function. 337 8. IANA Considerations 339 This document does not require any IANA actions. 341 9. Security Considerations 343 This document does not introduce additional security requirements and 344 mechanisms other than the ones described in [RFC8402]. 346 10. Contributors 348 The following individuals also contribute to this document. 350 o Cheng Li, Huawei 352 o Lei Wang, China Mobile 354 o Shuangping Zhan, ZTE 356 o Greg 358 11. Acknowledgements 360 The authors would like to thank Adrian Farrel, Stewart Bryant, 361 Alexander Vainshtein, Andrew G. Malis and Loa Andersson for their 362 review, suggestions and comments to this document. 364 The authors would like to acknowledge the contribution from Alexander 365 Vainshtein on "Nesting of Path Segments". 367 12. References 368 12.1. Normative References 370 [I-D.ietf-spring-segment-routing-mpls] 371 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 372 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 373 data plane", draft-ietf-spring-segment-routing-mpls-22 374 (work in progress), May 2019. 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, 378 DOI 10.17487/RFC2119, March 1997, 379 . 381 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 382 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 383 May 2017, . 385 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 386 Decraene, B., Litkowski, S., and R. Shakir, "Segment 387 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 388 July 2018, . 390 12.2. Informative References 392 [I-D.gandhi-spring-sr-mpls-pm] 393 Gandhi, R., Filsfils, C., daniel.voyer@bell.ca, d., 394 Salsano, S., Ventre, P., and M. Chen, "Performance 395 Measurement in Segment Routing Networks with MPLS Data 396 Plane", draft-gandhi-spring-sr-mpls-pm-03 (work in 397 progress), September 2018. 399 [I-D.gandhi-spring-udp-pm] 400 Gandhi, R., Filsfils, C., daniel.voyer@bell.ca, d., 401 Salsano, S., Ventre, P., and M. Chen, "UDP Path for In- 402 band Performance Measurement for Segment Routing 403 Networks", draft-gandhi-spring-udp-pm-02 (work in 404 progress), September 2018. 406 [I-D.ietf-6man-segment-routing-header] 407 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 408 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 409 Routing Header (SRH)", draft-ietf-6man-segment-routing- 410 header-22 (work in progress), August 2019. 412 [I-D.ietf-spring-segment-routing-policy] 413 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 414 bogdanov@google.com, b., and P. Mattes, "Segment Routing 415 Policy Architecture", draft-ietf-spring-segment-routing- 416 policy-03 (work in progress), May 2019. 418 [I-D.li-idr-sr-policy-path-segment-distribution] 419 Li, C., Chen, M., Dong, J., and Z. Li, "Segment Routing 420 Policies for Path Segment and Bidirectional Path", draft- 421 li-idr-sr-policy-path-segment-distribution-01 (work in 422 progress), October 2018. 424 [I-D.li-pce-sr-bidir-path] 425 Li, C., Chen, M., Cheng, W., Li, Z., Dong, J., Gandhi, R., 426 and Q. Xiong, "PCEP Extensions for Associated 427 Bidirectional Segment Routing (SR) Paths", draft-li-pce- 428 sr-bidir-path-06 (work in progress), August 2019. 430 [I-D.li-pce-sr-path-segment] 431 Li, C., Chen, M., Cheng, W., Dong, J., Li, Z., Gandhi, R., 432 and Q. Xiong, "Path Computation Element Communication 433 Protocol (PCEP) Extension for Path Segment in Segment 434 Routing (SR)", draft-li-pce-sr-path-segment-08 (work in 435 progress), August 2019. 437 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 438 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 439 May 2016, . 441 Authors' Addresses 443 Weiqiang Cheng 444 China Mobile 446 Email: chengweiqiang@chinamobile.com 448 Han Li 449 China Mobile 451 Email: lihan@chinamobile.com 453 Mach(Guoyi) Chen 454 Huawei 456 Email: mach.chen@huawei.com 457 Rakesh Gandhi 458 Cisco Systems, Inc. 459 Canada 461 Email: rgandhi@cisco.com 463 Royi Zigler 464 Broadcom 466 Email: royi.zigler@broadcom.com