--- 1/draft-ietf-spring-oam-usecase-03.txt 2016-10-20 13:16:07.311059265 -0700 +++ 2/draft-ietf-spring-oam-usecase-04.txt 2016-10-20 13:16:07.335059858 -0700 @@ -1,21 +1,21 @@ spring R. Geib, Ed. Internet-Draft Deutsche Telekom Intended status: Informational C. Filsfils -Expires: October 24, 2016 C. Pignataro, Ed. +Expires: April 23, 2017 C. Pignataro, Ed. N. Kumar Cisco - April 22, 2016 + October 20, 2016 A Scalable and Topology-Aware MPLS Dataplane Monitoring System - draft-ietf-spring-oam-usecase-03 + draft-ietf-spring-oam-usecase-04 Abstract This document describes features of a path monitoring system and related use cases. Segment based routing enables a scalable and simple method to monitor data plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS ping and LSP trace, in a very complementary way. MPLS topology awareness reduces management and control plane involvement of OAM measurements while enabling new OAM @@ -29,21 +29,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 24, 2016. + This Internet-Draft will expire on April 23, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -51,89 +51,90 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. An MPLS Topology-Aware Path Monitoring System . . . . . . . . 4 - 4. SR-based Path Monitoring Use Case Illustration . . . . . . . 5 + 4. SR-based Path Monitoring Use Case Illustration . . . . . . . 6 4.1. Use Case 1 - LSP Dataplane Monitoring . . . . . . . . . . 6 4.2. Use Case 2 - Monitoring a Remote Bundle . . . . . . . . . 8 - 4.3. Use Case 3 - Fault Localization . . . . . . . . . . . . . 8 + 4.3. Use Case 3 - Fault Localization . . . . . . . . . . . . . 9 5. Failure Notification from PMS to LERi . . . . . . . . . . . . 9 - 6. Applying SR to Monitoring LDP Paths . . . . . . . . . . . . . 9 - 7. PMS Monitoring of Different Segment ID Types . . . . . . . . 9 + 6. Applying SR to Monitoring non-SR based LSPs (LDP and possibly + RSVP-TE) . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 7. PMS Monitoring of Different Segment ID Types . . . . . . . . 10 8. Connectivity Verification Using PMS . . . . . . . . . . . . . 10 9. Extensions of Specifications Relevant to this Use Case . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . 11 13.2. Informative References . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Acronyms ECMP Equal-Cost Multi-Path IGP Interionr Gateway Protocol LER Label Edge Router LSP Label Switched Path LSR Label Switching Router OAM Operations, Administration, and Maintenance PMS Path Monitoring System SID Segment Identifier SR Segment Routing SRGB Segment Routing Global Block 2. Introduction It is essential for a network operator to monitor all the forwarding - paths observed by the transported user packets. The monitoring flow - is expected to be forwarded in dataplane in a similar way as user - packets. Segment Routing enables forwarding of packets along pre- - defined paths and segments and thus a Segment Routed monitoring + paths observed by the transported user packets. The monitoring + packet is expected to be forwarded in dataplane in a similar way as + user packets. Segment Routing enables forwarding of packets along + pre-defined paths and segments and thus a Segment Routed monitoring packet can stay in dataplane while passing along one or more segments to be monitored. - This document describes illustrates a system using MPLS data plane - path monitoring capabilities. The use case introduced here is - limited to a single IGP MPLS domain. + This document describes a system using MPLS data plane path + monitoring capabilities. The use cases introduced here is limited to + a single IGP MPLS domain. The system applies to monitoring of LDP LSP's as well as to monitoring of Segment Routed LSP's. As compared to LDP, Segment Routing is expected to simplify the system by enabling MPLS topology detection based on IGP signaled segments as specified at [I-D.ietf-isis-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions]. Thus a centralised and MPLS topology aware monitoring unit can be realized in a Segment Routed domain. This topology awareness can be used for OAM purposes as described by this document. The MPLS path monitoring system described by this document can be - realised with pre-Segment based Routing (SR) technology. Making such - a pre-SR MPLS monitoring system aware of a domains complete MPLS + realised with pre-Segment Routing (SR) based technology. Making such + a pre-SR MPLS monitoring system aware of a domain's complete MPLS topology requires e.g. management plane access. To avoid the use of stale MPLS label information, IGP must be monitored and MPLS topology must be timely aligned with IGP topology. Obviously, enhancing IGPs to exchange of MPLS topology information as done by SR significantly simplifies and stabilises such an MPLS path monitoring system. This document adopts the terminology and framework described in [I-D.ietf-spring-segment-routing]. The system offers several benefits for network monitoring. A single centralized monitoring device is able to monitor the complete set of - a domains forwarding paths. Monitoring packets never leave data + a domain's forwarding paths. Monitoring packets never leave data plane. MPLS path trace function (whose specification and features are not part of this use case) is required, if the actual data plane of a router should be checked against its control plane. SR capabilities allow to direct MPLS OAM packets from a centralized monitoring system to any router within a domain whose path should be traced. In addition to monitoring paths, problem localization is required. Faults can be localized: @@ -141,70 +142,72 @@ o correlation between different SR based monitoring probes. o by any MPLS traceroute method (possibly in combination with SR based path stacks). Topology awareness is an essential part of link state IGPs. Adding MPLS topology awareness to an IGP speaking device hence enables a simple and scalable data plane based monitoring mechanism. - MPLS OAM offers flexible features to recognise an execute data paths + MPLS OAM offers flexible features to recognise and execute data paths of an MPLS domain. By utilising the ECMP related tool set offered e.g. by RFC 4379 [RFC4379], a segment based routing LSP monitoring system may: o easily detect ECMP functionality and properties of paths at data level. o construct monitoring packets executing desired paths also if ECMP is present. o limit the MPLS label stack of an OAM packet to a minmum of 3 labels. Alternatively, any path may be executed by building suitable label stacks. This allows path execution without ECMP awareness. - The MPLS path monitoring system may be a any server residing at a + The MPLS Path Monitoring System (PMS) may be any server residing at a single interface of the domain to be monitored. It doesn't have to support any specialised protocol stack, it just should be capable of - understanding the topology and building the probe packet with the - right segment stack. As long as measurement packets return to this - or another interface connecting such a server, the MPLS monitoring - servers are the single entities pushing monitoring packet label - stacks. If the depth of label stacks to be pushed by a path - monitoring system (PMS) are of concern for a domain, a dedicated - server based path monitoring architecture allows limiting monitoring - related label stack pushes to these servers. + understanding the topology and building the monitoring probe packet + with the right segment stack. The monitoring probe packet could be + BFD or LSP Ping packet or any other OAM format that PMS supports. As + long as the monitoring packet returns back to the server, the path + can be considered as validated. The MPLS monitoring servers are the + single entities pushing monitoring packet label stacks. If the depth + of label stacks to be pushed by a path monitoring system (PMS) are of + concern for a domain, a dedicated server based path monitoring + architecture allows limiting monitoring related label stack pushes to + these servers. Documents discussing SR OAM requirements and possible solutions to allow SR usage as described by this document have been submitted already, see [I-D.ietf-spring-sr-oam-requirement] and - [I-D.kumarkini-mpls-spring-lsp-ping]. + [I-D.ietf-mpls-spring-lsp-ping]. 3. An MPLS Topology-Aware Path Monitoring System An MPLS PMS which is able to learn the IGP LSDB (including the SID's) is able to execute arbitrary chains of label switched paths. It can send pure monitoring packets along such a path chain or it can direct suitable MPLS OAM packets to any node along a path segment. Segment Routing here is used as a means of adding label stacks and hence transport to standard MPLS OAM packets, which then detect correspondence of control and data plane of this (or any other addressed) path. Any node connected to an SR domain is MPLS topology aware (the node knows all related IP addresses, SR SIDs and MPLS labels). Thus a PMS connected to an MPLS SR domain just needs to set up a topology data base for monitoring purposes. Let us describe how the PMS constructs a labels stack to transport a - packet to LER i, monitor the path of it to LER j and then receive the + packet to LER i, monitor its path to LER j and then receive the packet back. The PMS may do so by sending packets carrying the following MPLS label stack infomation: o Top Label: a path from PMS to LER i, which is expressed as Node SID of LER i. o Next Label: the path that needs to be monitored from LER i to LER j. If this path is a single physical interface (or a bundle of @@ -220,26 +223,28 @@ o Next Label or address: the path back to the PMS. Likely, no further segment/label is required here. Indeed, once the packet reaches LER j, the 'steering' part of the solution is done and the probe just needs to return to the PMS. This is best achieved by popping the MPLS stack and revealing a probe packet with PMS as destination address (note that in this case, the source and destination addresses could be the same). If an IP address is applied, no SID/label has to be assigned to the PMS (if it is a host/server residing in an IP subnet outside the MPLS domain). - Note: if the PMS is an IP host not connected to the MPLS domain, the - PMS can send its probe with the list of SIDs/Labels onto a suitable - tunnel providing an MPLS access to a router which is part of the - monitored MPLS domain. + Note: a deployment might prefer not to connect the PMS to the MPLS + domain. if the PMS is an IP host not connected to the MPLS domain, + the PMS can send its probe with the list of SIDs/Labels onto a + suitable tunnel providing an MPLS access to a router which is part of + the monitored MPLS domain. 4. SR-based Path Monitoring Use Case Illustration + 4.1. Use Case 1 - LSP Dataplane Monitoring +---+ +----+ +-----+ |PMS| |LSR1|-----|LER i| +---+ +----+ +-----+ | / \ / | / \__/ +-----+/ /| |LER m| / | +-----+\ / \ @@ -284,21 +289,21 @@ First algorithm based path. o If ECMP is deployed, it may be desired to measure along both possible paths which a packet may use between LER i and LER j. To do so, the MPLS OAM mechanism chosen to detect ECMP must reveal the required information (an example is a so called tree trace) between LER i and LER j. This method of dealing with ECMP based load balancing paths requires the smallest SR label stacks if monitoring of paths is applied after the tree trace completion. - o The path LER j to PMS to must be available. This path must be + o The path LER j to PMS must be available. This path must be detectable, but it is usually sufficient to apply an SPF based path. Once the MPLS paths (Node SIDs) and the required information to deal with ECMP has been detected, the paths of LER i to LER j can be monitored by the PMS. Monitoring itself does not require MPLS OAM functionality. All monitoring packets stay on dataplane, hence path monitoring does no longer require control plane interaction in any LER or LSR of the domain. To ensure reliable results, the PMS should be aware of any changes in IGP or MPLS topology. Further changes in @@ -323,22 +328,28 @@ could also be dedicated monitoring system. If measurement system reliability is an issue, more than a single PMS may be connected to the MPLS domain. Monitoring an MPLS domain by a PMS based on SR offers the option of monitoring complete MPLS domains with little effort and very excellent scalability. Data plane failure detection by circulating monitoring packets can be executed at any time. The PMS further could be enabled to send MPLS OAM packets with the label stacks and address information identical to those of the monitoring packets to - any node of the MPLS domain. It does not require access to LSR/LER - management interfaces or their control plane to do so. + any node of the MPLS domain. Prior to monitoring a path, MPLS OAM + may be used to detect ECMP dependant forwarding of a packet. A PMS + may be designed to learn the IP address information required to + execute a particular ECMP routed path and interfaces along that path. + This allows to monitor these paths with label stacks reduced to a + limited number of Node-SIDs resulting from SPF routing. The PMS does + not require access to LSR/LER management interfaces or their control + plane to do so. 4.2. Use Case 2 - Monitoring a Remote Bundle +---+ _ +--+ +-------+ | | { } | |---991---L1---662---| | |PMS|--{ }-|R1|---992---L2---663---|R2 (72)| | | {_} | |---993---L3---664---| | +---+ +--+ +-------+ SR based probing of all the links of a remote bundle @@ -386,37 +398,41 @@ 5. Failure Notification from PMS to LERi PMS on detecting any failure in the path liveliness may use any out- of-band mechanism to signal the failure to LER i. This document does not propose any specific mechanism and operators can choose any existing or new approach. Alternately, the Operator may log the failure in local monitoring system and take necessary action by manual intervention. -6. Applying SR to Monitoring LDP Paths +6. Applying SR to Monitoring non-SR based LSPs (LDP and possibly RSVP- + TE) A SR based PMS connected to a MPLS domain consisting of LER and LSR - supporting SR and LDP in parallel in all nodes may use SR paths to - transmit packets to and from start and end points of LDP paths to be - monitored. In the above example, the label stack top to bottom may - be as follows, when sent by the PMS: + supporting SR and LDP or RSVP-TE in parallel in all nodes may use SR + paths to transmit packets to and from start and end points of non-SR + based LSP paths to be monitored. In the above example, the label + stack top to bottom may be as follows, when sent by the PMS: o Top: SR based Node-SID of LER i at LER m. - o Next: LDP label identifying the path to LER j at LER i. + o Next: LDP or RSVP-TE label identifying the path to LER j at LER i. o Bottom: SR based Node-SID identifying the path to the PMS at LER j While the mixed operation shown here still requires the PMS to be - aware of the LER LDP-MPLS topology, the PMS may learn the SR MPLS - topology by IGP and use this information. + aware of the LER LDP-MPLS or RSVP-TE topology, the PMS may learn the + SR MPLS topology by IGP and use this information. + + An implementation report on a PMS operating in an LDP domain is given + in [I-D.leipnitz-spring-pms-implementation-report]. 7. PMS Monitoring of Different Segment ID Types MPLS SR topology awareness should allow the SID to monitor liveliness of most types of SIDs (this may not be recommendable if a SID identifies an inter domain interface). To match control plane information with data plane information, MPLS OAM functions as defined for example by RFC 4379 [RFC4379] should be enhanced to allow collection of data relevant to check all relevant @@ -457,65 +473,74 @@ never use stale MPLS or IGP routing information. Further, assigning different label ranges for different purposes may be useful. A well known global service level range may be excluded for utilisation within PMS measurement packets. These ideas shouldn't start a discussion. They rather should point out, that such a discussion is required when SR based OAM mechanisms like a SR are standardised. 12. Acknowledgements The authors would like to thank Nobo Akiya for his contribution. - Raik Leipnitz kindly provided an editorial review. + Raik Leipnitz kindly provided an editorial review. The authors would + also like to thank Faisal Iqbal for an insightful review and a useful + set of comments and suggestions. 13. References 13.1. Normative References [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, DOI 10.17487/RFC4379, February 2006, . 13.2. Informative References [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., - Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS - Extensions for Segment Routing", draft-ietf-isis-segment- - routing-extensions-06 (work in progress), December 2015. + Litkowski, S., Decraene, B., and j. jefftant@gmail.com, + "IS-IS Extensions for Segment Routing", draft-ietf-isis- + segment-routing-extensions-08 (work in progress), October + 2016. + + [I-D.ietf-mpls-spring-lsp-ping] + Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini, + S., Gredler, H., and M. Chen, "Label Switched Path (LSP) + Ping/Trace for Segment Routing Networks Using MPLS + Dataplane", draft-ietf-mpls-spring-lsp-ping-00 (work in + progress), May 2016. [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", draft-ietf-ospf-segment- - routing-extensions-07 (work in progress), March 2016. + routing-extensions-09 (work in progress), July 2016. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf- - spring-segment-routing-07 (work in progress), December - 2015. + spring-segment-routing-09 (work in progress), July 2016. [I-D.ietf-spring-sr-oam-requirement] Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., and S. Litkowski, "OAM Requirements for Segment Routing - Network", draft-ietf-spring-sr-oam-requirement-01 (work in - progress), December 2015. + Network", draft-ietf-spring-sr-oam-requirement-02 (work in + progress), July 2016. - [I-D.kumarkini-mpls-spring-lsp-ping] - Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini, - S., Gredler, H., and M. Chen, "Label Switched Path (LSP) - Ping/Trace for Segment Routing Networks Using MPLS - Dataplane", draft-kumarkini-mpls-spring-lsp-ping-06 (work - in progress), March 2016. + [I-D.leipnitz-spring-pms-implementation-report] + Leipnitz, R. and R. Geib, "A scalable and topology aware + MPLS data plane monitoring system", draft-leipnitz-spring- + pms-implementation-report-00 (work in progress), June + 2016. Authors' Addresses + Ruediger Geib (editor) Deutsche Telekom Heinrich Hertz Str. 3-7 Darmstadt 64295 Germany Phone: +49 6151 5812747 Email: Ruediger.Geib@telekom.de Clarence Filsfils