idnits 2.17.1 draft-ietf-spring-oam-usecase-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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 (October 15, 2015) is 3109 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-05 == 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-06 == Outdated reference: A later version (-03) exists of draft-ietf-spring-sr-oam-requirement-00 == Outdated reference: A later version (-06) exists of draft-kumarkini-mpls-spring-lsp-ping-04 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING R. Geib 3 Internet-Draft Deutsche Telekom 4 Intended status: Informational C. Filsfils 5 Expires: April 17, 2016 C. Pignataro 6 N. Kumar 7 Cisco Systems, Inc. 8 October 15, 2015 10 Use Case for a Scalable and Topology-Aware Segment Routing MPLS Data 11 Plane Monitoring System 12 draft-ietf-spring-oam-usecase-01 14 Abstract 16 This document describes features and a use case of a path monitoring 17 system. Segment based routing enables a scalable and simple method 18 to monitor data plane liveliness of the complete set of paths 19 belonging to a single domain. Compared with legacy MPLS ping and 20 path trace, MPLS topology awareness reduces management and control 21 plane involvement of OAM measurements while enabling new and prior 22 hard to realise OAM features. 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 April 17, 2016. 41 Copyright Notice 43 Copyright (c) 2015 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. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. An MPLS Topology-Aware Path Monitoring System . . . . . . . . 5 61 4. SR-Based Path Monitoring Use Case Illustration . . . . . . . 6 62 4.1. Use Case 1 - LSP Data Plane Monitoring . . . . . . . . . 6 63 4.2. Use Case 2 - Monitoring a Remote Bundle . . . . . . . . . 8 64 4.3. Use Case 3 - Fault Localization . . . . . . . . . . . . . 9 65 5. Failure Notification from PMS to LERi . . . . . . . . . . . . 9 66 6. Applying SR to Monitor LDP Paths . . . . . . . . . . . . . . 9 67 7. PMS Monitoring of Different Segment ID Types . . . . . . . . 10 68 8. Connectivity Verification Using PMS . . . . . . . . . . . . . 10 69 9. Extensions of Related Specifications . . . . . . . . . . . . 10 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 73 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 13.2. Informative References . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Acronyms 80 ECMP Equal-Cost Multi-Path 82 IGP Interionr Gateway Protocol 84 LER Label Edge Router 86 LSP Label Switched Path 88 LSR Label Switching Router 90 OAM Operations, Administration, and Maintenance 92 PMS Path Monitoring System 94 SID Segment Identifier 96 SR Segment Routing 98 2. Introduction 100 It is essential for a network operator to monitor all the forwarding 101 paths observed by the transported user packets. The monitoring flow 102 is expected to be forwarded in data plane in a similar way as user 103 packets. Segment Routing enables forwarding of packets along pre- 104 defined paths and segments and thus a Segment Routed monitoring 105 packet can stay in dataplane while passing along one or more segments 106 to be monitored. 108 This document describes illustrates use cases based on data plane 109 path monitoring capabilities. The use case is limited to a single 110 IGP MPLS domain. 112 The use case applies to monitoring of LDP LSP's as well as to 113 monitoring of Segment Routed LSP's. As compared to LDP, Segment 114 Routing is expected to simplify the use case by enabling MPLS 115 topology detection based on IGP signaled segments as specified by 116 [I-D.ietf-isis-segment-routing-extensions] and 117 [I-D.ietf-ospf-segment-routing-extensions]. Thus a centralised and 118 MPLS topology aware monitoring unit can be realized in a Segment 119 Routed domain. This topology awareness can be used for OAM purposes 120 as described by this use case. This use case can't be realised with 121 legacy IP technology. It is hard to realise with LDP. Segment 122 Routing allows for a simple realisation. 124 The MPLS path monitoring system described by this document can be 125 realised with pre-Segment based Routing (SR) technology. Making such 126 a pre-SR MPLS monitoring system aware of a domains complete MPLS 127 topology requires e.g. management plane access. To avoid the use of 128 stale MPLS label information, IGP must be monitored and MPLS topology 129 must be timely aligned with IGP topology. Obviously, enhancing IGPs 130 to exchange of MPLS topology information as done by SR significantly 131 simplifies and stabilises such an MPLS path monitoring system. 133 This document adopts the terminology and framework described in 134 [I-D.ietf-spring-segment-routing]. It assumes application of a 135 Segment Routing Global Block (of Labels in the MPLS case), as this 136 simplifies this Use Case to the largest extent posssible. 138 The use case offers several benefits for network monitoring. A 139 single centralized monitoring device is able to monitor the complete 140 set of a domains forwarding paths. Monitoring packets never leave 141 data plane. MPLS path trace function (whose specification and 142 features are not part of this use case) is required, if the actual 143 data plane of a router should be checked against its control plane. 144 SR capabilities allow to direct MPLS OAM packets from a centralized 145 monitoring system to any router within a domain whose path should be 146 traced. 148 In addition to monitoring paths, problem localization is required. 149 Faults can be localized: 151 o by IGP LSA analysis. 153 o correlation between different SR based monitoring probes. 155 o by any MPLS traceroute method (possibly in combination with SR 156 based path stacks). 158 Topology awareness is an essential part of link state IGPs. Adding 159 MPLS topology awareness to an IGP speaking device hence enables a 160 simple and scalable data plane based monitoring mechanism. 162 MPLS OAM offers flexible features to recognise an execute data paths 163 of an MPLS domain. By utilising the ECMP related tool set offered 164 e.g. by [RFC4379], a segment based routing LSP monitoring system 165 may: 167 o easily detect ECMP functionality and properties of paths at data 168 level. 170 o construct monitoring packets executing desired paths also if ECMP 171 is present. 173 o limit the MPLS label stack of an OAM packet to a minmum of 3 174 labels. 176 Alternatively, any path may be executed by building suitable label 177 stacks. This allows path execution without ECMP awareness. 179 The MPLS path monitoring system may be a any server residing at a 180 single interface of the domain to be monitored. It doesn't have to 181 support any specialised protocol stack, it just should be capable of 182 understanding the topology and building the probe packet with the 183 right segment stack. As long as measurement packets return to this 184 or another interface connecting such a server, the MPLS monitoring 185 servers are the single entities pushing monitoring packet label 186 stacks. If the depth of label stacks to be pushed by a path 187 monitoring system (PMS) are of concern for a domain, a dedicated 188 server based path monitoring architecture allows limiting monitoring 189 related label stack pushes to these servers. 191 This draft does not intend to describe how to operate and maintain a 192 Segment Routing domain in general. One or more suitable document to 193 that purpose require stable SR solutions. Drafts discussing SR OAM 194 requirements and possible solutions to support SR OAM in general have 195 been submitted, see [I-D.ietf-spring-sr-oam-requirement] and 196 [I-D.kumarkini-mpls-spring-lsp-ping]. 198 3. An MPLS Topology-Aware Path Monitoring System 200 An MPLS PMS which is able to learn the IGP LSDB (including the SID's) 201 is able to execute arbitrary chains of label switched paths. It can 202 send pure monitoring packets along such a path chain or it can direct 203 suitable MPLS OAM packets to any node along a path segment. Segment 204 Routing here is used as a means of adding label stacks and hence 205 transport to standard MPLS OAM packets, which then detect 206 correspondence of control and data plane of this (or any other 207 addressed) path. Any node connected to an SR domain is MPLS topology 208 aware (the node knows all related IP addresses, SR SIDs and MPLS 209 labels). Thus a PMS connected to an MPLS SR domain just needs to set 210 up a topology data base for monitoring purposes. 212 Let us describe how the PMS constructs a labels stack to transport a 213 packet to LER i, monitor the path of it to LER j and then receive the 214 packet back. 216 The PMS may do so by sending packets carrying the following MPLS 217 label stack infomation: 219 o Top Label: a path from PMS to LER i, which is expressed as Node 220 SID of LER i. 222 o Next Label: the path that needs to be monitored from LER i to LER 223 j. If this path is a single physical interface (or a bundle of 224 connected interfaces), it can be expressed by the related AdjSID. 225 If the shortest path from LER i to LER j is supposed to be 226 monitored, the Node-SID (LER j) can be used. Another option is to 227 insert a list of segments expressing the desired path (hop by hop 228 as an extreme case). If LER i pushes a stack of Labels based on a 229 SR policy decision and this stack of LSPs is to be monitored, the 230 PMS needs an interface to collect the information enabling it to 231 address this SR created path. 233 o Next Label or address: the path back to the PMS. Likely, no 234 further segment/label is required here. Indeed, once the packet 235 reaches LER j, the 'steering' part of the solution is done and the 236 probe just needs to return to the PMS. This is best achieved by 237 popping the MPLS stack and revealing a probe packet with PMS as 238 destination address (note that in this case, the source and 239 destination addresses could be the same). If an IP address is 240 applied, no SID/label has to be assigned to the PMS (if it is a 241 host/server residing in an IP subnet outside the MPLS domain). 243 Note: if the PMS is an IP host not connected to the MPLS domain, the 244 PMS can send its probe with the list of SIDs/Labels onto a suitable 245 tunnel providing an MPLS access to a router which is part of the 246 monitored MPLS domain. 248 4. SR-Based Path Monitoring Use Case Illustration 250 4.1. Use Case 1 - LSP Data Plane Monitoring 252 +---+ +----+ +-----+ 253 |PMS| |LSR1|-----|LER i| 254 +---+ +----+ +-----+ 255 | / \ / 256 | / \__/ 257 +-----+/ /| 258 |LER m| / | 259 +-----+\ / \ 260 \ / \ 261 \+----+ +-----+ 262 |LSR2|-----|LER j| 263 +----+ +-----+ 265 Example of a PMS based LSP dataplane monitoring 267 Figure 1 269 For the sake of simplicity, let's assume that all the nodes are 270 configured with the same SRGB [I-D.ietf-spring-segment-routing]. 272 Let's assign the following Node SIDs to the nodes of the figure: PMS 273 = 10, LER i = 20, LER j = 30. 275 To be able to work with the smallest possible SR label stack, first a 276 suitable MPLS OAM method is used to detect the ECMP routed path 277 between LER i to LER j which is to be monitored (and the required 278 address information to direct a packet along it). Afterwards the PMS 279 sets up and sends packets to monitor availability of the detected 280 path. The PMS does this by creating a measurement packet with the 281 following label stack (top to bottom): 20 - 30 - 10. The packet will 282 only reliably use the monitored path, if the label and address 283 information used in combination with the MPLS OAM method of choice is 284 identical to that of the monitoring packet. 286 LER m forwards the packet received from the PMS to LSR1. Assuming 287 Pen-ultimate Hop Popping to be deployed, LSR1 pops the top label and 288 forwards the packet to LER i. There the top label has a value 30 and 289 LER i forwards it to LER j. This will be done transmitting the 290 packet via LSR1 or LSR2. The LSR will again pop the top label. LER 291 j will forward the packet now carrying the top label 10 to the PMS 292 (and it will pass a LSR and LER m). 294 A few observations on the example given in figure 1: 296 o The path PMS to LER i must be available. This path must be 297 detectable, but it is usually sufficient to apply a Shortest Path 298 First algorithm based path. 300 o If ECMP is deployed, it may be desired to measure along both 301 possible paths which a packet may use between LER i and LER j. To 302 do so, the MPLS OAM mechanism chosen to detect ECMP must reveal 303 the required information (an example is a so called tree trace) 304 between LER i and LER j. This method of dealing with ECMP based 305 load balancing paths requires the smallest SR label stacks if 306 monitoring of paths is applied after the tree trace completion. 308 o The path LER j to PMS to must be available. This path must be 309 detectable, but it is usually sufficient to apply an SPF based 310 path. 312 Once the MPLS paths (Node SIDs) and the required information to deal 313 with ECMP has been detected, the paths of LER i to LER j can be 314 monitored by the PMS. Monitoring itself does not require MPLS OAM 315 functionality. All monitoring packets stay on dataplane, hence path 316 monitoring does no longer require control plane interaction in any 317 LER or LSR of the domain. To ensure reliable results, the PMS should 318 be aware of any changes in IGP or MPLS topology. Further changes in 319 ECMP functionality at LER i will impact results. Either the PMS 320 should be notified of such changes or they should be limited to 321 planned maintenance. After a topology change, a suitable MPLS OAM 322 mechanism may be useful to detect the impact of the change. 324 Determining a path to be executed prior to a measurement may also be 325 done by setting up a label stack including all Node SIDs along that 326 path (if LSR1 has Node SID 40 in the example and it should be passed 327 between LER i and LER j, the label stack is 20 - 40 - 30 - 10). The 328 advantage of this method is, that it does not involve MPLS OAM 329 functionality and it is independent of ECMP functionalities. The 330 method still is able to monitor all link combinations of all paths of 331 an MPLS domain. If correct forwarding along the desired paths has to 332 be checked, some suitable MPLS OAM mechanism may be applied also in 333 this case. 335 In theory at least, a single PMS is able to monitor data plane 336 availability of all LSPs in the domain. The PMS may be a router, but 337 could also be dedicated monitoring system. If measurement system 338 reliability is an issue, more than a single PMS may be connected to 339 the MPLS domain. 341 Monitoring an MPLS domain by a PMS based on SR offers the option of 342 monitoring complete MPLS domains with little effort and very 343 excellent scalability. Data plane failure detection by circulating 344 monitoring packets can be executed at any time. The PMS further 345 could be enabled to send MPLS OAM packets with the label stacks and 346 address information identical to those of the monitoring packets to 347 any node of the MPLS domain. It does not require access to LSR/LER 348 management interfaces or their control plane to do so. 350 4.2. Use Case 2 - Monitoring a Remote Bundle 352 +---+ _ +--+ +-------+ 353 | | { } | |---991---L1---662---| | 354 |PMS|--{ }-|R1|---992---L2---663---|R2 (72)| 355 | | {_} | |---993---L3---664---| | 356 +---+ +--+ +-------+ 358 SR based probing of all the links of a remote bundle 360 Figure 2 362 R1 addresses Lx by the Adjacency SID 99x, while R2 addresses Lx by 363 the Adjacency SID 66(x+1). 365 In the above figure, the PMS needs to assess the dataplane 366 availability of all the links within a remote bundle connected to 367 routers R1 and R2. 369 The monitoring system retrieves the SID/Label information from the 370 IGP LSDB and appends the following segment list/label stack: {72, 371 662, 992, 664} on its IP probe (whose source and destination 372 addresses are the address of the PMS). 374 PMS sends the probe to its connected router. If the connected router 375 is not SR compliant, a tunneling technique can be used to tunnel the 376 probe and its MPLS stack to the first SR router. The MPLS/SR domain 377 then forwards the probe to R2 (72 is the Node SID of R2). R2 378 forwards the probe to R1 over link L1 (Adjacency SID 662). R1 379 forwards the probe to R2 over link L2 (Adjacency SID 992). R2 380 forwards the probe to R1 over link L3 (Adjacency SID 664). R1 then 381 forwards the IP probe to PMS as per classic IP forwarding. 383 4.3. Use Case 3 - Fault Localization 385 In the previous example, a uni-directional fault on the middle link 386 in direction of R2 to R1 would be localized by sending the following 387 two probes with respective segment lists: 389 o 72, 662, 992, 664 391 o 72, 663, 992, 664 393 The first probe would fail while the second would succeed. 394 Correlation of the measurements reveals that the only difference is 395 using the Adjacency SID 662 of the middle link from R1 to R2 in the 396 non successful measurement. Assuming the second probe has been 397 routed correctly, the fault must have been occurring in R2 which 398 didn't forward the packet to the interface identified by its 399 Adjacency SID 662. 401 5. Failure Notification from PMS to LERi 403 PMS on detecting any failure in the path liveliness may use any out- 404 of-band mechanism to signal the failure to LER i. This document does 405 not propose any specific mechanism and operators can choose any 406 existing or new approach. 408 Alternately, the Operator may log the failure in local monitoring 409 system and take necessary action by manual intervention. 411 6. Applying SR to Monitor LDP Paths 413 A SR based PMS connected to a MPLS domain consisting of LER and LSR 414 supporting SR and LDP in parallel in all nodes may use SR paths to 415 transmit packets to and from start and end points of LDP paths to be 416 monitored. In the above example, the label stack top to bottom may 417 be as follows, when sent by the PMS: 419 o Top: SR based Node-SID of LER i at LER m. 421 o Next: LDP label identifying the path to LER j at LER i. 423 o Bottom: SR based Node-SID identifying the path to the PMS at LER j 425 While the mixed operation shown here still requires the PMS to be 426 aware of the LER LDP-MPLS topology, the PMS may learn the SR MPLS 427 topology by IGP and use this information. 429 7. PMS Monitoring of Different Segment ID Types 431 MPLS SR topology awareness should allow the SID to monitor liveliness 432 of most types of SIDs (this may not be recommendable if a SID 433 identifies an inter domain interface). 435 To match control plane information with data plane information, MPLS 436 OAM functions as defined by e.g. [RFC4379] should be enhanced to 437 allow collection of data relevant to check all relevant types of 438 Segment IDs. 440 8. Connectivity Verification Using PMS 442 While the PMS based use cases explained in Section 3 are sufficient 443 to provide continuity check between LER i and LER j, it may not help 444 perform connectivity verification. So in some cases like data plane 445 programming corruption, it is possible that a transit node between 446 LER i and LER j erroneously removes the top segment ID and forwards a 447 monitoring packet to the PMS based on the bottom segment ID leading 448 to a falsified path liveliness indication by the PMS. 450 There are various method to perform basic connectivity verification 451 like intermittently setting the TTL to 1 in bottom label so LER j 452 selectively perform connectivity verification. Other methods are 453 possible and may be added when requirements and solutions are 454 specified. 456 9. Extensions of Related Specifications 458 The following activities are welcome enhancements supporting this use 459 case, but they are not part of it: 461 [RFC4379] functions should be extended to support Flow- and Entropy 462 Label based ECMP. 464 10. IANA Considerations 466 This memo includes no request to IANA. 468 11. Security Considerations 470 As mentioned in the introduction, a PMS monitoring packet should 471 never leave the domain where it originated. It therefore should 472 never use stale MPLS or IGP routing information. Further, assigning 473 different label ranges for different purposes may be useful. A well 474 known global service level range may be excluded for utilisation 475 within PMS measurement packets. These ideas shouldn't start a 476 discussion. They rather should point out, that such a discussion is 477 required when SR based OAM mechanisms like a SR are standardised. 479 12. Acknowledgement 481 The authors would like to thank Nobo Akiya for his contribution. 482 Raik Leipnitz kindly provided an editorial review. 484 13. References 486 13.1. Normative References 488 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 489 Label Switched (MPLS) Data Plane Failures", RFC 4379, 490 DOI 10.17487/RFC4379, February 2006, 491 . 493 13.2. Informative References 495 [I-D.ietf-isis-segment-routing-extensions] 496 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., 497 Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS 498 Extensions for Segment Routing", draft-ietf-isis-segment- 499 routing-extensions-05 (work in progress), June 2015. 501 [I-D.ietf-ospf-segment-routing-extensions] 502 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 503 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 504 Extensions for Segment Routing", draft-ietf-ospf-segment- 505 routing-extensions-05 (work in progress), June 2015. 507 [I-D.ietf-spring-segment-routing] 508 Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., 509 and r. rjs@rob.sh, "Segment Routing Architecture", draft- 510 ietf-spring-segment-routing-06 (work in progress), October 511 2015. 513 [I-D.ietf-spring-sr-oam-requirement] 514 Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., 515 and S. Litkowski, "OAM Requirements for Segment Routing 516 Network", draft-ietf-spring-sr-oam-requirement-00 (work in 517 progress), June 2015. 519 [I-D.kumarkini-mpls-spring-lsp-ping] 520 Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini, 521 S., Gredler, H., and M. Chen, "Label Switched Path (LSP) 522 Ping/Trace for Segment Routing Networks Using MPLS 523 Dataplane", draft-kumarkini-mpls-spring-lsp-ping-04 (work 524 in progress), July 2015. 526 Authors' Addresses 528 Ruediger Geib 529 Deutsche Telekom 530 Heinrich Hertz Str. 3-7 531 Darmstadt 64295 532 Germany 534 Phone: +49 6151 5812747 535 Email: Ruediger.Geib@telekom.de 537 Clarence Filsfils 538 Cisco Systems, Inc. 539 Brussels 540 Belgium 542 Email: cfilsfil@cisco.com 544 Carlos Pignataro 545 Cisco Systems, Inc. 546 7200 Kit Creek Road 547 Research Triangle Park, NC 27709-4987 548 US 550 Email: cpignata@cisco.com 552 Nagendra Kumar 553 Cisco Systems, Inc. 554 7200 Kit Creek Road 555 Research Triangle Park, NC 27709 556 US 558 Email: naikumar@cisco.com