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