idnits 2.17.1 draft-geib-spring-oam-usecase-06.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 (July 3, 2015) is 3217 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 2 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: January 4, 2016 C. Pignataro 6 N. Kumar 7 Cisco Systems, Inc. 8 July 3, 2015 10 Use case for a scalable and topology aware MPLS data plane monitoring 11 system 12 draft-geib-spring-oam-usecase-06 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 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 January 4, 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. An MPLS topology aware path monitoring system . . . . . . . . 4 60 3. SR based path monitoring use case illustration . . . . . . . 5 61 3.1. Use-case 1 - LSP dataplane monitoring . . . . . . . . . . 5 62 3.2. Use-case 2 - Monitoring a remote bundle . . . . . . . . . 7 63 3.3. Use-Case 3 - Fault localization . . . . . . . . . . . . . 8 64 4. Failure Notification from PMS to LERi . . . . . . . . . . . . 8 65 5. Applying SR to monitor LDP paths . . . . . . . . . . . . . . 9 66 6. PMS monitoring of different Segment ID types . . . . . . . . 9 67 7. Connectivity Verification using PMS . . . . . . . . . . . . . 9 68 8. Extensions of related standards helpful for this use case . . 10 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 12.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 It is essential for a network operator to monitor all the forwarding 80 paths observed by the transported user packets. The monitoring flow 81 is expected to be forwarded in dataplane in a similar way as user 82 packets. Segment Routing enables forwarding of packets along pre- 83 defined paths and segments and thus a Segment Routed monitoring 84 packet can stay in dataplane while passing along one or more segments 85 to be monitored. 87 This document describes illustrates use-cases based on data plane 88 path monitoring capabilities. The use case is limited to a single 89 IGP MPLS domain. 91 The use case applies to monitoring of LDP LSP's as well as to 92 monitoring of Segment Routed LSP's. As compared to LDP, Segment 93 Routing is expected to simplify the use case by enabling MPLS 94 topology detection based on IGP signaled segments as specified by 95 [ID.sr-isis]. Thus a centralised and MPLS topology aware monitoring 96 unit can be realized in a Segment Routed domain. This topology 97 awareness can be used for OAM purposes as described by this use case. 98 The MPLS path monitoring system described by this document can be 99 realised with pre-Segment based Routing (SR) technology. Making such 100 a pre-SR MPLS monitoring system aware of a domains complete MPLS 101 topology requires e.g. management plane access. To avoid the use of 102 stale MPLS label information, IGP must be monitored and MPLS topology 103 must be timely aligned with IGP topology. Obviously, enhancing IGPs 104 to exchange of MPLS topology information as done by SR significantly 105 simplifies and stabilises such an MPLS path monitoring system. 107 This document adopts the terminology and framework described in 108 [ID.sr-archi]. It further adopts the editorial simplification 109 explained in section 1.2 of the segment routing use-cases 110 [ID.sr-use]. 112 The use case offers several benefits for network monitoring. A 113 single centralized monitoring device is able to monitor the complete 114 set of a domains forwarding paths. Monitoring packets never leave 115 data plane. MPLS path trace function (whose specification and 116 features are not part of this use case) is required, if the actual 117 data plane of a router should be checked against its control plane. 118 SR capabilities allow to direct MPLS OAM packets from a centralized 119 monitoring system to any router within a domain whose path should be 120 traced. 122 In addition to monitoring paths, problem localization is required. 123 Faults can be localized: 125 o by IGP LSA analysis. 127 o correlation between different SR based monitoring probes. 129 o by any MPLS traceroute method (possibly in combination with SR 130 based path stacks). 132 Topology awareness is an essential part of link state IGPs. Adding 133 MPLS topology awareness to an IGP speaking device hence enables a 134 simple and scalable data plane based monitoring mechanism. 136 MPLS OAM offers flexible features to recognise an execute data paths 137 of an MPLS domain. By utilising the ECMP related tool set offered 138 e.g. by RFC 4379 [RFC4379], a segment based routing LSP monitoring 139 system may: 141 o easily detect ECMP functionality and properties of paths at data 142 level. 144 o construct monitoring packets executing desired paths also if ECMP 145 is present. 147 o limit the MPLS label stack of an OAM packet to a minmum of 3 148 labels. 150 Alternatively, any path may be executed by building suitable label 151 stacks. This allows path execution without ECMP awareness. 153 The MPLS path monitoring system may be a any server residing at a 154 single interface of the domain to be monitored. It doesn't have to 155 support any specialised protocol stack, it just should be capable of 156 understanding the topology and building the probe packet with the 157 right segment stack. As long as measurement packets return to this 158 or another interface connecting such a server, the MPLS monitoring 159 servers are the single entities pushing monitoring packet label 160 stacks. If the depth of label stacks to be pushed by a path 161 monitoring system (PMS) are of concern for a domain, a dedicated 162 server based path monitoring architecture allows limiting monitoring 163 related label stack pushes to these servers. 165 First drafts discussing SR OAM requirements and possible solutions to 166 allow SR usage as described by this document have been submitted 167 already, see [ID.sr-4379ext] and [ID.sr-oam_detect]. 169 2. An MPLS topology aware path monitoring system 171 An MPLS PMS which is able to learn the IGP LSDB (including the SID's) 172 is able to execute arbitrary chains of label switched paths. It can 173 send pure monitoring packets along such a path chain or it can direct 174 suitable MPLS OAM packets to any node along a path segment. Segment 175 Routing here is used as a means of adding label stacks and hence 176 transport to standard MPLS OAM packets, which then detect 177 correspondence of control and data plane of this (or any other 178 addressed) path. Any node connected to an SR domain is MPLS topology 179 aware (the node knows all related IP addresses, SR SIDs and MPLS 180 labels). Thus a PMS connected to an MPLS SR domain just needs to set 181 up a topology data base for monitoring purposes. 183 Let us describe how the PMS constructs a labels stack to transport a 184 packet to LER i, monitor the path of it to LER j and then receive the 185 packet back. 187 The PMS may do so by sending packets carrying the following MPLS 188 label stack infomation: 190 o Top Label: a path from PMS to LER i, which is expressed as Node 191 SID of LER i. 193 o Next Label: the path that needs to be monitored from LER i to LER 194 j. If this path is a single physical interface (or a bundle of 195 connected interfaces), it can be expressed by the related AdjSID. 196 If the shortest path from LER i to LER j is supposed to be 197 monitored, the Node-SID (LER j) can be used. Another option is to 198 insert a list of segments expressing the desired path (hop by hop 199 as an extreme case). If LER i pushes a stack of Labels based on a 200 SR policy decision and this stack of LSPs is to be monitored, the 201 PMS needs an interface to collect the information enabling it to 202 address this SR created path. 204 o Next Label or address: the path back to the PMS. Likely, no 205 further segment/label is required here. Indeed, once the packet 206 reaches LER j, the 'steering' part of the solution is done and the 207 probe just needs to return to the PMS. This is best achieved by 208 popping the MPLS stack and revealing a probe packet with PMS as 209 destination address (note that in this case, the source and 210 destination addresses could be the same). If an IP address is 211 applied, no SID/label has to be assigned to the PMS (if it is a 212 host/server residing in an IP subnet outside the MPLS domain). 214 Note: if the PMS is an IP host not connected to the MPLS domain, the 215 PMS can send its probe with the list of SIDs/Labels onto a suitable 216 tunnel providing an MPLS access to a router which is part of the 217 monitored MPLS domain. 219 3. SR based path monitoring use case illustration 221 3.1. Use-case 1 - LSP dataplane monitoring 223 +---+ +----+ +-----+ 224 |PMS| |LSR1|-----|LER i| 225 +---+ +----+ +-----+ 226 | / \ / 227 | / \__/ 228 +-----+/ /| 229 |LER m| / | 230 +-----+\ / \ 231 \ / \ 232 \+----+ +-----+ 233 |LSR2|-----|LER j| 234 +----+ +-----+ 236 Example of a PMS based LSP dataplane monitoring 238 Figure 1 240 For the sake of simplicity, let's assume that all the nodes are 241 configured with the same SRGB [ID.sr-archi], as described by section 242 1.2 of [ID.sr-use]. 244 Let's assign the following Node SIDs to the nodes of the figure: PMS 245 = 10, LER i = 20, LER j = 30. 247 To be able to work with the smallest possible SR label stack, first a 248 suitable MPLS OAM method is used to detect the ECMP routed path 249 between LER i to LER j which is to be monitored (and the required 250 address information to direct a packet along it). Afterwards the PMS 251 sets up and sends packets to monitor availability of the detected 252 path. The PMS does this by creating a measurement packet with the 253 following label stack (top to bottom): 20 - 30 - 10. The packet will 254 only reliably use the monitored path, if the label and address 255 information used in combination with the MPLS OAM method of choice is 256 identical to that of the monitoring packet. 258 LER m forwards the packet received from the PMS to LSR1. Assuming 259 Pen-ultimate Hop Popping to be deployed, LSR1 pops the top label and 260 forwards the packet to LER i. There the top label has a value 30 and 261 LER i forwards it to LER j. This will be done transmitting the 262 packet via LSR1 or LSR2. The LSR will again pop the top label. LER 263 j will forward the packet now carrying the top label 10 to the PMS 264 (and it will pass a LSR and LER m). 266 A few observations on the example given in figure 1: 268 o The path PMS to LER i must be available. This path must be 269 detectable, but it is usually sufficient to apply a Shortest Path 270 First algorithm based path. 272 o If ECMP is deployed, it may be desired to measure along both 273 possible paths which a packet may use between LER i and LER j. To 274 do so, the MPLS OAM mechanism chosen to detect ECMP must reveal 275 the required information (an example is a so called tree trace) 276 between LER i and LER j. This method of dealing with ECMP based 277 load balancing paths requires the smallest SR label stacks if 278 monitoring of paths is applied after the tree trace completion. 280 o The path LER j to PMS to must be available. This path must be 281 detectable, but it is usually sufficient to apply an SPF based 282 path. 284 Once the MPLS paths (Node SIDs) and the required information to deal 285 with ECMP has been detected, the paths of LER i to LER j can be 286 monitored by the PMS. Monitoring itself does not require MPLS OAM 287 functionality. All monitoring packets stay on dataplane, hence path 288 monitoring does no longer require control plane interaction in any 289 LER or LSR of the domain. To ensure reliable results, the PMS should 290 be aware of any changes in IGP or MPLS topology. Further changes in 291 ECMP functionality at LER i will impact results. Either the PMS 292 should be notified of such changes or they should be limited to 293 planned maintenance. After a topology change, a suitable MPLS OAM 294 mechanism may be useful to detect the impact of the change. 296 Determining a path to be executed prior to a measurement may also be 297 done by setting up a label stack including all Node SIDs along that 298 path (if LSR1 has Node SID 40 in the example and it should be passed 299 between LER i and LER j, the label stack is 20 - 40 - 30 - 10). The 300 advantage of this method is, that it does not involve MPLS OAM 301 functionality and it is independent of ECMP functionalities. The 302 method still is able to monitor all link combinations of all paths of 303 an MPLS domain. If correct forwarding along the desired paths has to 304 be checked, some suitable MPLS OAM mechanism may be applied also in 305 this case. 307 In theory at least, a single PMS is able to monitor data plane 308 availability of all LSPs in the domain. The PMS may be a router, but 309 could also be dedicated monitoring system. If measurement system 310 reliability is an issue, more than a single PMS may be connected to 311 the MPLS domain. 313 Monitoring an MPLS domain by a PMS based on SR offers the option of 314 monitoring complete MPLS domains with little effort and very 315 excellent scalability. Data plane failure detection by circulating 316 monitoring packets can be executed at any time. The PMS further 317 could be enabled to send MPLS OAM packets with the label stacks and 318 address information identical to those of the monitoring packets to 319 any node of the MPLS domain. It does not require access to LSR/LER 320 management interfaces or their control plane to do so. 322 3.2. Use-case 2 - Monitoring a remote bundle 324 +---+ _ +--+ +-------+ 325 | | { } | |---991---L1---662---| | 326 |PMS|--{ }-|R1|---992---L2---663---|R2 (72)| 327 | | {_} | |---993---L3---664---| | 328 +---+ +--+ +-------+ 330 SR based probing of all the links of a remote bundle 332 Figure 2 334 R1 addresses Lx by the Adjacency SID 99x, while R2 addresses Lx by 335 the Adjacency SID 66(x+1). 337 In the above figure, the PMS needs to assess the dataplane 338 availability of all the links within a remote bundle connected to 339 routers R1 and R2. 341 The monitoring system retrieves the SID/Label information from the 342 IGP LSDB and appends the following segment list/label stack: {72, 343 662, 992, 664} on its IP probe (whose source and destination 344 addresses are the address of the PMS). 346 PMS sends the probe to its connected router. If the connected router 347 is not SR compliant, a tunneling technique can be used to tunnel the 348 probe and its MPLS stack to the first SR router. The MPLS/SR domain 349 then forwards the probe to R2 (72 is the Node SID of R2). R2 350 forwards the probe to R1 over link L1 (Adjacency SID 662). R1 351 forwards the probe to R2 over link L2 (Adjacency SID 992). R2 352 forwards the probe to R1 over link L3 (Adjacency SID 664). R1 then 353 forwards the IP probe to PMS as per classic IP forwarding. 355 3.3. Use-Case 3 - Fault localization 357 In the previous example, a uni-directional fault on the middle link 358 in direction of R2 to R1 would be localized by sending the following 359 two probes with respective segment lists: 361 o 72, 662, 992, 664 363 o 72, 663, 992, 664 365 The first probe would fail while the second would succeed. 366 Correlation of the measurements reveals that the only difference is 367 using the Adjacency SID 662 of the middle link from R1 to R2 in the 368 non successful measurement. Assuming the second probe has been 369 routed correctly, the fault must have been occurring in R2 which 370 didn't forward the packet to the interface identified by its 371 Adjacency SID 662. 373 4. Failure Notification from PMS to LERi 375 PMS on detecting any failure in the path liveliness may use any out- 376 of-band mechanism to signal the failure to LER i. This document does 377 not propose any specific mechanism and operators can choose any 378 existing or new approach. 380 Alternately, the Operator may log the failure in local monitoring 381 system and take necessary action by manual intervention. 383 5. Applying SR to monitor LDP paths 385 A SR based PMS connected to a MPLS domain consisting of LER and LSR 386 supporting SR and LDP in parallel in all nodes may use SR paths to 387 transmit packets to and from start and end points of LDP paths to be 388 monitored. In the above example, the label stack top to bottom may 389 be as follows, when sent by the PMS: 391 o Top: SR based Node-SID of LER i at LER m. 393 o Next: LDP label identifying the path to LER j at LER i. 395 o Bottom: SR based Node-SID identifying the path to the PMS at LER j 397 While the mixed operation shown here still requires the PMS to be 398 aware of the LER LDP-MPLS topology, the PMS may learn the SR MPLS 399 topology by IGP and use this information. 401 6. PMS monitoring of different Segment ID types 403 MPLS SR topology awareness should allow the SID to monitor liveliness 404 of most types of SIDs (this may not be recommendable if a SID 405 identifies an inter domain interface). 407 To match control plane information with data plane information, MPLS 408 OAM functions as defined by e.g. RFC4379 should be enhanced to allow 409 collection of data relevant to check all relevant types of Segment 410 IDs. 412 7. Connectivity Verification using PMS 414 While the PMS based use cases explained in Section 3 are sufficient 415 to provide continuity check between LER i and LER j, it may not help 416 perform connectivity verification. So in some cases like data plane 417 programming corruption, it is possible that a transit node between 418 LER i and LER j erroneously removes the top segment ID and forwards a 419 monitoring packet to the PMS based on the bottom segment ID leading 420 to a falsified path liveliness indication by the PMS. 422 There are various method to perform basic connectivity verification 423 like intermittently setting the TTL to 1 in bottom label so LER j 424 selectively perform connectivity verification. Other methods are 425 possible and may be added when requirements and solutions are 426 specified. 428 8. Extensions of related standards helpful for this use case 430 The following activities are welcome enhancements supporting this use 431 case, but they are not part of it: 433 RFC4379 functions should be extended to support Flow- and Entropy 434 Label based ECMP. 436 9. IANA Considerations 438 This memo includes no request to IANA. 440 10. Security Considerations 442 As mentioned in the introduction, a PMS monitoring packet should 443 never leave the domain where it originated. It therefore should 444 never use stale MPLS or IGP routing information. Further, assigning 445 different label ranges for different purposes may be useful. A well 446 known global service level range may be excluded for utilisation 447 within PMS measurement packets. These ideas shouldn't start a 448 discussion. They rather should point out, that such a discussion is 449 required when SR based OAM mechanisms like a SR are standardised. 451 11. Acknowledgement 453 The authors would like to thank Nobo Akiya for his contribution. 454 Raik Leipnitz kindly provided an editorial review. 456 12. References 458 12.1. Normative References 460 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 461 Label Switched (MPLS) Data Plane Failures", RFC 4379, 462 February 2006. 464 12.2. Informative References 466 [ID.sr-4379ext] 467 IETF, "Label Switched Path (LSP) Ping/Trace for Segment 468 Routing Networks Using MPLS Dataplane", IETF, 469 http://datatracker.ietf.org/doc/ 470 draft-kumar-mpls-spring-lsp-ping/, 2013. 472 [ID.sr-archi] 473 IETF, "Segment Routing Architecture", IETF, 474 https://datatracker.ietf.org/doc/draft-filsfils-spring- 475 segment-routing/, 2014. 477 [ID.sr-isis] 478 IETF, "IS-IS Extensions for Segment Routing", IETF, 479 http://datatracker.ietf.org/doc/ 480 draft-previdi-isis-segment-routing-extensions/, 2014. 482 [ID.sr-oam_detect] 483 IETF, "Detecting Multi-Protocol Label Switching (MPLS) 484 Data Plane Failures in Source Routed LSPs", IETF, 485 http://datatracker.ietf.org/doc/ 486 draft-kini-spring-mpls-lsp-ping/, 2013. 488 [ID.sr-use] 489 IETF, "Segment Routing Use Cases", IETF, 490 http://datatracker.ietf.org/doc/ 491 draft-filsfils-rtgwg-segment-routing-use-cases/, 2013. 493 Authors' Addresses 495 Ruediger Geib (editor) 496 Deutsche Telekom 497 Heinrich Hertz Str. 3-7 498 Darmstadt 64295 499 Germany 501 Phone: +49 6151 5812747 502 Email: Ruediger.Geib@telekom.de 504 Clarence Filsfils 505 Cisco Systems, Inc. 506 Brussels 507 Belgium 509 Email: cfilsfil@cisco.com 511 Carlos Pignataro 512 Cisco Systems, Inc. 513 7200 Kit Creek Road 514 Research Triangle Park, NC 27709-4987 515 US 517 Email: cpignata@cisco.com 518 Nagendra Kumar 519 Cisco Systems, Inc. 520 7200 Kit Creek Road 521 Research Triangle Park, NC 27709 522 US 524 Email: naikumar@cisco.com