draft-ietf-spring-oam-usecase-09.txt   draft-ietf-spring-oam-usecase-10.txt 
spring R. Geib, Ed. spring R. Geib, Ed.
Internet-Draft Deutsche Telekom Internet-Draft Deutsche Telekom
Intended status: Informational C. Filsfils Intended status: Informational C. Filsfils
Expires: January 26, 2018 C. Pignataro, Ed. Expires: June 21, 2018 C. Pignataro, Ed.
N. Kumar N. Kumar
Cisco Systems, Inc. Cisco Systems, Inc.
July 25, 2017 December 18, 2017
A Scalable and Topology-Aware MPLS Dataplane Monitoring System A Scalable and Topology-Aware MPLS Dataplane Monitoring System
draft-ietf-spring-oam-usecase-09 draft-ietf-spring-oam-usecase-10
Abstract Abstract
This document describes features of a path monitoring system and This document describes features of an MPLS path monitoring system
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 LSP Trace, in a very
complementary way. MPLS topology awareness reduces management and complementary way. MPLS topology awareness reduces management and
control plane involvement of OAM measurements while enabling new OAM control plane involvement of OAM measurements while enabling new OAM
features. features.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 26, 2018. This Internet-Draft will expire on June 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 5 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5
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. SR-based Path Monitoring Use Case Illustration . . . . . . . 7
4.1. Use Case 1 - LSP Dataplane Monitoring . . . . . . . . . . 7 4.1. Use Case 1 - LSP Dataplane Monitoring . . . . . . . . . . 7
4.2. Use Case 2 - Monitoring a Remote Bundle . . . . . . . . . 10 4.2. Use Case 2 - Monitoring a Remote Bundle . . . . . . . . . 10
4.3. Use Case 3 - Fault Localization . . . . . . . . . . . . . 11 4.3. Use Case 3 - Fault Localization . . . . . . . . . . . . . 11
5. Path Trace and Failure Notification . . . . . . . . . . . . . 11 5. Path Trace and Failure Notification . . . . . . . . . . . . . 12
6. Applying SR to Monitoring non-SR based LSPs (LDP and possibly 6. Applying SR to Monitoring non-SR based LSPs (LDP and possibly
RSVP-TE) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 RSVP-TE) . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. PMS Monitoring of Different Segment ID Types . . . . . . . . 13 7. PMS Monitoring of Different Segment ID Types . . . . . . . . 13
8. Connectivity Verification Using PMS . . . . . . . . . . . . . 13 8. Connectivity Verification Using PMS . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Network operator need to be able to monitor the forwarding paths used Network operators need to be able to monitor the forwarding paths
to transport user packets. Monitoring packets are expected to be used to transport user packets. Monitoring packets are expected to
forwarded in dataplane in a similar way as user packets. Segment be forwarded in dataplane in a similar way as user packets. Segment
Routing enables forwarding of packets along pre-defined paths and Routing enables forwarding of packets along pre-defined paths and
segments and thus a Segment Routed monitoring packet can stay in segments and thus a Segment Routed monitoring packet can stay in
dataplane while passing along one or more segments to be monitored. dataplane while passing along one or more segments to be monitored.
This document describes a system using MPLS data plane path This document describes a system as a functional component called
monitoring capabilities. The use cases introduced here are limited (MPLS) Path Monitoring System, PMS. The PMS is using MPLS data plane
to a single Interior Gateway Protocol (IGP) MPLS domain. path monitoring capabilities. The use cases introduced here are
limited to a single Interior Gateway Protocol (IGP) MPLS domain. The
use cases of this document refer to the PMS system realised as a
separate node. Although many use cases depict the PMS as a physical
node, no assumption should be made, and the node could be virtual.
This system is defined as a functional component abstracted to have
many realizations. The terms PMS and system are used interchangeably
in the following.
The system applies to monitoring of non Segment Routing Label The system applies to monitoring of non Segment Routing Label
Switched Paths (LSP's) like LDP as well as to monitoring of Segment Switched Paths (LSP's) like Label Distribution Protocol (LDP) as well
Routed LSP's (section 7 offers some more information). As compared as to monitoring of Segment Routed LSP's (section 7 offers some more
to non Segment Routing approaches, Segment Routing is expected to information). As compared to non Segment Routing approaches, Segment
simplify such a monitoring system by enabling MPLS topology detection Routing is expected to simplify such a monitoring system by enabling
based on IGP signaled segments. The MPLS topology should be detected MPLS topology detection based on IGP signaled segments. The MPLS
and correlated with the IGP topology, which is too detected by IGP topology should be detected and correlated with the IGP topology,
signaling. Thus a centralized and MPLS topology aware monitoring which is too detected by IGP signaling. Thus a centralized and MPLS
unit can be realized in a Segment Routed domain. This topology topology aware monitoring unit can be realized in a Segment Routed
awareness can be used for Operation, Administration, and Maintenance domain. This topology awareness can be used for Operation,
(OAM) purposes as described by this document. Administration, and Maintenance (OAM) purposes as described by this
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 system described here allows to set up an SR domain wide
centralized connectivity validation. Many operators operators of centralized connectivity validation. Many operators of large
large networks regard centralized monitoring system as useful.. networks regard centralized 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 to transport MPLS path trace or connectivity validation o SR allows the transport of MPLS path trace or connectivity
packets for every Label Switched Path to all nodes of an SR validation packets for every Label Switched Path to all nodes of
domain. This use case doesn't describe new path trace features. an SR domain. This use case doesn't describe new path trace
The system described here allows to set up an SR domain wide features. The system described here allows to set up an SR domain
centralized connectivity validation, which is useful in large wide 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 sending probing packets which represent customer traffic,
possibly from multiple services (e.g., small Voice over IP packet, possibly from multiple services (e.g., small Voice over IP packet,
larger HTTP packets) and embedding of useful monitoring data larger HTTP packets) and embedding of useful monitoring data
(e.g., accurate time stamps since both sender and receiver have (e.g., accurate time stamps since both sender and receiver have
the same clock, sequence numbers to ease the measurement...). 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 base), 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
skipping to change at page 5, line 5 skipping to change at page 5, line 12
IGP change is detected, the monitored path can be considered as IGP change is detected, the monitored path can be considered as
validated. If monitoring requires pushing a large label stack, a validated. If monitoring requires pushing a large label stack, a
software based implementation is usually more flexible than an software based implementation is usually more flexible than an
hardware based one. Hence router label stack depth and label 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 [I-D.ietf-mpls-spring-lsp-ping] discusses SR OAM applicability and
MPLS traceroute enhancements adding functionality to the use cases MPLS traceroute enhancements adding functionality to the use cases
described by this document. described by this document.
The document describes both use cases and a standalone monitoring
framework. The monitoring system re-uses existing IETF OAM protocols
and leverage Segment Routing (Source Routing) to allow a single
device to send, have exercised, and receive its own probing packets.
As a consequence, there are no new interoperability considerations.
Standard Track is not required and Informational status is
appropriate
2. Terminology and Acronyms 2. Terminology and Acronyms
2.1. Terminology 2.1. Terminology
Continuity Check Continuity Check
is defined in Section 2.2.7 of RFC 7276 [RFC7276]. is defined in Section 2.2.7 of RFC 7276 [RFC7276].
Connectivity Verification Connectivity Verification
skipping to change at page 7, line 9 skipping to change at page 7, line 25
popping the MPLS stack and revealing a probe packet with PMS as 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 which 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, routing protocol support isn't
required and the PMS itself doesn't have to be involved in IGP or required and the PMS itself doesn't have to be involved in IGP or
MPLS routing. A static route will do. Further options, like MPLS routing. A static route will do. The option to connect a PMS
deployment of a PMS connecting to the MPLS domain by a tunnel only to an MPLS domain by a tunnel may be attractive to some operators.
require more thought, as this implies security aspects. MPLS so far MPLS so far separates networks securely by avoiding tunnel access to
separates networks securely by avoiding tunnel access to MPLS MPLS domains. Tunnel based access of a PMS to an MPLS domain is out
domains. of scope of this document, as it implies additional security aspects.
4. SR-based Path Monitoring Use Case Illustration 4. SR-based Path Monitoring Use Case Illustration
4.1. Use Case 1 - LSP Dataplane Monitoring 4.1. Use Case 1 - LSP Dataplane Monitoring
Figure 1 shows an example of this functional component as a system,
which can be physical or virtual.
+---+ +----+ +-----+ +---+ +----+ +-----+
|PMS| |LSR1|-----|LER i| |PMS| |LSR1|-----|LER i|
+---+ +----+ +-----+ +---+ +----+ +-----+
| / \ / | / \ /
| / \__/ | / \__/
+-----+/ /| +-----+/ /|
|LER m| / | |LER m| / |
+-----+\ / \ +-----+\ / \
\ / \ \ / \
\+----+ +-----+ \+----+ +-----+
skipping to change at page 9, line 31 skipping to change at page 10, line 18
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 RFC 8029
[RFC8029] connectivity verification and, if there's only one physical [RFC8029] connectivity verification and, if there's only one physical
connection between all nodes, the approach is independent of ECMP connection between all nodes, the approach is independent of ECMP
functionalities. The method still is able to monitor all link functionalities. The method still is able to monitor all link
combinations of all paths of an MPLS domain. If correct forwarding combinations of all paths of an MPLS domain. If correct forwarding
along the desired paths has to be checked, or multiple physical along the desired paths has to be checked, or multiple physical
connections exist between any two nodes, all Adj-SIDs along that path connections exist between any two nodes, all Adj-SIDs along that path
should be part of the label stack. should be part of the label stack.
In theory at least, a single PMS is able to monitor data plane While a single PMS can detect the complete MPLS control and data
availability of all LSPs in the domain. The PMS may be a router, but plane topology, a reliable deployment requires two separated PMS.
could also be dedicated monitoring system. If measurement system Scalable permanent surveillance of a set of LSPs could require
reliability is an issue, more than a single PMS may be connected to deployment of several PMS. The PMS may be a router, but could also
the MPLS domain. 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 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 PMS 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
skipping to change at page 14, line 42 skipping to change at page 15, line 29
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Security Considerations 10. Security Considerations
The PMS builds packets with intent of performing OAM tasks. It uses The PMS builds packets with intent of performing OAM tasks. It uses
address information based on topology information, rather than a address information based on topology information, rather than a
protocol. protocol.
The PMS allows to insert traffic into non-SR domains. This may be The PMS allows the insertion of traffic into non-SR domains. This
required in the case of an LDP domain attached to the SR domain, but may be required in the case of an LDP domain attached to the SR
it can be used to compromise security in the case of external IP domain, but it can be used to maliciously insert traffic in the case
domains and MPLS based VPNs. of external IP domains and MPLS based VPNs.
To avoid a PMS to insert traffic into an MPLS VPN domain, one or more To prevent a PMS from inserting traffic into an MPLS VPN domain, one
sets of label ranges may be reserved for service labels within an SR or more sets of label ranges may be reserved for service labels
domain. The PMS should be configured to reject usage of these within an SR domain. The PMS should be configured to reject usage of
service label values. In the same way, misuse of IP destination these service label values. In the same way, misuse of IP
addresses is blocked if only IP-destination address values conforming destination addresses is blocked if only IP-destination address
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 personal should be logged. OAM supported by a PMS requires skilled personnel
and hence only experts requiring PMS access should be allowed to and hence only experts requiring PMS access should be allowed to
access such a system. It is recommended to directly attach a PMS to access such a system. It is recommended to directly attach a PMS to
an SR domain. Connecting a PMS to an SR domain is technically an SR domain. Connecting a PMS to an SR domain by a tunnel is
possible, but adds further security issues. A tunnel based access of technically possible, but adds further security issues. A tunnel
a PMS to an SR domain is not recommended. based access of 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 routing
information. As it is necessary to know that the information is information. To carry out a desired measurement properly, the PMS
stale is order to follow the instruction, as is the case with for must be aware of and respect the actual route changes, convergence
example convergence events that may be ongoing at the time of events, as well as the assignment of Segment IDs relevant for
diagnostic measurement. measurements. At a minimum, the PMS must be able to listen to IGP
topology changes, or pull routing and segment information from
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 are 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. Note however that it is a task of an OAM system to
discover and locate network sections having where forwarding behavior discover and locate network sections having where forwarding behavior
is not matching control plane state. As soon as a PMS or an operator is not matching control plane state. As soon as a PMS or an operator
of a PMS has the impression, that the PMS topology information is of a PMS has the impression that the PMS topology information is
stale, measures need to be taken to refresh the topology information. stale, measures need to be taken to refresh the topology information.
These measures should be part of the PMS design. Matching forwarding These measures should be part of the PMS design. Matching forwarding
and control plane state by periodically automated execution of RFC and control plane state by periodically automated execution of RFC
8029 [RFC8029] mechanisms may be such a feature. Whenever network 8029 [RFC8029] mechanisms may be such a feature. Whenever network
maintenance tasks are performed by operators, the PMS topology maintenance tasks are performed by operators, the PMS topology
discovery should be started asynchronously after network maintenance discovery should be started asynchronously after network maintenance
has been finished. has been finished.
A PMS loosing network connectivity or crashing must remove all IGP A PMS loosing network connectivity or crashing must remove all IGP
and MPLS topology information prior to restarting operation. and MPLS topology information prior to restarting operation.
A PMS may operate routine measurements. If these are automated, care A PMS may operate routine measurements on large scale. Care must be
must be taken to avoid unintended traffic insertion. On the other taken to avoid unintended traffic insertion after topology changes
hand, large scale operation based on operator configuration itself is which result , e.g., in changes of label assignments to routes or
a source of unintended misconfigurations and should be avoided. interfaces within a domain. If the labels concerned are part of the
label stack composed by the PMS for any measurement packet and their
state is stale, the measurement initially needs to be stopped. Set
up and operation of routine measurements may be automated. Secure
automated PMS operation requires a working automated detection and
recognition of stale routing state.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Nobo Akiya for his contribution. The authors would like to thank Nobo Akiya for his contribution.
Raik Leipnitz kindly provided an editorial review. The authors would Raik Leipnitz kindly provided an editorial review. The authors would
also like to thank Faisal Iqbal for an insightful review and a useful also like to thank Faisal Iqbal for an insightful review and a useful
set of comments and suggestions. Finally, Bruno Decraene's shepherd set of comments and suggestions. Finally, Bruno Decraene's shepherd
review led to a clarified document. review led to a clarified document.
12. References 12. References
skipping to change at page 16, line 8 skipping to change at page 17, line 4
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Nobo Akiya for his contribution. The authors would like to thank Nobo Akiya for his contribution.
Raik Leipnitz kindly provided an editorial review. The authors would Raik Leipnitz kindly provided an editorial review. The authors would
also like to thank Faisal Iqbal for an insightful review and a useful also like to thank Faisal Iqbal for an insightful review and a useful
set of comments and suggestions. Finally, Bruno Decraene's shepherd set of comments and suggestions. Finally, Bruno Decraene's shepherd
review led to a clarified document. review led to a clarified document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
and R. Shakir, "Segment Routing Architecture", draft-ietf- Litkowski, S., and R. Shakir, "Segment Routing
spring-segment-routing-12 (work in progress), June 2017. 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,
<http://www.rfc-editor.org/info/rfc7276>. <https://www.rfc-editor.org/info/rfc7276>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-mpls-spring-lsp-ping] [I-D.ietf-mpls-spring-lsp-ping]
Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini, Kumar, N., Pignataro, C., Swallow, G., Akiya, N., Kini,
S., Gredler, H., and M. Chen, "Label Switched Path (LSP) S., and M. Chen, "Label Switched Path (LSP) Ping/
Ping/Traceroute for Segment Routing Networks with MPLS Traceroute for Segment Routing IGP Prefix and Adjacency
Dataplane", draft-ietf-mpls-spring-lsp-ping-03 (work in SIDs with MPLS Data-plane", draft-ietf-mpls-spring-lsp-
progress), June 2017. ping-13 (work in progress), October 2017.
[I-D.leipnitz-spring-pms-implementation-report] [I-D.leipnitz-spring-pms-implementation-report]
Leipnitz, R. and R. Geib, "A scalable and topology aware Leipnitz, R. and R. Geib, "A scalable and topology aware
MPLS data plane monitoring system", draft-leipnitz-spring- MPLS data plane monitoring system", draft-leipnitz-spring-
pms-implementation-report-00 (work in progress), June pms-implementation-report-00 (work in progress), June
2016. 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,
<http://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,
<http://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884, "Extended ICMP to Support Multi-Part Messages", RFC 4884,
DOI 10.17487/RFC4884, April 2007, DOI 10.17487/RFC4884, April 2007,
<http://www.rfc-editor.org/info/rfc4884>. <https://www.rfc-editor.org/info/rfc4884>.
[RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP [RFC4950] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP
Extensions for Multiprotocol Label Switching", RFC 4950, Extensions for Multiprotocol Label Switching", RFC 4950,
DOI 10.17487/RFC4950, August 2007, DOI 10.17487/RFC4950, August 2007,
<http://www.rfc-editor.org/info/rfc4950>. <https://www.rfc-editor.org/info/rfc4950>.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
June 2010, <http://www.rfc-editor.org/info/rfc5884>. June 2010, <https://www.rfc-editor.org/info/rfc5884>.
[RFC6576] Geib, R., Ed., Morton, A., Fardid, R., and A. Steinmitz, [RFC6576] Geib, R., Ed., Morton, A., Fardid, R., and A. Steinmitz,
"IP Performance Metrics (IPPM) Standard Advancement "IP Performance Metrics (IPPM) Standard Advancement
Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March
2012, <http://www.rfc-editor.org/info/rfc6576>. 2012, <https://www.rfc-editor.org/info/rfc6576>.
[RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test [RFC6808] Ciavattone, L., Geib, R., Morton, A., and M. Wieser, "Test
Plan and Results Supporting Advancement of RFC 2679 on the Plan and Results Supporting Advancement of RFC 2679 on the
Standards Track", RFC 6808, DOI 10.17487/RFC6808, December Standards Track", RFC 6808, DOI 10.17487/RFC6808, December
2012, <http://www.rfc-editor.org/info/rfc6808>. 2012, <https://www.rfc-editor.org/info/rfc6808>.
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S. [RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
Pallagatti, "Seamless Bidirectional Forwarding Detection Pallagatti, "Seamless Bidirectional Forwarding Detection
(S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016, (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
<http://www.rfc-editor.org/info/rfc7880>. <https://www.rfc-editor.org/info/rfc7880>.
[RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless [RFC7881] Pignataro, C., Ward, D., and N. Akiya, "Seamless
Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6,
and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016, and MPLS", RFC 7881, DOI 10.17487/RFC7881, July 2016,
<http://www.rfc-editor.org/info/rfc7881>. <https://www.rfc-editor.org/info/rfc7881>.
[RFC7882] Aldrin, S., Pignataro, C., Mirsky, G., and N. Kumar, [RFC7882] Aldrin, S., Pignataro, C., Mirsky, G., and N. Kumar,
"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,
<http://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,
<http://www.rfc-editor.org/info/rfc8029>. <https://www.rfc-editor.org/info/rfc8029>.
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
Clarence Filsfils Clarence Filsfils
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
 End of changes. 44 change blocks. 
95 lines changed or deleted 122 lines changed or added

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