idnits 2.17.1 draft-geib-spring-oam-usecase-00.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 (October 17, 2013) is 3841 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ID.sr-architecture' is defined on line 253, but no explicit reference was found in the text ** 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 October 17, 2013 4 Expires: April 20, 2014 6 Use case for a scalable and topology aware MPLS data plane monitoring 7 system 8 draft-geib-spring-oam-usecase-00 10 Abstract 12 This document describes features and a use case of a path monitoring 13 system. Segment based routing enables a scalbale and simple method 14 to monitor data plane liveliness of the complete set of paths 15 belonging to a single domain. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 20, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. A topology aware MPLS path monitoring system . . . . . . . . . 4 53 3. Applying SR to monitor LDP paths . . . . . . . . . . . . . . . 5 54 4. PMS monitoring of different Segment ID types . . . . . . . . . 6 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 59 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 1. Introduction 64 Paths looping packets through a network are not desireable for 65 network and user data routing. The ability to execute arbitrary path 66 combinations within a domain offers several benefits for network 67 monitoring. A single monitoring device is able to monitor the 68 complete set of a domains forwarding paths with OAM packets never 69 leaving data plane. This requires topology awareness as well as a 70 suitable security architecture. Topology awareness is an essential 71 part of link state IGPs. Adding MPLS topology awareness to an IGP 72 speaking device hence enables a simple and scaleable data plane 73 monitoring mechanism. 75 The design of such a monitoring system should ensure that OAM packets 76 never leave the domain they are supposed to monitor. Topology and 77 network state awareness are useful, careful address-selection may be 78 another one. 80 MPLS OAM offers flexible features to recognise an execute data paths 81 of an MPLS domain. By utilsing the ECMP related tool set of RFC 4379 82 [RFC4379], a segment based routing LSP monitoring system may: 84 o easily detect ECMP functionality and properties of paths at data 85 level. 87 o construct monitoring packets executing desired paths also if ECMP 88 is present. 90 o limit the MPLS label stack of an OAM packet to a minmum of 3 91 labels. 93 IPv6 related ECMP path detection and execution for OAM purposes is 94 less powerful than that offered by MPLS OAM. This document is 95 foscused on MPLS path monitoring. 97 The MPLS path monitoring system described by this document can be 98 realised with pre-Segment based Routing (SR) technology. Making 99 monitoring system aware of a domains complete MPLS topolfrom 100 utilising stale MPLS label information, IGP must be monitored and 101 MPLS topology must be timely aligned with IGP topology. Obviously, 102 enhancing IGPs to exchange of MPLS topology information significantly 103 simplifies and stabilises such an MPLS path monitoring system. In 104 addition to IGP extensions, also RFC 4379 may have to be extended to 105 support detection of SR routed paths. 107 Note that the MPLS path monitoring system may be a specialised system 108 residing at a single interface of the domain to be monitored. As 109 long as measurement packets return to this or another well specified 110 interface, the MPLS monitoring system is the single entity pushing 111 monitoring packet label stacks. Concerns about router label stack 112 pushing capabilities don't apply in this case. 114 2. A topology aware MPLS path monitoring system 116 A MPLS path monitoring system (PMS) which is able to learn all 117 labeled paths of a domain is able to build a measurement packet which 118 executes an arbitrary chain of paths. Such a monitoring system is 119 aware of the MPLS topology. The task is to check liveliness of the 120 MPLS transport path between LER i and LER j. The PMS may do so by 121 sending packets carrying the following minimum address infomation: 123 o Top Label: connected LSRs path to LER i. 125 o Next Label: LER i's path to LER j. 127 o Next Label or address: Data plane measurement destination at LER j 128 (this could be a label or an IP address) 130 Note that the label stack could as well address MPLS node after MPLS 131 node passed by the measurtement packet on it's path from PMS to the 132 packets destination or any address stack between this maximum and the 133 above minimum address information. Further, the destination could be 134 the PSM itself. This is shown in figure. 136 +---+ +----+ +-----+ 137 |PMS| |LSR1|-----|LER i| 138 +---+ +----+ +-----+ 139 | / \ / 140 | / \__/ 141 +-----+/ /| 142 |LER m| / | 143 +-----+\ / \ 144 \ / \ 145 \+----+ +-----+ 146 |LSR2|-----|LER j| 147 +----+ +-----+ 149 Example of a PMS based LSP dataplane liveness measurement 151 Figure 1 153 For the sake of simplicity, let's assume a global Node-Segment ID 154 label space (meaning the value of a label never changes during a 155 label swap). Let's assign the following Node SIDs to the nodes of 156 the figure: PMS = 10, LER i = 20, LER j = 30. 158 The aim is to check liveliness of the path LER i to LER j. The PMS 159 does this by creating a measurement packet with the following label 160 stack (top to bottom): 20 - 30 - 10. 162 LER m forwards the packet received from the PMS to LSR1. Assuming 163 Pen-ultimate Hop Popping to be deployed, LSR1 pops the top label and 164 forwards the packet to LER i. There the top label has a value 30 and 165 LER i forwards it to LER j. This will be done transmitting the 166 packet via LSR1 or LSR2. The LSR will again pop the top label. LER 167 j will forward the packet now carrying the top label 10 to the PMS 168 (and it will pass a LSR and LER m). 170 A few observations on the example: 172 o The path PMS to LER i must be stable and it must be detectable. 174 o If ECMP is deployed, it may be desired to measure along both 175 possible paths, a packet may use between LER i and LER j. This 176 may be done by using MPLS OAM coded measurement packets with 177 suitable IP destination addresses. 179 o The path LER j to PMS to must be stable and it must be detectable. 181 To ensure reliable results, the PMS should be aware of any changes in 182 IGP or MPLS topology. 184 Determining a path to be executed prior to a measurement may also be 185 done by setting up a label including all node SIDs along that path 186 (if LER1 has Node SID 40 in the example and it should be passed 187 between LER i and LER j, the label stack is 20 - 40 - 30 - 10). 189 Obviously, the PMS is able to check and monitor data plane liveliness 190 of all LSPs in the domain. The PMS may be a router, but could also 191 be dedicated monitoring system. If measurement system reliability is 192 an issue, more than a single PMS may be connected to the MPLS domain. 194 Monitoring an MPLS domain by a PMS based on SR offers the option of 195 monitoring complete MPLS domains with little effort and very 196 excellent scaleability. 198 3. Applying SR to monitor LDP paths 200 A SR based PMS connected to a MPLS domain consisting of LER and LSR 201 supporting SR and LDP in parrallel in all nodes may use SR paths to 202 transmit packets to and from start and end points of LDP paths to be 203 monitored. In the above example, the label stack top to bottom may 204 be as follows, when sent by the PMS: 206 o Top: SR based Node-SID of LER i at LER m. 208 o Next: LDP label identifying the path to LER j at LER i. 210 o Bottom: SR based Node-SID identifying the path to the PMS at LER j 212 While the mixed operation shown here still requires the PMS to be 213 aware of the LER LDP-MPLS topology, the PMS may learn the SR MPLS 214 topology by IGP and use this information. 216 4. PMS monitoring of different Segment ID types 218 MPLS SR topology awareness should allow the SID to monitor liveliness 219 of most types of SIDs (this may not be recommendable if a SID 220 identifies an inter domain interface). 222 To match control plane information with data palne information, 223 RFC4379 should be enhaced to allow collection of data relevant to 224 check all relevant types of Segment IDs. 226 5. IANA Considerations 228 This memo includes no request to IANA. 230 6. Security Considerations 232 As mentioned in the introduction, a PMS monitoring packet should 233 never leave the domain where it originated. It therefore should 234 never use stale MPLS or IGP routing information. Further, asigning 235 different label ranges for different purposes may be useful. A well 236 known global service level range may be excluded for utilisation 237 within PMS measurement packets. These ideas shoulddn't start a 238 discussion. They rather should point out, that such a discussion is 239 required when SR based OAM mechanisms like a SR are standardised. 241 7. References 243 7.1. Normative References 245 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 246 Label Switched (MPLS) Data Plane Failures", RFC 4379, 247 February 2006. 249 [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 251 7.2. Informative References 253 [ID.sr-architecture] 254 IETF, "Segment Routing Architecture", IETF, https:// 255 datatracker.ietf.org/doc/ 256 draft-filsfils-rtgwg-segment-routing/, 2013. 258 Author's Address 260 Ruediger Geib (editor) 261 Deutsche Telekom 262 Heinrich Hertz Str. 3-7 263 Darmstadt, 64295 264 Germany 266 Phone: +49 6151 5812747 267 Email: Ruediger.Geib@telekom.de