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