idnits 2.17.1 draft-geib-spring-oam-usecase-04.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 (March 5, 2015) is 3337 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. -------------------------------------------------------------------------------- 1 spring R. Geib, Ed. 2 Internet-Draft Deutsche Telekom 3 Intended status: Informational C. Filsfils 4 Expires: September 6, 2015 C. Pignataro 5 N. Kumar 6 Cisco Systems, Inc. 7 March 5, 2015 9 Use case for a scalable and topology aware MPLS data plane monitoring 10 system 11 draft-geib-spring-oam-usecase-04 13 Abstract 15 This document describes features and a use case of a path monitoring 16 system. Segment based routing enables a scalable and simple method 17 to monitor data plane liveliness of the complete set of paths 18 belonging to a single domain. Compared with legacy MPLS ping and 19 path trace, MPLS topology awareness reduces management and control 20 plane involvement of OAM measurements while enabling new OAM 21 features. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 6, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. An MPLS topology aware path monitoring system . . . . . . . . 4 59 3. SR based path monitoring use case illustration . . . . . . . 5 60 3.1. Use-case 1 - LSP dataplane monitoring . . . . . . . . . . 5 61 3.2. Use-case 2 - Monitoring a remote bundle . . . . . . . . . 7 62 3.3. Use-Case 3 - Fault localization . . . . . . . . . . . . . 8 63 4. Failure Notification from PMS to LERi . . . . . . . . . . . . 8 64 5. Applying SR to monitor LDP paths . . . . . . . . . . . . . . 9 65 6. PMS monitoring of different Segment ID types . . . . . . . . 9 66 7. Connectivity Verification using PMS . . . . . . . . . . . . . 9 67 8. Extensions of related standards helpful for this use case . . 10 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 12.2. Informative References . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 It is essential for a network operator to monitor all the forwarding 79 paths observed by the transported user packets. The monitoring flow 80 is expected to be forwarded in dataplane in a similar way as user 81 packets. Segment Routing enables forwarding of packets along pre- 82 defined paths and segments and thus a Segment Routed monitoring 83 packet can stay in dataplane while passing along one or more segments 84 to be monitored. 86 This document describes illustrates use-cases based on data plane 87 path monitoring capabilities. The use case is limited to a single 88 IGP MPLS domain. 90 The use case applies to monitoring of LDP LSP's as well as to 91 monitoring of Segment Routed LSP's. As compared to LDP, Segment 92 Routing is expected to simplify the use case by enabling MPLS 93 topology detection based on IGP signaled segments as specified by 94 [ID.sr-isis]. Thus a centralised and MPLS topology aware monitoring 95 unit can be realized in a Segment Routed domain. This topology 96 awareness can be used for OAM purposes as described by this use case. 97 The MPLS path monitoring system described by this document can be 98 realised with pre-Segment based Routing (SR) technology. Making such 99 a pre-SR MPLS monitoring system aware of a domains complete MPLS 100 topology requires e.g. management plane access. To avoid the use of 101 stale MPLS label information, IGP must be monitored and MPLS topology 102 must be timely aligned with IGP topology. Obviously, enhancing IGPs 103 to exchange of MPLS topology information as done by SR significantly 104 simplifies and stabilises such an MPLS path monitoring system. 106 This document adopts the terminology and framework described in 107 [ID.sr-archi]. It further adopts the editorial simplification 108 explained in section 1.2 of the segment routing use-cases 109 [ID.sr-use]. 111 The use case offers several benefits for network monitoring. A 112 single centralized monitoring device is able to monitor the complete 113 set of a domains forwarding paths. Monitoring packets never leave 114 data plane. MPLS path trace function (whose specification and 115 features are not part of this use case) is required, if the actual 116 data plane of a router should be checked against its control plane. 117 SR capabilities allow to direct MPLS OAM packets from a centralized 118 monitoring system to any router within a domain whose path should be 119 traced. 121 In addition to monitoring paths, problem localization is required. 122 Faults can be localized: 124 o by IGP LSA analysis. 126 o correlation between different SR based monitoring probes. 128 o by any MPLS traceroute method (possibly in combination with SR 129 based path stacks). 131 Topology awareness is an essential part of link state IGPs. Adding 132 MPLS topology awareness to an IGP speaking device hence enables a 133 simple and scalable data plane based monitoring mechanism. 135 MPLS OAM offers flexible features to recognise an execute data paths 136 of an MPLS domain. By utilsing the ECMP related tool set offered 137 e.g. by RFC 4379 [RFC4379], a segment based routing LSP monitoring 138 system may: 140 o easily detect ECMP functionality and properties of paths at data 141 level. 143 o construct monitoring packets executing desired paths also if ECMP 144 is present. 146 o limit the MPLS label stack of an OAM packet to a minmum of 3 147 labels. 149 Alternatively, any path may be executed by building suitable label 150 stacks. This allows path execution without ECMP awareness. 152 The MPLS path monitoring system may be a any server residing at a 153 single interface of the domain to be monitored. It doesn't have to 154 support any specialised protocol stack, it just should be capable of 155 understanding the topology and building the probe packet with the 156 right segment stack. As long as measurement packets return to this 157 or another interface connecting such a server, the MPLS monitoring 158 servers are the single entities pushing monitoring packet label 159 stacks. If the depth of label stacks to be pushed by a PMS are of 160 concern for a domain, a dedicated server based path monitoring 161 architecture allows limiting monitoring related label stack pushes to 162 these servers. 164 First drafts discussing SR OAM requirements and possible solutions to 165 allow SR usage as described by this document have been submitted 166 already, see [ID.sr-4379ext] and [ID.sr-oam_detect]. 168 2. An MPLS topology aware path monitoring system 170 An MPLS path monitoring system (PMS) which is able to learn the IGP 171 LSDB (including the SID's) is able to execute arbitrary chains of 172 label switched paths. It can send pure monitoring packets along such 173 a path chain or it can direct suitable MPLS OAM packets to any node 174 along a path segment. Segment Routing here is used as a means of 175 adding label stacks and hence transport to standard MPLS OAM packets, 176 which then detect correspondence of control and data plane of this 177 (or any other addressed) path. Any node connected to an SR domain is 178 MPLS topology aware (the node knows all related IP addresses, SR SIDs 179 and MPLS labels). Thus a PMS connected to an MPLS SR domain just 180 needs to set up a topology data base for monitoring purposes. 182 Let us describe how the PMS constructs a labels stack to transport a 183 packet to LER i, monitor the path of it to LER j and then receive the 184 packet back. 186 The PMS may do so by sending packets carrying the following MPLS 187 label stack infomation: 189 o Top Label: a path from PMS to LER i This is expressed as Node SID 190 of LER i. 192 o Next Label: the path that needs to be monitored from LER i to LER 193 j. If this path is a single physical interface (or a bundle of 194 connected interfaces), it can be expressed by the related AdjSID. 195 If the shortest path from LER i to LER j is supposed to be 196 monitored, the Node-SID (LER j) can be used. Another option is to 197 insert a list of segments expressing the desired path (hop by hop 198 as an extreme case). If LER i pushes a stack of Labels based on a 199 SR policy decision and this stack of LSPs is to be monitored, the 200 PMS needs an interface to collect the information enabling it to 201 address this SR created path. 203 o Next Label or address: the path back to the PMS. Likely, no 204 further segment/label is required here. Indeed, once the packet 205 reaches LER j, the 'steering' part of the solution is done and the 206 probe just needs to return to the PMS. This is best achieved by 207 popping the MPLS stack and revealing a probe packet with PMS as 208 destination address (note that in this case, the source and 209 destination addresses could be the same). If an IP address is 210 applied, no SID/label has to be assigned to the PMS (if it is a 211 host/server residing in an IP subnet outside the MPLS domain). 213 Note: if the PMS is an IP host not connected to the MPLS domain, the 214 PMS can send its probe with the list of SIDs/Labels onto a suitable 215 tunnel providing an MPLS access to a router which is part of the 216 monitored MPLS domain. 218 3. SR based path monitoring use case illustration 220 3.1. Use-case 1 - LSP dataplane monitoring 222 +---+ +----+ +-----+ 223 |PMS| |LSR1|-----|LER i| 224 +---+ +----+ +-----+ 225 | / \ / 226 | / \__/ 227 +-----+/ /| 228 |LER m| / | 229 +-----+\ / \ 230 \ / \ 231 \+----+ +-----+ 232 |LSR2|-----|LER j| 233 +----+ +-----+ 235 Example of a PMS based LSP dataplane monitoring 237 Figure 1 239 For the sake of simplicity, let's assume that all the nodes are 240 configured with the same SRGB [ID.sr-archi], as described by section 241 1.2 of [ID.sr-use]. 243 Let's assign the following Node SIDs to the nodes of the figure: PMS 244 = 10, LER i = 20, LER j = 30. 246 To be able to work with the smallest possible SR label stack, first A 247 suitable MPLS OAM method is used to detect the ECMP routed path 248 between LER i to LER j which is to be monitored (and the required 249 address information to direct a packet along it). Afterwards the PMS 250 sets up and sends packets to monitor availability of the detected 251 path. The PMS does this by creating a measurement packet with the 252 following label stack (top to bottom): 20 - 30 - 10. The packet will 253 only reliably use the monitored path, if the label and address 254 information used in combination with the MPLS OAM method of choice is 255 identical to that of the monitoring packet. 257 LER m forwards the packet received from the PMS to LSR1. Assuming 258 Pen-ultimate Hop Popping to be deployed, LSR1 pops the top label and 259 forwards the packet to LER i. There the top label has a value 30 and 260 LER i forwards it to LER j. This will be done transmitting the 261 packet via LSR1 or LSR2. The LSR will again pop the top label. LER 262 j will forward the packet now carrying the top label 10 to the PMS 263 (and it will pass a LSR and LER m). 265 A few observations on the example given in figure 1: 267 o The path PMS to LER i must be available. This path must be 268 detectable, but it is usually sufficient to apply an SPF based 269 path. 271 o If ECMP is deployed, it may be desired to measure along both 272 possible paths which a packet may use between LER i and LER j. To 273 do so, the MPLS OAM mechanism chosen to detect ECMP must reveal 274 the required information (an example is a so called tree trace) 275 between LER i and LER j. This method of dealing with ECMP based 276 load balancing paths requires the smallest SR label stacks if 277 monitoring of paths is applied after the tree trace completion. 279 o The path LER j to PMS to must be available. This path must be 280 detectable, but it is usually sufficient to apply an SPF based 281 path. 283 Once the MPLS paths (Node SIDs) and the required information to deal 284 with ECMP has been detected, the paths of LER i to LER j can be 285 monitored by the PMS. Monitoring itself does not require MPLS OAM 286 functionality. All monitoring packets stay on dataplane, hence path 287 monitoring does no longer require control plane interaction in any 288 LER or LSR of the domain. To ensure reliable results, the PMS should 289 be aware of any changes in IGP or MPLS topology. Further changes in 290 ECMP functionality at LER i will impact results. Either the PMS 291 should be notified of such changes or they should be limited to 292 planned maintenance. After a topology change, a suitable MPLS OAM 293 mechanism may be useful to detect the impact of the change. 295 Determining a path to be executed prior to a measurement may also be 296 done by setting up a label stack including all Node SIDs along that 297 path (if LSR1 has Node SID 40 in the example and it should be passed 298 between LER i and LER j, the label stack is 20 - 40 - 30 - 10). The 299 advantage of this method is, that it does not involve MPLS OAM 300 functionality and it is independent of ECMP functionalities. The 301 method still is able to monitor all link combinations of all paths of 302 an MPLS domain. If correct forwarding along the desired paths has to 303 be checked, some suitable MPLS OAM mechanism may be applied also in 304 this case. 306 In theory at least, a single PMS is able to monitor data plane 307 availability of all LSPs in the domain. The PMS may be a router, but 308 could also be dedicated monitoring system. If measurement system 309 reliability is an issue, more than a single PMS may be connected to 310 the MPLS domain. 312 Monitoring an MPLS domain by a PMS based on SR offers the option of 313 monitoring complete MPLS domains with little effort and very 314 excellent scalability. Data plane failure detection by circulating 315 monitoring packets can be executed at any time. The PMS further 316 could be enabled to send MPLS OAM packets with the label stacks and 317 address information identical to those of the monitoring packets to 318 any node of the MPLS domain. It does not require access to LSR/LER 319 management interfaces or their control plane to do so. 321 3.2. Use-case 2 - Monitoring a remote bundle 323 +---+ _ +--+ +-------+ 324 | | { } | |---991---L1---662---| | 325 |PMS|--{ }-|R1|---992---L2---663---|R2 (72)| 326 | | {_} | |---993---L3---664---| | 327 +---+ +--+ +-------+ 329 SR based probing of all the links of a remote bundle 331 Figure 2 333 R1 addresses Lx by the Adjacency SID 99x, while R2 addresses Lx by 334 the Adjacency SID 66(x+1). 336 In the above figure, the PMS needs to assess the dataplane 337 availability of all the links within a remote bundle connected to 338 routers R1 and R2. 340 The monitoring system retrieves the SID/Label information from the 341 IGP LSDB and appends the following segment list/label stack: {72, 342 662, 992, 664} on its IP probe (whose source and destination 343 addresses are the address of the PMS). 345 MS sends the probe to its connected router. If the connected router 346 is not SR compliant, a tunneling technique can be used to tunnel the 347 probe and its MPLS stack to the first SR router. The MPLS/SR domain 348 then forwards the probe to R2 (72 is the Node SID of R2). R2 349 forwards the probe to R1 over link L1 (Adjacency SID 662). R1 350 forwards the probe to R2 over link L2 (Adjacency SID 992). R2 351 forwards the probe to R1 over link L3 (Adjacency SID 664). R1 then 352 forwards the IP probe to PMS as per classic IP forwarding. 354 3.3. Use-Case 3 - Fault localization 356 In the previous example, a uni-directional fault on the middle link 357 from R1 to R2 would be localized by sending the following two probes 358 with respective segment lists: 360 o 72, 662, 992, 664 362 o 72, 663, 992, 664 364 The first probe would fail while the second would succeed. 365 Correlation of the measurements reveals that the only difference is 366 using the Adjacency SID 662 of the middle link from R1 to R2 in the 367 non successful measurement. Assuming the second probe has been 368 routed correctly, the fault must have been occurring in R2 which 369 didn't forward the packet to the interface identified by its 370 Adjacency SID 662. 372 4. Failure Notification from PMS to LERi 374 PMS on detecting any failure in the path liveliness may use any out- 375 of-band mechanism to signal the failure to LER i. This document does 376 not propose any specific mechanism and operators can choose any 377 existing or new approach. 379 Alternately, the Operator may log the failure in local monitoring 380 system and take necessary action by manual intervention. 382 5. Applying SR to monitor LDP paths 384 A SR based PMS connected to a MPLS domain consisting of LER and LSR 385 supporting SR and LDP in parallel in all nodes may use SR paths to 386 transmit packets to and from start and end points of LDP paths to be 387 monitored. In the above example, the label stack top to bottom may 388 be as follows, when sent by the PMS: 390 o Top: SR based Node-SID of LER i at LER m. 392 o Next: LDP label identifying the path to LER j at LER i. 394 o Bottom: SR based Node-SID identifying the path to the PMS at LER j 396 While the mixed operation shown here still requires the PMS to be 397 aware of the LER LDP-MPLS topology, the PMS may learn the SR MPLS 398 topology by IGP and use this information. 400 6. PMS monitoring of different Segment ID types 402 MPLS SR topology awareness should allow the SID to monitor liveliness 403 of most types of SIDs (this may not be recommendable if a SID 404 identifies an inter domain interface). 406 To match control plane information with data plane information, MPLS 407 OAM functions as defined by e.g. RFC4379 should be enhanced to allow 408 collection of data relevant to check all relevant types of Segment 409 IDs. 411 7. Connectivity Verification using PMS 413 While the PMS based use cases explained in Section 3 are sufficient 414 to provide continuity check between LER i and LER j, it may not help 415 perform connectivity verification. So in some cases like data plane 416 programming corruption, it is possible that a transit node between 417 LER i and LER j erroneously removes the top segment ID and forwards a 418 monitoring packet to the PMS based on the bottom segment ID leading 419 to a falsified path liveliness indication by the PMS. 421 There are various method to perform basic connectivity verification 422 like intermittely setting the TTL to 1 in bottom label so LER j 423 selectively perform connectivity verification. Other methods are 424 possible and may be added when requirements and solutions are 425 specified. 427 8. Extensions of related standards helpful for this use case 429 The following activities are welcome enhancements supporting this use 430 case, but they are not part of it: 432 RFC4379 functions should be extended to support Flow- and Entropy 433 Label based ECMP. 435 9. IANA Considerations 437 This memo includes no request to IANA. 439 10. Security Considerations 441 As mentioned in the introduction, a PMS monitoring packet should 442 never leave the domain where it originated. It therefore should 443 never use stale MPLS or IGP routing information. Further, assigning 444 different label ranges for different purposes may be useful. A well 445 known global service level range may be excluded for utilisation 446 within PMS measurement packets. These ideas shouldn't start a 447 discussion. They rather should point out, that such a discussion is 448 required when SR based OAM mechanisms like a SR are standardised. 450 11. Acknowledgement 452 The authors would like to thank Nobo Akiya for his contribution. 454 12. References 456 12.1. Normative References 458 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 459 Label Switched (MPLS) Data Plane Failures", RFC 4379, 460 February 2006. 462 12.2. Informative References 464 [ID.sr-4379ext] 465 IETF, "Label Switched Path (LSP) Ping/Trace for Segment 466 Routing Networks Using MPLS Dataplane", IETF, 467 http://datatracker.ietf.org/doc/ 468 draft-kumar-mpls-spring-lsp-ping/, 2013. 470 [ID.sr-archi] 471 IETF, "Segment Routing Architecture", IETF, 472 https://datatracker.ietf.org/doc/draft-filsfils-spring- 473 segment-routing/, 2014. 475 [ID.sr-isis] 476 IETF, "IS-IS Extensions for Segment Routing", IETF, 477 http://datatracker.ietf.org/doc/ 478 draft-previdi-isis-segment-routing-extensions/, 2014. 480 [ID.sr-oam_detect] 481 IETF, "Detecting Multi-Protocol Label Switching (MPLS) 482 Data Plane Failures in Source Routed LSPs", IETF, 483 http://datatracker.ietf.org/doc/ 484 draft-kini-spring-mpls-lsp-ping/, 2013. 486 [ID.sr-use] 487 IETF, "Segment Routing Use Cases", IETF, 488 http://datatracker.ietf.org/doc/ 489 draft-filsfils-rtgwg-segment-routing-use-cases/, 2013. 491 Authors' Addresses 493 Ruediger Geib (editor) 494 Deutsche Telekom 495 Heinrich Hertz Str. 3-7 496 Darmstadt 64295 497 Germany 499 Phone: +49 6151 5812747 500 Email: Ruediger.Geib@telekom.de 502 Clarence Filsfils 503 Cisco Systems, Inc. 504 Brussels 505 Belgium 507 Email: cfilsfil@cisco.com 509 Carlos Pignataro 510 Cisco Systems, Inc. 511 7200 Kit Creek Road 512 Research Triangle Park, NC 27709-4987 513 US 515 Email: cpignata@cisco.com 516 Nagendra Kumar 517 Cisco Systems, Inc. 518 7200 Kit Creek Road 519 Research Triangle Park, NC 27709 520 US 522 Email: naikumar@cisco.com