draft-ietf-spring-oam-usecase-10.txt   rfc8403.txt 
spring R. Geib, Ed. Internet Engineering Task Force (IETF) R. Geib, Ed.
Internet-Draft Deutsche Telekom Request for Comments: 8403 Deutsche Telekom
Intended status: Informational C. Filsfils Category: Informational C. Filsfils
Expires: June 21, 2018 C. Pignataro, Ed. ISSN: 2070-1721 C. Pignataro, Ed.
N. Kumar N. Kumar
Cisco Systems, Inc. Cisco Systems, Inc.
December 18, 2017 July 2018
A Scalable and Topology-Aware MPLS Dataplane Monitoring System A Scalable and Topology-Aware MPLS Data-Plane Monitoring System
draft-ietf-spring-oam-usecase-10
Abstract Abstract
This document describes features of an MPLS path monitoring system This document describes features of an MPLS path monitoring system
and related use cases. Segment based routing enables a scalable and and related use cases. Segment-based routing enables a scalable and
simple method to monitor data plane liveliness of the complete set of simple method to monitor data-plane liveliness of the complete set of
paths belonging to a single domain. The MPLS monitoring system adds paths belonging to a single domain. The MPLS monitoring system adds
features to the traditional MPLS Ping and LSP Trace, in a very features to the traditional MPLS ping and Label Switched Path (LSP)
complementary way. MPLS topology awareness reduces management and trace, in a very complementary way. MPLS topology awareness reduces
control plane involvement of OAM measurements while enabling new OAM management and control-plane involvement of Operations,
features. Administration, and Maintenance (OAM) measurements while enabling new
OAM features.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on June 21, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8403.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 5 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
3. An MPLS Topology-Aware Path Monitoring System . . . . . . . . 6 3. An MPLS Topology-Aware Path Monitoring System . . . . . . . . 6
4. SR-based Path Monitoring Use Case Illustration . . . . . . . 7 4. Illustration of an SR-Based Path Monitoring Use Case . . . . 8
4.1. Use Case 1 - LSP Dataplane Monitoring . . . . . . . . . . 7 4.1. Use Case 1: LSP Data-Plane Monitoring . . . . . . . . . . 8
4.2. Use Case 2 - Monitoring a Remote Bundle . . . . . . . . . 10 4.2. Use Case 2: Monitoring a Remote Bundle . . . . . . . . . 11
4.3. Use Case 3 - Fault Localization . . . . . . . . . . . . . 11 4.3. Use Case 3: Fault Localization . . . . . . . . . . . . . 12
5. Path Trace and Failure Notification . . . . . . . . . . . . . 12 5. Path Trace and Failure Notification . . . . . . . . . . . . . 12
6. Applying SR to Monitoring non-SR based LSPs (LDP and possibly 6. Applying SR to Monitoring LSPs That Are Not SR Based (LDP and
RSVP-TE) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Possibly RSVP-TE) . . . . . . . . . . . . . . . . . . . . . . 13
7. PMS Monitoring of Different Segment ID Types . . . . . . . . 13 7. PMS Monitoring of Different Segment ID Types . . . . . . . . 14
8. Connectivity Verification Using PMS . . . . . . . . . . . . . 14 8. Connectivity Verification Using PMS . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Network operators need to be able to monitor the forwarding paths Network operators need to be able to monitor the forwarding paths
used to transport user packets. Monitoring packets are expected to used to transport user packets. Monitoring packets are expected to
be forwarded in dataplane in a similar way as user packets. Segment be forwarded in the data plane in a similar way to user packets.
Routing enables forwarding of packets along pre-defined paths and Segment Routing (SR) enables forwarding of packets along predefined
segments and thus a Segment Routed monitoring packet can stay in paths and segments; thus, an SR monitoring packet can stay in the
dataplane while passing along one or more segments to be monitored. data plane while passing along one or more segments to be monitored.
This document describes a system as a functional component called This document describes a system as a functional component called
(MPLS) Path Monitoring System, PMS. The PMS is using MPLS data plane (MPLS) Path Monitoring System or PMS. The PMS uses capabilities for
path monitoring capabilities. The use cases introduced here are MPLS data-plane path monitoring. The use cases introduced here are
limited to a single Interior Gateway Protocol (IGP) MPLS domain. The limited to a single Interior Gateway Protocol (IGP) MPLS domain. The
use cases of this document refer to the PMS system realised as a use cases of this document refer to the PMS realized as a separate
separate node. Although many use cases depict the PMS as a physical node. Although many use cases depict the PMS as a physical node, no
node, no assumption should be made, and the node could be virtual. assumption should be made, and the node could be virtual. This
This system is defined as a functional component abstracted to have system is defined as a functional component abstracted to have many
many realizations. The terms PMS and system are used interchangeably realizations. The terms "PMS" and "system" are used interchangeably
in the following. here.
The system applies to monitoring of non Segment Routing Label The system applies to the monitoring of non-SR LSPs like Label
Switched Paths (LSP's) like Label Distribution Protocol (LDP) as well Distribution Protocol (LDP) as well as to the monitoring of SR LSPs
as to monitoring of Segment Routed LSP's (section 7 offers some more (Section 7 offers some more information). As compared to non-SR
information). As compared to non Segment Routing approaches, Segment approaches, SR is expected to simplify such a monitoring system by
Routing is expected to simplify such a monitoring system by enabling enabling MPLS topology detection based on IGP-signaled segments. The
MPLS topology detection based on IGP signaled segments. The MPLS MPLS topology should be detected and correlated with the IGP
topology should be detected and correlated with the IGP topology, topology, which is also detected by IGP signaling. Thus, a
which is too detected by IGP signaling. Thus a centralized and MPLS centralized and MPLS-topology-aware monitoring unit can be realized
topology aware monitoring unit can be realized in a Segment Routed in an SR domain. This topology awareness can be used for Operation,
domain. This topology awareness can be used for Operation,
Administration, and Maintenance (OAM) purposes as described by this Administration, and Maintenance (OAM) purposes as described by this
document. document.
Benefits offered by the system: Benefits offered by the system:
o The system described here allows to set up an SR domain wide o The ability to set up an SR-domain-wide centralized connectivity
centralized connectivity validation. Many operators of large validation. Many operators of large networks regard a centralized
networks regard centralized monitoring system as useful.. monitoring system as useful.
o The MPLS Ping (or continuity check) packets never leave the MPLS o The MPLS ping (or continuity check) packets never leave the MPLS
user data plane. user data plane.
o SR allows the transport of MPLS path trace or connectivity o SR allows the transport of MPLS path trace or connectivity
validation packets for every Label Switched Path to all nodes of validation packets for every LSP to all nodes of an SR domain.
an SR domain. This use case doesn't describe new path trace This use case doesn't describe new path-trace features. The
features. The system described here allows to set up an SR domain system described here allows for the set up of an SR-domain-wide
wide centralized connectivity validation, which is useful in large centralized connectivity validation, which is useful in large
network operator domains. network operator domains.
o The system sending the monitoring packet is also receiving it. o The system sending the monitoring packet is also receiving it.
The payload of the monitoring packet may be chosen freely. This The payload of the monitoring packet may be chosen freely. This
allows sending probing packets which represent customer traffic, allows probing packets to be sent that represent customer traffic,
possibly from multiple services (e.g., small Voice over IP packet, possibly from multiple services (e.g., small Voice over IP
larger HTTP packets) and embedding of useful monitoring data packets, larger HTTP packets), and allows the embedding of useful
(e.g., accurate time stamps since both sender and receiver have monitoring data (e.g., accurate timestamps since both sender and
the same clock and sequence numbers to ease the measurement...). receiver have the same clock and sequence numbers to ease the
measurement).
o Set up of a flexible MPLS monitoring system in terms of o Set up of a flexible MPLS monitoring system in terms of
deployment: from one single centralized one to a set of deployment: from one single centralized one to a set of
distributed systems (e.g., on a per region or service base), and distributed systems (e.g., on a per-region or service basis), and
in terms of redundancy from 1+1 to N+1. in terms of redundancy from 1+1 to N+1.
In addition to monitoring paths, problem localization is required. In addition to monitoring paths, problem localization is required.
Topology awareness is an important feature of link state IGPs Topology awareness is an important feature of link-state IGPs
deployed by operators of large networks. MPLS topology awareness deployed by operators of large networks. MPLS topology awareness
combined with IGP topology awareness enables a simple and scalable combined with IGP topology awareness enables a simple and scalable
data plane based monitoring mechanism. Faults can be localized: data-plane-based monitoring mechanism. Faults can be localized:
o by capturing the Interior Gateway Protocol (IGP) topology and o by capturing the IGP topology and analyzing IGP messages
analyzing IGP messages indicating changes of it. indicating changes of it.
o by correlation between different SR based monitoring probes. o by correlation between different SR-based monitoring probes.
o by setting up an MPLS traceroute packet for a path (or Segment) to o by setting up an MPLS traceroute packet for a path (or segment) to
be tested and transporting it to a node to validate path be tested and transporting it to a node to validate path
connectivity from that node on. connectivity from that node on.
MPLS OAM offers flexible traceroute (connectivity verification) MPLS OAM offers flexible traceroute (connectivity verification)
features to detect and execute data paths of an MPLS domain. By features to detect and execute data paths of an MPLS domain. By
utilizing the Equal Cost Multipath (ECMP) related tool set offered, utilizing the ECMP-related tool set offered, e.g., by RFC 8029
e.g., by RFC 8029 [RFC8029], a SR based MPLS monitoring system can be [RFC8029], an SR-based MPLS monitoring system can be enabled to:
enabled to:
o detect how to route packets along different ECMP routed paths. o detect how to route packets along different ECMP-routed paths.
o construct Ping packets, which can be steered to paths whose o Construct ping packets that can be steered along a single path or
connectivity is to be checked, also if ECMP is present. ECMP towards a particular LER/LSR whose connectivity is to be
checked.
o limit the MPLS label stack of such a Ping packet checking o limit the MPLS label stack of such a ping packet, checking
continuity of every single IGP-Segment to the maximum number of 3 continuity of every single IGP segment to the maximum number of 3
labels. A smaller label stack may also be helpful, if any router labels. A smaller label stack may also be helpful, if any router
interprets a limited number of packet header bytes to determine an interprets a limited number of packet header bytes to determine an
ECMP path along which to route a packet. ECMP along which to route a packet.
Alternatively, any path may be executed by building suitable label Alternatively, any path may be executed by building suitable label
stacks. This allows path execution without ECMP awareness. stacks. This allows path execution without ECMP awareness.
The MPLS Path Monitoring System may be any server residing at a The MPLS PMS may be any server residing at a single interface of the
single interface of the domain to be monitored. The PMS doesn't need domain to be monitored. The PMS doesn't need to support the complete
to support the complete MPLS routing or control plane. It needs to MPLS routing or control plane. It needs to be capable of learning
be capable to learn and maintain an accurate MPLS and IGP topology. and maintaining an accurate MPLS and IGP topology. MPLS ping and
MPLS Ping and traceroute packets need to be set up and sent with the traceroute packets need to be set up and sent with the correct
correct segment stack. The PMS further must be able to receive and segment stack. The PMS must further be able to receive and decode
decode returning Ping or Traceroute packets. Packets from a variety returning ping or traceroute packets. Packets from a variety of
of protocols can be used to check continuity. These include Internet protocols can be used to check continuity. These include Internet
Control Message Protocol [RFC0792] [RFC4443] [RFC4884] [RFC4950], Control Message Protocol (ICMP) [RFC0792] [RFC4443] [RFC4884]
Bidirectional Forwarding Detection (BFD) [RFC5884], Seamless [RFC4950], Bidirectional Forwarding Detection (BFD) [RFC5884],
Bidirectional Forwarding Detection (S-BFD) [RFC7880] [RFC7881] (see Seamless Bidirectional Forwarding Detection (S-BFD) [RFC7880]
Section 3.4 of [RFC7882]), and MPLS LSP Ping [RFC8029]. They can [RFC7881] (see Section 3.4 of [RFC7882]), and MPLS LSP ping
also have any other OAM format supported by the PMS. As long as the [RFC8029]. They can also have any other OAM format supported by the
packet used to check continuity returns back to the server while no PMS. As long as the packet used to check continuity returns to the
IGP change is detected, the monitored path can be considered as server while no IGP change is detected, the monitored path can be
validated. If monitoring requires pushing a large label stack, a considered as validated. If monitoring requires pushing a large
software based implementation is usually more flexible than an label stack, a software-based implementation is usually more flexible
hardware based one. Hence router label stack depth and label than a hardware-based one. Hence, router label stack depth and label
composition limitations don't limit MPLS OAM choices. composition limitations don't limit MPLS OAM choices.
[I-D.ietf-mpls-spring-lsp-ping] discusses SR OAM applicability and RFC 8287 [RFC8287] discusses SR OAM applicability and MPLS traceroute
MPLS traceroute enhancements adding functionality to the use cases enhancements adding functionality to the use cases described by this
described by this document. document.
The document describes both use cases and a standalone monitoring The document describes both use cases and a standalone monitoring
framework. The monitoring system re-uses existing IETF OAM protocols framework. The monitoring system reuses existing IETF OAM protocols
and leverage Segment Routing (Source Routing) to allow a single and leverage Segment Routing (Source Routing) to allow a single
device to send, have exercised, and receive its own probing packets. device to send, have exercised, and receive its own probing packets.
As a consequence, there are no new interoperability considerations. As a consequence, there are no new interoperability considerations.
Standard Track is not required and Informational status is A Standards Track RFC is not required; Informational status for this
appropriate document is appropriate
2. Terminology and Acronyms 2. Terminology and Abbreviations
2.1. Terminology 2.1. Terminology
Continuity Check Continuity Check
is defined in Section 2.2.7 of RFC 7276 [RFC7276]. See Section 2.2.7 of RFC 7276 [RFC7276].
Connectivity Verification Connectivity Verification
is defined in Section 2.2.7 of RFC 7276 [RFC7276]. See Section 2.2.7 of RFC 7276 [RFC7276].
MPLS topology MPLS topology
The MPLS topology of an MPLS domain is the complete set of MPLS- The MPLS topology of an MPLS domain is the complete set of MPLS-
and IP-address information and all routing and data plane and IP-address information and all routing and data-plane
information required to address and utilize every MPLS path information required to address and utilize every MPLS path
within this domain from an MPLS Path Monitoring System attached within this domain from an MPLS PMS attached to this MPLS domain
to this MPLS domain at an arbitrary access. This document at an arbitrary access. This document assumes availability of
assumes availability of the MPLS topology (which can be detected the MPLS topology (which can be detected with available protocols
with available protocols and interfaces). None of the use cases and interfaces). None of the use cases will describe how to set
will describe how to set it up. it up.
This document further adopts the terminology and framework described This document further adopts the terminology and framework described
in [I-D.ietf-spring-segment-routing]. in [RFC8402].
2.2. Acronyms 2.2. Abbreviations
ECMP Equal-Cost Multi-Path ECMP Equal-Cost Multipath
IGP Interior Gateway Protocol IGP Interior Gateway Protocol
LER Label Edge Router LER Label Edge Router
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router LSR Label Switching Router
OAM Operations, Administration, and Maintenance OAM Operations, Administration, and Maintenance
PMS Path Monitoring System PMS Path Monitoring System
skipping to change at page 6, line 14 skipping to change at page 6, line 35
LER Label Edge Router LER Label Edge Router
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router LSR Label Switching Router
OAM Operations, Administration, and Maintenance OAM Operations, Administration, and Maintenance
PMS Path Monitoring System PMS Path Monitoring System
RSVP-TE Resource ReserVation Protocol-Traffic Engineering RSVP-TE Resource Reservation Protocol - Traffic Engineering
SID Segment Identifier SID Segment Identifier
SR Segment Routing SR Segment Routing
SRGB Segment Routing Global Block SRGB Segment Routing Global Block
3. An MPLS Topology-Aware Path Monitoring System 3. An MPLS Topology-Aware Path Monitoring System
Any node at least listening to the IGP of an SR domain is MPLS Any node at least listening to the IGP of an SR domain is MPLS
topology aware (the node knows all related IP addresses, SR SIDs and topology aware (the node knows all related IP addresses, SR SIDs and
MPLS labels). An MPLS PMS which is able to learn the IGP LSDB MPLS labels). An MPLS PMS that is able to learn the IGP Link State
(including the SID's) is able to execute arbitrary chains of label Database (LSDB) (including the SIDs) is able to execute arbitrary
switched paths. To monitor an MPLS SR domain, a PMS needs to set up chains of LSPs. To monitor an MPLS SR domain, a PMS needs to set up
a topology data base of the MPLS SR domain to be monitored. It may a topology database of the MPLS SR domain to be monitored. It may be
be used to send ping type packets to only check continuity along such used to send ping-type packets to only check continuity along such a
a path chain based on the topology information only. In addition, path chain based only on the topology information. In addition, the
the PMS can be used to trace MPLS Label Switched Path and thus verify PMS can be used to trace MPLS LSP and, thus, verify their
their connectivity and correspondence between control and data plane, connectivity and correspondence between control and data planes,
respectively. The PMS can direct suitable MPLS traceroute packets to respectively. The PMS can direct suitable MPLS traceroute packets to
any node along a path segment. any node along a path segment.
Let us describe how the PMS constructs a labels stack to transport a Let us describe how the PMS constructs a label stack to transport a
packet to LER i, monitor its path to LER j and then receive the packet to LER i, monitor its path to LER j, and then receive the
packet back. packet back.
The PMS may do so by sending packets carrying the following MPLS The PMS may do so by sending packets carrying the following MPLS
label stack information: label stack information:
o Top Label: a path from PMS to LER i, which is expressed as Node o Top Label: a path from PMS to LER i, which is expressed as Node-
SID of LER i. SID of LER i.
o Next Label: the path that needs to be monitored from LER i to LER 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 j. If this path is a single physical interface (or a bundle of
connected interfaces), it can be expressed by the related connected interfaces), it can be expressed by the related Adj-SID.
Adjacency-SID. If the shortest path from LER i to LER j is If the shortest path from LER i to LER j is supposed to be
supposed to be monitored, the Node-SID (LER j) can be used. monitored, the Node-SID (LER j) can be used. Another option is to
insert a list of segments expressing the desired path (hop by hop
Another option is to insert a list of segments expressing the as an extreme case). If LER i pushes a stack of labels based on
desired path (hop by hop as an extreme case). If LER i pushes a an SR policy decision and this stack of LSPs is to be monitored,
stack of Labels based on a SR policy decision and this stack of the PMS needs an interface to collect the information enabling it
LSPs is to be monitored, the PMS needs an interface to collect the to address this SR-created path.
information enabling it to address this SR created path.
o Next Label or address: the path back to the PMS. Likely, no o Next Label or address: the path back to the PMS. Likely, no
further segment/label is required here. Indeed, once the packet further segment/label is required here. Indeed, once the packet
reaches LER j, the 'steering' part of the solution is done and the reaches LER j, the 'steering' part of the solution is done, and
probe just needs to return to the PMS. This is best achieved by the probe just needs to return to the PMS. This is best achieved
popping the MPLS stack and revealing a probe packet with PMS as by popping the MPLS stack and revealing a probe packet with PMS as
destination address (note that in this case, the source and destination address (note that in this case, the source and
destination addresses could be the same). If an IP address is 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 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). host/server residing in an IP subnet outside the MPLS domain).
The PMS should be physically connected to a router which is part of The PMS should be physically connected to a router that is part of
the SR domain. It must be able to send and receive MPLS packets via the SR domain. It must be able to send and receive MPLS packets via
this interface. As mentioned above, routing protocol support isn't this interface. As mentioned above, the routing protocol support
required and the PMS itself doesn't have to be involved in IGP or isn't required, and the PMS itself doesn't have to be involved in IGP
MPLS routing. A static route will do. The option to connect a PMS or MPLS routing. A static route will do. The option to connect a
to an MPLS domain by a tunnel may be attractive to some operators. PMS to an MPLS domain by a tunnel may be attractive to some
MPLS so far separates networks securely by avoiding tunnel access to operators. So far, MPLS separates networks securely by avoiding
MPLS domains. Tunnel based access of a PMS to an MPLS domain is out tunnel access to MPLS domains. Tunnel-based access of a PMS to an
of scope of this document, as it implies additional security aspects. MPLS domain is out of scope of this document, as it implies
additional security aspects.
4. SR-based Path Monitoring Use Case Illustration 4. Illustration of an SR-Based Path Monitoring Use Case
4.1. Use Case 1 - LSP Dataplane Monitoring 4.1. Use Case 1: LSP Data-Plane Monitoring
Figure 1 shows an example of this functional component as a system, Figure 1 shows an example of this functional component as a system,
which can be physical or virtual. which can be physical or virtual.
+---+ +----+ +-----+ +---+ +----+ +-----+
|PMS| |LSR1|-----|LER i| |PMS| |LSR1|-----|LER i|
+---+ +----+ +-----+ +---+ +----+ +-----+
| / \ / | / \ /
| / \__/ | / \__/
+-----+/ /| +-----+/ /|
|LER m| / | |LER m| / |
+-----+\ / \ +-----+\ / \
\ / \ \ / \
\+----+ +-----+ \+----+ +-----+
|LSR2|-----|LER j| |LSR2|-----|LER j|
+----+ +-----+ +----+ +-----+
Example of a PMS based LSP dataplane monitoring
Figure 1 Figure 1: Example of a PMS-Based LSP Data-Plane Monitoring
For the sake of simplicity, let's assume that all the nodes are For the sake of simplicity, let's assume that all the nodes are
configured with the same SRGB [I-D.ietf-spring-segment-routing]. configured with the same SRGB [RFC8402].
Let's assign the following Node SIDs to the nodes of the figure: PMS Let's assign the following Node-SIDs to the nodes of the figure:
= 10, LER i = 20, LER j = 30. PMS = 10, LER i = 20, LER j = 30.
The aim is to set up a continuity check of the path between LER i and The aim is to set up a continuity check of the path between LER i and
LER j. As has been said, the monitoring packets are to be sent and LER j. As has been said, the monitoring packets are to be sent and
received by the PMS. Let's assume the design aim is to be able to received by the PMS. Let's assume the design aim is to be able to
work with the smallest possible SR label stack. In the given work with the smallest possible SR label stack. In the given
topology, a fairly simple option is to perform an MPLS path trace, as topology, a fairly simple option is to perform an MPLS path trace, as
specified by RFC 8029 [RFC8029] (using the Downstream (Detailed) specified by RFC 8029 [RFC8029] (using the Downstream (Detailed)
Mapping information resulting from a path trace). The starting point Mapping information resulting from a path trace). The starting point
for the path trace is LER i and the PMS sends the MPLS path trace for the path trace is LER i and the PMS sends the MPLS path trace
packet to LER i. The MPLS echo reply of LER i should be sent to the packet to LER i. The MPLS echo reply of LER i should be sent to the
PMS. As a result, IP destination address choices are detected, which PMS. As a result, the IP destination address choices are detected,
are then used to target any one of the ECMP routed paths between LER which are then used to target any one of the ECMP-routed paths
i and LER j by the MPLS ping packets to later check path continuity. between LER i and LER j by the MPLS ping packets to later check path
The Label stack of these ping packets doesn't need to consist of more continuity. The label stack of these ping packets doesn't need to
than 3 labels. Finally, the PMS sets up and sends packets to monitor consist of more than 3 labels. Finally, the PMS sets up and sends
connectivity of the ECMP routed paths. The PMS does this by creating packets to monitor connectivity of the ECMP routed paths. The PMS
a measurement packet with the following label stack (top to bottom): does this by creating a measurement packet with the following label
20 - 30 - 10. The ping packets reliably use the monitored path, if stack (top to bottom): 20 - 30 - 10. The ping packets reliably use
the IP-address information which has been detected by the MPLS trace the monitored path, if the IP-address information that has been
route is used as the IP destination address (note that this IP detected by the MPLS traceroute is used as the IP destination address
address isn't used or required for any IP routing). (note that this IP address isn't used or required for any IP
routing).
LER m forwards the packet received from the PMS to LSR1. Assuming LER m forwards the packet received from the PMS to LSR1. Assuming
Pen-ultimate Hop Popping to be deployed, LSR1 pops the top label and Penultimate Hop Popping is deployed, LSR1 pops the top label and
forwards the packet to LER i. There the top label has a value 30 and forwards the packet to LER i. There the top label has a value 30 and
LER i forwards it to LER j. This will be done transmitting the LER i forwards it to LER j. This will be done transmitting the
packet via LSR1 or LSR2. The LSR will again pop the top label. LER packet via LSR1 or LSR2. The LSR will again pop the top label. LER
j will forward the packet now carrying the top label 10 to the PMS j will forward the packet now carrying the top label 10 to the PMS
(and it will pass a LSR and LER m). (and it will pass a LSR and LER m).
A few observations on the example given in figure 1: A few observations on the example given in Figure 1:
o The path PMS to LER i must be available (i.e., a continuity check o The path from PMS to LER i must be available (i.e., a continuity
only along the path to LER i must succeed). If desired, an MPLS check along the path to LER i must succeed). If desired, an MPLS
trace route may be used to exactly detect the data plane path traceroute may be used to exactly detect the data-plane path taken
taken for this MPLS Segment. It is usually sufficient to just for this MPLS segment. It is usually sufficient to just apply any
apply any of the existing Shortest Path routed paths. of the existing Shortest Path routed paths.
o If ECMP is deployed, separate continuity checks monitoring all o If ECMP is deployed, separate continuity checks monitoring all
possible paths which a packet may use between LER i and LER j may possible paths that a packet may use between LER i and LER j may
be desired. This can be done by applying an MPLS trace route be desired. This can be done by applying an MPLS traceroute
between LER i and LER j. Another option is to use SR routing, but between LER i and LER j. Another option is to use SR, but this
this will likely require additional label information within the will likely require additional label information within the label
label stack of the ping packet. Further, if multiple links are stack of the ping packet. Further, if multiple links are deployed
deployed between two nodes, SR methods to address each individual between two nodes, SR methods to address each individual path
path require an Adj-SID to be assigned to each single interface. require an Adj-SID to be assigned to each single interface. This
This method is based on control plane information - a connectivity method is based on control-plane information -- a connectivity
verification based on MPLS traceroute seems to be a fairly good verification based on MPLS traceroute seems to be a fairly good
option to deal with ECMP and validation of control and data plane option to deal with ECMP and validation of correlation between
correlation. control and data planes.
o The path LER j to PMS must be available (i.e., a continuity check o The path LER j to PMS must be available (i.e., a continuity check
only along the path from LER j to PMS must succeed). If desired, only along the path from LER j to PMS must succeed). If desired,
an MPLS trace route may be used to exactly detect the data plane an MPLS traceroute may be used to exactly detect the data-plane
path taken for this MPLS Segment. It is usually sufficient to path taken for this MPLS segment. It is usually sufficient to
just apply any of the existing Shortest Path routed paths. just apply any of the existing Shortest Path routed paths.
Once the MPLS paths (Node-SIDs) and the required information to deal Once the MPLS paths (Node-SIDs) and the required information to deal
with ECMP have been detected, the path continuity between LER i and with ECMP have been detected, the path continuity between LER i and
LER j can be monitored by the PMS. Path continuity monitoring by LER j can be monitored by the PMS. Path continuity monitoring by
ping packets does not require RFC 8029 [RFC8029] MPLS OAM ping packets does not require the MPLS OAM functionality described in
functionality. All monitoring packets stay on dataplane, hence path RFC 8029 [RFC8029]. All monitoring packets stay on the data plane;
continuity monitoring does not require control plane interaction in hence, path continuity monitoring does not require control-plane
any LER or LSR of the domain. To ensure consistent interpretation of interaction in any LER or LSR of the domain. To ensure consistent
the results, the PMS should be aware of any changes in IGP or MPLS interpretation of the results, the PMS should be aware of any changes
topology or ECMP routing. While the description given here in IGP or MPLS topology or ECMP routing. While this document
pronouncing path connectivity checking as a simple basic application, describes path connectivity checking as a basic application,
others like checking continuity of underlying physical infrastructure additional monitoring (like checking continuity of underlying
or delay measurements may be desired. In both cases, a change in physical infrastructure or performing delay measurements) may be
ECMP routing which is not caused by an IGP or MPLS topology change desired. A change in ECMP routing that is not caused by an IGP or
may not be desirable. A PMS therefore should also periodically MPLS topology change may not be desirable for connectivity checks and
verify connectivity of the SR paths which are monitored for delay measurements. Therefore, a PMS should also periodically verify
continuity. connectivity of the SR paths that are monitored for continuity.
Determining a path to be executed prior to a measurement may also be Determining a path to be executed prior to a measurement may also be
done by setting up a label stack including all Node-SIDs along that done by setting up a label stack including all Node-SIDs along that
path (if LSR1 has Node SID 40 in the example and it should be passed path (if LSR1 has Node-SID 40 in the example and it should be passed
between LER i and LER j, the label stack is 20 - 40 - 30 - 10). The between LER i and LER j, the label stack is 20 - 40 - 30 - 10). The
advantage of this method is, that it does not involve RFC 8029 advantage of this method is that it does not involve connectivity
[RFC8029] connectivity verification and, if there's only one physical verification as specified in RFC 8029 [RFC8029] and, if there's only
connection between all nodes, the approach is independent of ECMP one physical connection between all nodes, the approach is
functionalities. The method still is able to monitor all link independent of ECMP functionalities. The method still is able to
combinations of all paths of an MPLS domain. If correct forwarding monitor all link combinations of all paths of an MPLS domain. If
along the desired paths has to be checked, or multiple physical correct forwarding along the desired paths has to be checked, or
connections exist between any two nodes, all Adj-SIDs along that path multiple physical connections exist between any two nodes, all Adj-
should be part of the label stack. SIDs along that path should be part of the label stack.
While a single PMS can detect the complete MPLS control and data While a single PMS can detect the complete MPLS control- and data-
plane topology, a reliable deployment requires two separated PMS. plane topology, a reliable deployment requires two separated PMSs.
Scalable permanent surveillance of a set of LSPs could require Scalable permanent surveillance of a set of LSPs could require
deployment of several PMS. The PMS may be a router, but could also deployment of several PMSs. The PMS may be a router, but could also
be dedicated monitoring system. If measurement system reliability is be a dedicated monitoring system. If measurement system reliability
an issue, more than a single PMS may be connected to the MPLS domain. 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 an MPLS domain by a PMS based on SR offers the option of
monitoring complete MPLS domains with limited effort and a unique monitoring complete MPLS domains with limited effort and a unique
possibility to scale a flexible monitoring solution as required by possibility to scale a flexible monitoring solution as required by
the operator (the number of PMS deployed is independent of the the operator (the number of PMSs deployed is independent of the
locations of the origin and destination of the monitored paths). The locations of the origin and destination of the monitored paths). The
PMS can be enabled to send MPLS OAM packets with the label stacks and PMS can be enabled to send MPLS OAM packets with the label stacks and
address information identical to those of the monitoring packets to address information identical to those of the monitoring packets to
any node of the MPLS domain. The routers of the monitored domain any node of the MPLS domain. The routers of the monitored domain
should support MPLS LSP Ping RFC 8029 [RFC8029]. They may also should support MPLS LSP ping RFC 8029 [RFC8029]. They may also
incorporate the additional enhancements defined in incorporate the additional enhancements defined in RFC 8287 [RFC8287]
[I-D.ietf-mpls-spring-lsp-ping] to incorporate further MPLS trace to incorporate further MPLS traceroute features. ICMP-ping-based
route features. ICMP Ping based continuity checks don't require continuity checks don't require router-control-plane activity. Prior
router control plane activity. Prior to monitoring a path, MPLS OAM to monitoring a path, MPLS OAM may be used to detect ECMP-dependent
may be used to detect ECMP dependent forwarding of a packet. A PMS forwarding of a packet. A PMS may be designed to learn the IP
may be designed to learn the IP address information required to address information required to execute a particular ECMP-routed path
execute a particular ECMP routed path and interfaces along that path. and interfaces along that path. This allows for the monitoring of
This allows to monitor these paths with label stacks reduced to a these paths with label stacks reduced to a limited number of Node-
limited number of Node-SIDs resulting from SPF routing. The PMS does SIDs resulting from Shortest Path First (SPF) routing. The PMS does
not require access to LSR / LER management- or data-plane information not require access to information about LSR/LER management or data
to do so. planes to do so.
4.2. Use Case 2: Monitoring a Remote Bundle
4.2. Use Case 2 - Monitoring a Remote Bundle
+---+ _ +--+ +-------+ +---+ _ +--+ +-------+
| | { } | |---991---L1---662---| | | | { } | |---991---L1---662---| |
|PMS|--{ }-|R1|---992---L2---663---|R2 (72)| |PMS|--{ }-|R1|---992---L2---663---|R2 (72)|
| | {_} | |---993---L3---664---| | | | {_} | |---993---L3---664---| |
+---+ +--+ +-------+ +---+ +--+ +-------+
SR based probing of all the links of a remote bundle Figure 2: SR-Based Probing of All the Links of a Remote Bundle
Figure 2
In the figure, R1 addresses Link "x" Lx by the Adjacency SID 99x, In the figure, R1 addresses Link "x" Lx by the Adj-SID 99x, while R2
while R2 addresses Link Lx by the Adjacency SID 66(x+1). addresses Link Lx by the Adj-SID 66(x+1).
In the above figure, the PMS needs to assess the dataplane In the above figure, the PMS needs to assess the data-plane
availability of all the links within a remote bundle connected to availability of all the links within a remote bundle connected to
routers R1 and R2. routers R1 and R2.
The monitoring system retrieves the SID/Label information from the The monitoring system retrieves the SID/label information from the
IGP LSDB and appends the following segment list/label stack: {72, IGP LSDB and appends the following segment list/label stack: {72,
662, 992, 664} on its IP probe (whose source and destination 662, 992, 664} on its IP probe (whose source and destination
addresses are the address of the PMS). addresses are the address of the PMS).
PMS sends the probe to its connected router. The MPLS/SR domain then The PMS sends the probe to its connected router. The MPLS/SR domain
forwards the probe to R2 (72 is the Node SID of R2). R2 forwards the then forwards the probe to R2 (72 is the Node-SID of R2). R2
probe to R1 over link L1 (Adjacency SID 662). R1 forwards the probe forwards the probe to R1 over link L1 (Adj-SID 662). R1 forwards the
to R2 over link L2 (Adjacency SID 992). R2 forwards the probe to R1 probe to R2 over link L2 (Adj-SID 992). R2 forwards the probe to R1
over link L3 (Adjacency SID 664). R1 then forwards the IP probe to over link L3 (Adj-SID 664). R1 then forwards the IP probe to the PMS
PMS as per classic IP forwarding. as per classic IP forwarding.
As has been mentioned in section 5.1, the PMS must be able monitor As was mentioned in Section 4.1, the PMS must be able to monitor the
continuity of the path PMS to R2 (Node-SID 72) as well as continuity continuity of the path PMS to R2 (Node-SID 72) as well as the
from R1 to the PMS. If both are given and packets are lost, continuity from R1 to the PMS. If both are given and packets are
forwarding on one of the three interfaces connecting R1 to R2 must be lost, forwarding on one of the three interfaces connecting R1 to R2
disturbed. must be disturbed.
4.3. Use Case 3 - Fault Localization 4.3. Use Case 3: Fault Localization
In the previous example, a uni-directional fault on the middle link In the previous example, a unidirectional fault on the middle link in
in direction of R2 to R1 would be localized by sending the following direction of R2 to R1 would be localized by sending the following two
two probes with respective segment lists: probes with respective segment lists:
o 72, 662, 992, 664 o 72, 662, 992, 664
o 72, 663, 992, 664 o 72, 663, 992, 664
The first probe would succeed while the second would fail. The first probe would succeed while the second would fail.
Correlation of the measurements reveals that the only difference is Correlation of the measurements reveals that the only difference is
using the Adjacency SID 663 of the middle link from R2 to R1 in the using the Adj-SID 663 of the middle link from R2 to R1 in the
non successful measurement. Assuming the second probe has been unsuccessful measurement. Assuming the second probe has been routed
routed correctly, the problem is that for some (possibly unknown) correctly, the problem is that, for some (possibly unknown) reason,
reason SR packets to be forwarded from R2 via the interface SR packets to be forwarded from R2 via the interface identified by
identified by Adjacency SID 663 are lost. Adj-SID 663 are lost.
The example above only illustrates a method to localize a fault by The example above only illustrates a method to localize a fault by
correlated continuity checks. Any operational deployment requires a correlated continuity checks. Any operational deployment requires
well designed engineering to allow for the desired non ambiguous well-designed engineering to allow for the desired unambiguous
diagnosis on the monitored section of the SR network. 'Section' here diagnosis on the monitored section of the SR network. 'Section' here
could be a path, a single physical interface, the set of all links of could be a path, a single physical interface, the set of all links of
a bundle or an adjacency of two nodes, just to name a few. a bundle, or an adjacency of two nodes (just to name a few).
5. Path Trace and Failure Notification 5. Path Trace and Failure Notification
Sometimes forwarding along a single path indeed doesn't work, while Sometimes, forwarding along a single path doesn't work, even though
the control plane information is healthy. Such a situation may occur the control-plane information is healthy. Such a situation may occur
after maintenance work within a domain. An operator may perform on after maintenance work within a domain. An operator may perform on-
demand-tests, but execution of automated PMS path trace checks may be demand tests, but execution of automated PMS path trace checks may be
set up too (scope may be limited to a subset of important end-to-end set up as well (scope may be limited to a subset of important end-to-
paths crossing the router or network section after completion of the end paths crossing the router or network section after completion of
maintenance work there). Upon detection of a path which can't be the maintenance work there). Upon detection of a path that can't be
used, the operator needs to be notified. A check ensuring that re- used, the operator needs to be notified. A check ensuring that a re-
routing event is differed from a path facing whose forwarding routing event is differed from a path facing whose forwarding
behavior doesn't correspond to the control plane information is behavior doesn't correspond to the control-plane information is
necessary (but out of scope of this document). necessary (but out of scope of this document).
Adding an automated problem solution to the PMS features only makes Adding an automated problem solution to the PMS features only makes
sense, if the root cause of the symptom appears often, can be assumed sense if the root cause of the symptom appears often, can be assumed
to be non-ambiguous by its symptoms, can be solved by a pre- to be unambiguous by its symptoms, can be solved by a predetermined
determined chain of commands and the automated PMS reaction not doing chain of commands, is not collaterally damaged by the automated PMS
any collateral damage. A closer analysis is out of scope of this reaction. A closer analysis is out of scope of this document.
document.
The PMS is expected to check control plane liveliness after a path The PMS is expected to check control-plane liveliness after a path
repair effort was executed. It doesn't matter whether the path repair effort was executed. It doesn't matter whether the path
repair was triggered manually or by an automated system. repair was triggered manually or by an automated system.
6. Applying SR to Monitoring non-SR based LSPs (LDP and possibly RSVP- 6. Applying SR to Monitoring LSPs That Are Not SR Based (LDP and
TE) Possibly RSVP-TE)
The MPLS path monitoring system described by this document can be The MPLS PMS described by this document can be realized with
realized with non-Segment Routing (SR) based technology. Making such technology that is not SR based. Making such a monitoring system
a non-SR MPLS monitoring system aware of a domain's complete MPLS that is not SR MPLS based aware of a domain's complete MPLS topology
topology requires, e.g., management plane access to the routers of requires, e.g., management-plane access to the routers of the domain
the domain to be monitored or set up of a dedicated tLDP tunnel per to be monitored or set up of a dedicated tLDP tunnel per router to
router to set up an LDP adjacency. To avoid the use of stale MPLS set up an LDP adjacency. To avoid the use of stale MPLS label
label information, the IGP must be monitored and MPLS topology must information, the IGP must be monitored and MPLS topology must be
be timely aligned with IGP topology. Enhancing IGPs to exchange of aligned with IGP topology in a timely manner. Enhancing IGPs to the
MPLS topology information as done by SR significantly simplifies and exchange of MPLS-topology information as done by SR significantly
stabilizes such an MPLS path monitoring system. simplifies and stabilizes such an MPLS PMS.
A SR based PMS connected to a MPLS domain consisting of LER and LSR An SR-based PMS connected to an MPLS domain consisting of LER and
supporting SR and LDP or RSVP-TE in parallel in all nodes may use SR LSRs supporting SR and LDP or RSVP-TE in parallel in all nodes may
paths to transmit packets to and from start and end points of non-SR use SR paths to transmit packets to and from the start and endpoints
based LSP paths to be monitored. In the example given in figure 1, of LSPs that are not SR based to be monitored. In the example given
the label stack top to bottom may be as follows, when sent by the in Figure 1, the label stack top to bottom may be as follows, when
PMS: sent by the PMS:
o Top: SR based Node-SID of LER i at LER m. o Top: SR-based Node-SID of LER i at LER m.
o Next: LDP or RSVP-TE label identifying the path or tunnel, o Next: LDP or RSVP-TE label identifying the path or tunnel,
respectively from LER i to LER j (at LER i). respectively, from LER i to LER j (at LER i).
o Bottom: SR based Node-SID identifying the path to the PMS at LER j 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 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 aware of the LER LDP-MPLS topology, the PMS may learn the SR MPLS
topology by IGP and use this information. topology by the IGP and use this information.
An implementation report on a PMS operating in an LDP domain is given An implementation report on a PMS operating in an LDP domain is given
in [I-D.leipnitz-spring-pms-implementation-report]. In addition, in [MPLS-PMS-REPORT]. In addition, this report compares delays
this report compares delays measured with a single PMS to the results measured with a single PMS to the results measured by systems that
measured by three standard conformant Measurement Agents ([RFC6808] are conformant with IP Performance Metrics (IPPM) connected to the
connected to an MPLS domain at three different sites). The delay MPLS domain at three sites (see [RFC6808] for IPPM conformance). The
measurements of the PMS and the IPPM Measurement Agents were compared delay measurements of the PMS and the IPPM Measurement Agents were
based on a statistical test in [RFC6576]. The Anderson Darling compared based on a statistical test in [RFC6576]. The Anderson
k-sample test showed that the PMS round-trip delay measurements are Darling k-sample test showed that the PMS round-trip delay
equal to those captured by an IPPM conformant IP measurement system measurements are equal to those captured by an IPPM-conformant IP
for 64 Byte measurement packets with 95% confidence. measurement system for 64 Byte measurement packets with 95%
confidence.
The authors are not aware of similar deployment for RSVP-TE. The authors are not aware of similar deployment for RSVP-TE.
Identification of tunnel entry- and transit-nodes may add complexity. Identification of tunnel entry- and transit-nodes may add complexity.
They are not within scope of this document. They are not within scope of this document.
7. PMS Monitoring of Different Segment ID Types 7. PMS Monitoring of Different Segment ID Types
MPLS SR topology awareness should allow the PMS to monitor liveliness MPLS SR topology awareness should allow the PMS to monitor liveliness
of SIDs related to interfaces within the SR and IGP domain, of SIDs related to interfaces within the SR and IGP domain,
respectively. Tracing a path where an SR capable node assigns an respectively. Tracing a path where an SR-capable node assigns an
Adj-SID for a non-SR-capable node may fail. This and other backward Adj-SID for a node that is not SR capable may fail. This and other
compatibility with non Segment Routing devices are discussed by backward compatibility with non-SR devices are discussed by RFC 8287
[I-D.ietf-mpls-spring-lsp-ping]. [RFC8287].
To match control plane information with data plane information for To match control-plane information with data-plane information for
all relevant types of Segment IDs, [I-D.ietf-mpls-spring-lsp-ping] all relevant types of Segment IDs, RFC 8287 [RFC8287] enhances MPLS
enhances MPLS OAM functions defined by RFC 8029 [RFC8029]. OAM functions defined by RFC 8029 [RFC8029].
8. Connectivity Verification Using PMS 8. Connectivity Verification Using PMS
While the PMS based use cases explained in Section 5 are sufficient While the PMS-based use cases explained in Section 5 are sufficient
to provide continuity check between LER i and LER j, it may not help to provide continuity checks between LER i and LER j, they may not
perform connectivity verification. help perform connectivity verification.
+---+
|PMS|
+---+
|
|
+----+ +----+ +-----+
|LSRa|-----|LSR1|-----|LER i|
+----+ +----+ +-----+
| / \ /
| / \__/
+-----+/ /|
|LER m| / |
+-----+\ / \
\ / \
\+----+ +-----+
|LSR2| |LER j|
+----+ +-----+
Connectivity verification with a PMS +---+
|PMS|
+---+
|
|
+----+ +----+ +-----+
|LSRa|-----|LSR1|-----|LER i|
+----+ +----+ +-----+
| / \ /
| / \__/
+-----+/ /|
|LER m| / |
+-----+\ / \
\ / \
\+----+ +-----+
|LSR2| |LER j|
+----+ +-----+
Figure 3 Figure 3: Connectivity Verification with a PMS
Let's assign the following Node SIDs to the nodes of the figure: PMS Let's assign the following Node-SIDs to the nodes of the figure:
= 10, LER i = 20, LER j = 30, LER m = 40. PMS is intended to PMS = 10, LER i = 20, LER j = 30, LER m = 40. The PMS is intended to
validate the path between LER m and LER j. In order to validate this validate the path between LER m and LER j. In order to validate this
path, PMS will send the probe packet with label stack of (top to path, the PMS will send the probe packet with a label stack of (top
bottom): {40} {30} {10}. Imagine any of the below forwarding entry to bottom): {40} {30} {10}. Imagine any of the below forwarding
misprogrammed situation: entry misprogrammed situation:
o LSRa receiving any packet with top label 40 will POP and forwards o LSRa receiving any packet with top label 40 will POP and forwards
to LSR1 instead of LER m. to LSR1 instead of LER m.
o LSR1 receiving any packet with top label 30 will pop and forward o LSR1 receiving any packet with top label 30 will pop and forward
to LER i instead of LER j. to LER i instead of LER j.
In any of these above situation, the probe packet will be delivered In either of the above situations, the probe packet will be delivered
back to PMS leading to a falsified path liveliness indication by the back to the PMS leading to a falsified path liveliness indication by
PMS. the PMS.
Connectivity Verification functions helps us to verify if the probe Connectivity Verification functions help us to verify if the probe is
is taking the expected path. For example, PMS can intermittently taking the expected path. For example, the PMS can intermittently
send the probe packet with label stack of (top to bottom): send the probe packet with a label stack of (top to bottom):
{40;ttl=255} {30;ttl=1} {10;ttl=255}. The probe packet may carry {40;ttl=255} {30;ttl=1} {10;ttl=255}. The probe packet may carry
information about LER m which could be carried in Target FEC Stack in information about LER m, which could be carried in the Target FEC
case of MPLS Echo Request or Discriminator in case of Seamless BFD. Stack in case of an MPLS Echo Request or Discriminator in the case of
When LER m receives the packet, it will punt due to TTL expiry and Seamless BFD. When LER m receives the packet, it will punt due to
sends a positive response. In the above mentioned misprogramming Time-To-Live (TTL) expiry and send a positive response. In the
situation, LSRa will forwards to LSR1 which will send a negative above-mentioned misprogramming situation, LSRa will forward to LSR1,
response to PMS as the information in probe does not match the local which will send a negative response to the PMS as the information in
node. PMS can do the same for bottom label as well. This will help probe does not match the local node. The PMS can do the same for
perform connectivity verification and ensure that the path between bottom label as well. This will help perform connectivity
LER m and LER j is working as expected. verification and ensure that the path between LER m and LER j is
working as expected.
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This document has no IANA actions.
10. Security Considerations 10. Security Considerations
The PMS builds packets with intent of performing OAM tasks. It uses The PMS builds packets with the intent of performing OAM tasks. It
address information based on topology information, rather than a uses address information based on topology information rather than a
protocol. protocol.
The PMS allows the insertion of traffic into non-SR domains. This The PMS allows the insertion of traffic into non-SR domains. This
may be required in the case of an LDP domain attached to the SR may be required in the case of an LDP domain attached to the SR
domain, but it can be used to maliciously insert traffic in the case domain, but it can be used to maliciously insert traffic in the case
of external IP domains and MPLS based VPNs. of external IP domains and MPLS-based VPNs.
To prevent a PMS from inserting traffic into an MPLS VPN domain, one To prevent a PMS from inserting traffic into an MPLS VPN domain, one
or more sets of label ranges may be reserved for service labels or more sets of label ranges may be reserved for service labels
within an SR domain. The PMS should be configured to reject usage of within an SR domain. The PMS should be configured to reject usage of
these service label values. In the same way, misuse of IP these service label values. In the same way, misuse of IP
destination addresses is blocked if only IP-destination address destination addresses is blocked if only IP destination address
values conforming to RFC 8029 [RFC8029] are settable by the PMS. values conforming to RFC 8029 [RFC8029] are settable by the PMS.
To limit potential misuse, access to a PMS needs to be authorized and To limit potential misuse, access to a PMS needs to be authorized and
should be logged. OAM supported by a PMS requires skilled personnel should be logged. OAM supported by a PMS requires skilled personnel;
and hence only experts requiring PMS access should be allowed to hence, only experts requiring PMS access should be allowed to access
access such a system. It is recommended to directly attach a PMS to such a system. It is recommended to directly attach a PMS to an SR
an SR domain. Connecting a PMS to an SR domain by a tunnel is domain. Connecting a PMS to an SR domain by a tunnel is technically
technically possible, but adds further security issues. A tunnel possible, but adds further security issues. A tunnel-based access of
based access of a PMS to an SR domain is not recommended. a PMS to an SR domain is not recommended.
Use of stale MPLS or IGP routing information could cause a PMS Use of stale MPLS or IGP routing information could cause a PMS-
monitoring packet to leave the domain where it originated. PMS monitoring packet to leave the domain where it originated. PMS-
monitoring packets should not be sent using stale MPLS or IGP routing monitoring packets should not be sent using stale MPLS- or IGP-
information. To carry out a desired measurement properly, the PMS routing information. To carry out a desired measurement properly,
must be aware of and respect the actual route changes, convergence the PMS must be aware of and respect the actual route changes,
events, as well as the assignment of Segment IDs relevant for convergence events, as well as the assignment of Segment IDs relevant
measurements. At a minimum, the PMS must be able to listen to IGP for measurements. At a minimum, the PMS must be able to listen to
topology changes, or pull routing and segment information from IGP topology changes or pull routing and segment information from
routers signaling topology changes. routers signaling topology changes.
Traffic insertion by a PMS may be unintended, especially if the IGP Traffic insertion by a PMS may be unintended, especially if the IGP
or MPLS topology stored locally are in stale state. As soon as the or MPLS topology stored locally is in stale state. As soon as the
PMS has an indication, that its IGP or MPLS topology are stale, it PMS has an indication that its IGP or MPLS topology are stale, it
should stop operations involving network sections whose topology may should stop operations involving network sections whose topology may
not be accurate. Note however that it is a task of an OAM system to not be accurate. However, note that it is the task of an OAM system
discover and locate network sections having where forwarding behavior to discover and locate network sections where forwarding behavior is
is not matching control plane state. As soon as a PMS or an operator not matching control-plane state. As soon as a PMS or an operator of
of a PMS has the impression that the PMS topology information is a PMS has the impression that the PMS topology information is stale,
stale, measures need to be taken to refresh the topology information. measures need to be taken to refresh the topology information. These
These measures should be part of the PMS design. Matching forwarding measures should be part of the PMS design. Matching forwarding and
and control plane state by periodically automated execution of RFC control-plane state by periodically automated execution of the
8029 [RFC8029] mechanisms may be such a feature. Whenever network mechanisms described in RFC 8029 [RFC8029] may be such a feature.
maintenance tasks are performed by operators, the PMS topology Whenever network maintenance tasks are performed by operators, the
discovery should be started asynchronously after network maintenance PMS topology discovery should be started asynchronously after network
has been finished. maintenance has been finished.
A PMS loosing network connectivity or crashing must remove all IGP A PMS that is losing network connectivity or crashing must remove all
and MPLS topology information prior to restarting operation. IGP- and MPLS-topology information prior to restarting operation.
A PMS may operate routine measurements on large scale. Care must be A PMS may operate routine measurements on a large scale. Care must
taken to avoid unintended traffic insertion after topology changes be taken to avoid unintended traffic insertion after topology changes
which result , e.g., in changes of label assignments to routes or that result in, e.g., changes of label assignments to routes or
interfaces within a domain. If the labels concerned are part of the interfaces within a domain. If the labels concerned are part of the
label stack composed by the PMS for any measurement packet and their label stack composed by the PMS for any measurement packet and their
state is stale, the measurement initially needs to be stopped. Set state is stale, the measurement initially needs to be stopped. Setup
up and operation of routine measurements may be automated. Secure and operation of routine measurements may be automated. Secure
automated PMS operation requires a working automated detection and automated PMS operation requires a working automated detection and
recognition of stale routing state. recognition of stale routing state.
11. Acknowledgements 11. References
The authors would like to thank Nobo Akiya for his contribution.
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. Finally, Bruno Decraene's shepherd
review led to a clarified document.
12. References
12.1. Normative References
[I-D.ietf-spring-segment-routing] 11.1. Normative References
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-13 (work
in progress), October 2017.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration, Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276, and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014, DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>. <https://www.rfc-editor.org/info/rfc7276>.
12.2. Informative References [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[I-D.ietf-mpls-spring-lsp-ping] 11.2. Informative References
Kumar, N., Pignataro, C., Swallow, G., Akiya, N., Kini,
S., and M. Chen, "Label Switched Path (LSP) Ping/
Traceroute for Segment Routing IGP Prefix and Adjacency
SIDs with MPLS Data-plane", draft-ietf-mpls-spring-lsp-
ping-13 (work in progress), October 2017.
[I-D.leipnitz-spring-pms-implementation-report] [MPLS-PMS-REPORT]
Leipnitz, R. and R. Geib, "A scalable and topology aware Leipnitz, R., Ed. and R. Geib, "A scalable and topology
MPLS data plane monitoring system", draft-leipnitz-spring- aware MPLS data plane monitoring system", Work in
pms-implementation-report-00 (work in progress), June Progress, draft-leipnitz-spring-pms-implementation-
2016. report-00, June 2016.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
skipping to change at page 18, line 41 skipping to change at page 18, line 41
"Seamless Bidirectional Forwarding Detection (S-BFD) Use "Seamless Bidirectional Forwarding Detection (S-BFD) Use
Cases", RFC 7882, DOI 10.17487/RFC7882, July 2016, Cases", RFC 7882, DOI 10.17487/RFC7882, July 2016,
<https://www.rfc-editor.org/info/rfc7882>. <https://www.rfc-editor.org/info/rfc7882>.
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029, Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017, DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>. <https://www.rfc-editor.org/info/rfc8029>.
[RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya,
N., Kini, S., and M. Chen, "Label Switched Path (LSP)
Ping/Traceroute for Segment Routing (SR) IGP-Prefix and
IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data
Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017,
<https://www.rfc-editor.org/info/rfc8287>.
Acknowledgements
The authors would like to thank Nobo Akiya for his contribution.
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. Finally, Bruno Decraene's Document
Shepherd review led to a clarified document.
Authors' Addresses Authors' Addresses
Ruediger Geib (editor) Ruediger Geib (editor)
Deutsche Telekom Deutsche Telekom
Heinrich Hertz Str. 3-7 Heinrich Hertz Str. 3-7
Darmstadt 64295 Darmstadt 64295
Germany Germany
Phone: +49 6151 5812747 Phone: +49 6151 5812747
Email: Ruediger.Geib@telekom.de Email: Ruediger.Geib@telekom.de
skipping to change at page 19, line 15 skipping to change at page 19, line 35
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
Belgium Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Carlos Pignataro (editor) Carlos Pignataro (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
7200 Kit Creek Road 7200 Kit Creek Road
Research Triangle Park, NC 27709-4987 Research Triangle Park, NC 27709-4987
US United States of America
Email: cpignata@cisco.com Email: cpignata@cisco.com
Nagendra Kumar Nagendra Kumar
Cisco Systems, Inc. Cisco Systems, Inc.
7200 Kit Creek Road 7200 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709-4987
US United States of America
Email: naikumar@cisco.com Email: naikumar@cisco.com
 End of changes. 126 change blocks. 
447 lines changed or deleted 446 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/