< draft-ietf-spring-oam-usecase-02.txt   draft-ietf-spring-oam-usecase-03.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: October 17, 2016 C. Pignataro Expires: October 24, 2016 C. Pignataro, Ed.
N. Kumar N. Kumar
Cisco Systems, Inc. Cisco
April 15, 2016 April 22, 2016
A scalable and topology aware MPLS data plane monitoring system A Scalable and Topology-Aware MPLS Dataplane Monitoring System
draft-ietf-spring-oam-usecase-02 draft-ietf-spring-oam-usecase-03
Abstract Abstract
This document describes features of a path monitoring system and a This document describes features of a path monitoring system and
use case. Segment based routing enables a scalable and simple method related use cases. Segment based routing enables a scalable and
to monitor data plane liveliness of the complete set of paths simple method to monitor data plane liveliness of the complete set of
belonging to a single domain. The MPLS monitoring system adds to paths belonging to a single domain. The MPLS monitoring system adds
legacy MPLS ping and path trace, it doesn't result in a deprication features to the traditional MPLS ping and LSP trace, in a very
them. MPLS topology awareness reduces management and control plane complementary way. MPLS topology awareness reduces management and
involvement of OAM measurements while enabling new OAM features. control plane involvement of 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 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 http://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 October 17, 2016. This Internet-Draft will expire on October 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 (http://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. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. An MPLS topology aware path monitoring system . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. SR based path monitoring use case illustration . . . . . . . 5 3. An MPLS Topology-Aware Path Monitoring System . . . . . . . . 4
3.1. Use-case 1 - LSP dataplane monitoring . . . . . . . . . . 5 4. SR-based Path Monitoring Use Case Illustration . . . . . . . 5
3.2. Use-case 2 - Monitoring a remote bundle . . . . . . . . . 7 4.1. Use Case 1 - LSP Dataplane Monitoring . . . . . . . . . . 6
3.3. Use-Case 3 - Fault localization . . . . . . . . . . . . . 8 4.2. Use Case 2 - Monitoring a Remote Bundle . . . . . . . . . 8
4. Failure Notification from PMS to LERi . . . . . . . . . . . . 8 4.3. Use Case 3 - Fault Localization . . . . . . . . . . . . . 8
5. Applying SR to monitor LDP paths . . . . . . . . . . . . . . 9 5. Failure Notification from PMS to LERi . . . . . . . . . . . . 9
6. PMS monitoring of different Segment ID types . . . . . . . . 9 6. Applying SR to Monitoring LDP Paths . . . . . . . . . . . . . 9
7. Connectivity Verification using PMS . . . . . . . . . . . . . 9 7. PMS Monitoring of Different Segment ID Types . . . . . . . . 9
8. Extensions of related standards helpful for this use case . . 10 8. Connectivity Verification Using PMS . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Extensions of Specifications Relevant to this Use Case . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 10 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 10 13.1. Normative References . . . . . . . . . . . . . . . . . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Acronyms
ECMP Equal-Cost Multi-Path
IGP Interionr Gateway Protocol
LER Label Edge Router
LSP Label Switched Path
LSR Label Switching Router
OAM Operations, Administration, and Maintenance
PMS Path Monitoring System
SID Segment Identifier
SR Segment Routing
SRGB Segment Routing Global Block
2. Introduction
It is essential for a network operator to monitor all the forwarding It is essential for a network operator to monitor all the forwarding
paths observed by the transported user packets. The monitoring flow paths observed by the transported user packets. The monitoring flow
is expected to be forwarded in dataplane in a similar way as user is expected to be forwarded in dataplane in a similar way as user
packets. Segment Routing enables forwarding of packets along pre- packets. Segment Routing enables forwarding of packets along pre-
defined paths and segments and thus a Segment Routed monitoring defined paths and segments and thus a Segment Routed monitoring
packet can stay in dataplane while passing along one or more segments packet can stay in dataplane while passing along one or more segments
to be monitored. to be monitored.
This document describes illustrates a system using MPLS data plane This document describes illustrates a system using MPLS data plane
path monitoring capabilities. The use case introduced here is path monitoring capabilities. The use case introduced here is
limited to a single IGP MPLS domain. limited to a single IGP MPLS domain.
The system applies to monitoring of LDP LSP's as well as to The system applies to monitoring of LDP LSP's as well as to
monitoring of Segment Routed LSP's. As compared to LDP, Segment monitoring of Segment Routed LSP's. As compared to LDP, Segment
Routing is expected to simplify the system by enabling MPLS topology Routing is expected to simplify the system by enabling MPLS topology
detection based on IGP signaled segments as specified by detection based on IGP signaled segments as specified at
[ID.sr-isis]. Thus a centralised and MPLS topology aware monitoring [I-D.ietf-isis-segment-routing-extensions] and
unit can be realized in a Segment Routed domain. This topology [I-D.ietf-ospf-segment-routing-extensions]. Thus a centralised and
awareness can be used for OAM purposes as described by this draft. MPLS topology aware monitoring unit can be realized in a Segment
Routed domain. This topology awareness can be used for OAM purposes
as described by this document.
The MPLS path monitoring system described by this document can be The MPLS path monitoring system described by this document can be
realised with pre-Segment based Routing (SR) technology. Making such realised with pre-Segment based Routing (SR) technology. Making such
a pre-SR MPLS monitoring system aware of a domains complete MPLS a pre-SR MPLS monitoring system aware of a domains complete MPLS
topology requires e.g. management plane access. To avoid the use of topology requires e.g. management plane access. To avoid the use of
stale MPLS label information, IGP must be monitored and MPLS topology stale MPLS label information, IGP must be monitored and MPLS topology
must be timely aligned with IGP topology. Obviously, enhancing IGPs must be timely aligned with IGP topology. Obviously, enhancing IGPs
to exchange of MPLS topology information as done by SR significantly to exchange of MPLS topology information as done by SR significantly
simplifies and stabilises such an MPLS path monitoring system. simplifies and stabilises such an MPLS path monitoring system.
This document adopts the terminology and framework described in This document adopts the terminology and framework described in
[ID.sr-archi]. It further adopts the editorial simplification [I-D.ietf-spring-segment-routing].
explained in section 1.2 of the segment routing use-cases
[ID.sr-use].
The system offers several benefits for network monitoring. A single The system offers several benefits for network monitoring. A single
centralized monitoring device is able to monitor the complete set of centralized monitoring device is able to monitor the complete set of
a domains forwarding paths. Monitoring packets never leave data a domains forwarding paths. Monitoring packets never leave data
plane. MPLS path trace function (whose specification and features plane. MPLS path trace function (whose specification and features
are not part of this use case) is required, if the actual data plane are not part of this use case) is required, if the actual data plane
of a router should be checked against its control plane. SR of a router should be checked against its control plane. SR
capabilities allow to direct MPLS OAM packets from a centralized capabilities allow to direct MPLS OAM packets from a centralized
monitoring system to any router within a domain whose path should be monitoring system to any router within a domain whose path should be
traced. traced.
skipping to change at page 4, line 23 skipping to change at page 4, line 41
support any specialised protocol stack, it just should be capable of support any specialised protocol stack, it just should be capable of
understanding the topology and building the probe packet with the understanding the topology and building the probe packet with the
right segment stack. As long as measurement packets return to this right segment stack. As long as measurement packets return to this
or another interface connecting such a server, the MPLS monitoring or another interface connecting such a server, the MPLS monitoring
servers are the single entities pushing monitoring packet label servers are the single entities pushing monitoring packet label
stacks. If the depth of label stacks to be pushed by a path stacks. If the depth of label stacks to be pushed by a path
monitoring system (PMS) are of concern for a domain, a dedicated monitoring system (PMS) are of concern for a domain, a dedicated
server based path monitoring architecture allows limiting monitoring server based path monitoring architecture allows limiting monitoring
related label stack pushes to these servers. related label stack pushes to these servers.
First drafts discussing SR OAM requirements and possible solutions to Documents discussing SR OAM requirements and possible solutions to
allow SR usage as described by this document have been submitted allow SR usage as described by this document have been submitted
already, see [ID.sr-4379ext] and [ID.sr-oam_detect]. already, see [I-D.ietf-spring-sr-oam-requirement] and
[I-D.kumarkini-mpls-spring-lsp-ping].
2. An MPLS topology aware path monitoring system 3. An MPLS Topology-Aware Path Monitoring System
An MPLS PMS which is able to learn the IGP LSDB (including the SID's) An MPLS PMS which is able to learn the IGP LSDB (including the SID's)
is able to execute arbitrary chains of label switched paths. It can is able to execute arbitrary chains of label switched paths. It can
send pure monitoring packets along such a path chain or it can direct send pure monitoring packets along such a path chain or it can direct
suitable MPLS OAM packets to any node along a path segment. Segment suitable MPLS OAM packets to any node along a path segment. Segment
Routing here is used as a means of adding label stacks and hence Routing here is used as a means of adding label stacks and hence
transport to standard MPLS OAM packets, which then detect transport to standard MPLS OAM packets, which then detect
correspondence of control and data plane of this (or any other correspondence of control and data plane of this (or any other
addressed) path. Any node connected to an SR domain is MPLS topology addressed) path. Any node connected to an SR domain is MPLS topology
aware (the node knows all related IP addresses, SR SIDs and MPLS aware (the node knows all related IP addresses, SR SIDs and MPLS
skipping to change at page 5, line 28 skipping to change at page 5, line 47
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).
Note: if the PMS is an IP host not connected to the MPLS domain, the Note: if the PMS is an IP host not connected to the MPLS domain, the
PMS can send its probe with the list of SIDs/Labels onto a suitable PMS can send its probe with the list of SIDs/Labels onto a suitable
tunnel providing an MPLS access to a router which is part of the tunnel providing an MPLS access to a router which is part of the
monitored MPLS domain. monitored MPLS domain.
3. SR based path monitoring use case illustration 4. SR-based Path Monitoring Use Case Illustration
4.1. Use Case 1 - LSP Dataplane Monitoring
3.1. Use-case 1 - LSP dataplane monitoring
+---+ +----+ +-----+ +---+ +----+ +-----+
|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 Example of a PMS based LSP dataplane monitoring
Figure 1 Figure 1
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 [ID.sr-archi], as described by section configured with the same SRGB [I-D.ietf-spring-segment-routing].
1.2 of [ID.sr-use].
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: PMS
= 10, LER i = 20, LER j = 30. = 10, LER i = 20, LER j = 30.
To be able to work with the smallest possible SR label stack, first a To be able to work with the smallest possible SR label stack, first a
suitable MPLS OAM method is used to detect the ECMP routed path suitable MPLS OAM method is used to detect the ECMP routed path
between LER i to LER j which is to be monitored (and the required between LER i to LER j which is to be monitored (and the required
address information to direct a packet along it). Afterwards the PMS address information to direct a packet along it). Afterwards the PMS
sets up and sends packets to monitor availability of the detected sets up and sends packets to monitor availability of the detected
path. The PMS does this by creating a measurement packet with the path. The PMS does this by creating a measurement packet with the
skipping to change at page 7, line 34 skipping to change at page 8, line 10
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 little effort and very monitoring complete MPLS domains with little effort and very
excellent scalability. Data plane failure detection by circulating excellent scalability. Data plane failure detection by circulating
monitoring packets can be executed at any time. The PMS further monitoring packets can be executed at any time. The PMS further
could be enabled to send MPLS OAM packets with the label stacks and could 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. It does not require access to LSR/LER any node of the MPLS domain. It does not require access to LSR/LER
management interfaces or their control plane to do so. management interfaces or their control plane to do so.
3.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 SR based probing of all the links of a remote bundle
Figure 2 Figure 2
skipping to change at page 8, line 23 skipping to change at page 8, line 43
PMS sends the probe to its connected router. If the connected router PMS sends the probe to its connected router. If the connected router
is not SR compliant, a tunneling technique can be used to tunnel the is not SR compliant, a tunneling technique can be used to tunnel the
probe and its MPLS stack to the first SR router. The MPLS/SR domain probe and its MPLS stack to the first SR router. The MPLS/SR domain
then forwards the probe to R2 (72 is the Node SID of R2). R2 then forwards the probe to R2 (72 is the Node SID of R2). R2
forwards the probe to R1 over link L1 (Adjacency SID 662). R1 forwards the probe to R1 over link L1 (Adjacency SID 662). R1
forwards the probe to R2 over link L2 (Adjacency SID 992). R2 forwards the probe to R2 over link L2 (Adjacency SID 992). R2
forwards the probe to R1 over link L3 (Adjacency SID 664). R1 then forwards the probe to R1 over link L3 (Adjacency SID 664). R1 then
forwards the IP probe to PMS as per classic IP forwarding. forwards the IP probe to PMS as per classic IP forwarding.
3.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 uni-directional fault on the middle link
in direction of R2 to R1 would be localized by sending the following in direction of R2 to R1 would be localized by sending the following
two probes with respective segment lists: two 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 fail while the second would succeed. The first probe would fail while the second would succeed.
Correlation of the measurements reveals that the only difference is Correlation of the measurements reveals that the only difference is
using the Adjacency SID 662 of the middle link from R1 to R2 in the using the Adjacency SID 662 of the middle link from R1 to R2 in the
non successful measurement. Assuming the second probe has been non successful measurement. Assuming the second probe has been
routed correctly, the fault must have been occurring in R2 which routed correctly, the fault must have been occurring in R2 which
didn't forward the packet to the interface identified by its didn't forward the packet to the interface identified by its
Adjacency SID 662. Adjacency SID 662.
4. Failure Notification from PMS to LERi 5. Failure Notification from PMS to LERi
PMS on detecting any failure in the path liveliness may use any out- PMS on detecting any failure in the path liveliness may use any out-
of-band mechanism to signal the failure to LER i. This document does of-band mechanism to signal the failure to LER i. This document does
not propose any specific mechanism and operators can choose any not propose any specific mechanism and operators can choose any
existing or new approach. existing or new approach.
Alternately, the Operator may log the failure in local monitoring Alternately, the Operator may log the failure in local monitoring
system and take necessary action by manual intervention. system and take necessary action by manual intervention.
5. Applying SR to monitor LDP paths 6. Applying SR to Monitoring LDP Paths
A SR based PMS connected to a MPLS domain consisting of LER and LSR A SR based PMS connected to a MPLS domain consisting of LER and LSR
supporting SR and LDP in parallel in all nodes may use SR paths to supporting SR and LDP in parallel in all nodes may use SR paths to
transmit packets to and from start and end points of LDP paths to be transmit packets to and from start and end points of LDP paths to be
monitored. In the above example, the label stack top to bottom may monitored. In the above example, the label stack top to bottom may
be as follows, when sent by the PMS: be as follows, when 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 label identifying the path to LER j at LER i. o Next: LDP label identifying the path to LER j at LER i.
o Bottom: SR based Node-SID identifying the path to the PMS at LER j 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 IGP and use this information.
6. PMS monitoring of different Segment ID types 7. PMS Monitoring of Different Segment ID Types
MPLS SR topology awareness should allow the SID to monitor liveliness MPLS SR topology awareness should allow the SID to monitor liveliness
of most types of SIDs (this may not be recommendable if a SID of most types of SIDs (this may not be recommendable if a SID
identifies an inter domain interface). identifies an inter domain interface).
To match control plane information with data plane information, MPLS To match control plane information with data plane information, MPLS
OAM functions as defined by e.g. RFC4379 should be enhanced to allow OAM functions as defined for example by RFC 4379 [RFC4379] should be
collection of data relevant to check all relevant types of Segment enhanced to allow collection of data relevant to check all relevant
IDs. types of Segment IDs.
7. Connectivity Verification using PMS 8. Connectivity Verification Using PMS
While the PMS based use cases explained in Section 3 are sufficient While the PMS based use cases explained in Section 3 are sufficient
to provide continuity check between LER i and LER j, it may not help to provide continuity check between LER i and LER j, it may not help
perform connectivity verification. So in some cases like data plane perform connectivity verification. So in some cases like data plane
programming corruption, it is possible that a transit node between programming corruption, it is possible that a transit node between
LER i and LER j erroneously removes the top segment ID and forwards a LER i and LER j erroneously removes the top segment ID and forwards a
monitoring packet to the PMS based on the bottom segment ID leading monitoring packet to the PMS based on the bottom segment ID leading
to a falsified path liveliness indication by the PMS. to a falsified path liveliness indication by the PMS.
There are various method to perform basic connectivity verification There are various method to perform basic connectivity verification
like intermittently setting the TTL to 1 in bottom label so LER j like intermittently setting the TTL to 1 in bottom label so LER j
selectively perform connectivity verification. Other methods are selectively perform connectivity verification. Other methods are
possible and may be added when requirements and solutions are possible and may be added when requirements and solutions are
specified. specified.
8. Extensions of related standards helpful for this use case 9. Extensions of Specifications Relevant to this Use Case
The following activities are welcome enhancements supporting this use The following activities are welcome enhancements supporting this use
case, but they are not part of it: case, but they are not part of it:
RFC4379 functions should be extended to support Flow- and Entropy RFC 4379 [RFC4379] functions should be extended to support Flow- and
Label based ECMP. Entropy Label based ECMP.
9. IANA Considerations 10. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Security Considerations 11. Security Considerations
As mentioned in the introduction, a PMS monitoring packet should As mentioned in the introduction, a PMS monitoring packet should
never leave the domain where it originated. It therefore should never leave the domain where it originated. It therefore should
never use stale MPLS or IGP routing information. Further, assigning never use stale MPLS or IGP routing information. Further, assigning
different label ranges for different purposes may be useful. A well different label ranges for different purposes may be useful. A well
known global service level range may be excluded for utilisation known global service level range may be excluded for utilisation
within PMS measurement packets. These ideas shouldn't start a within PMS measurement packets. These ideas shouldn't start a
discussion. They rather should point out, that such a discussion is discussion. They rather should point out, that such a discussion is
required when SR based OAM mechanisms like a SR are standardised. required when SR based OAM mechanisms like a SR are standardised.
11. Acknowledgement 12. 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. Raik Leipnitz kindly provided an editorial review.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
DOI 10.17487/RFC4379, February 2006, DOI 10.17487/RFC4379, February 2006,
<http://www.rfc-editor.org/info/rfc4379>. <http://www.rfc-editor.org/info/rfc4379>.
12.2. Informative References 13.2. Informative References
[ID.sr-4379ext] [I-D.ietf-isis-segment-routing-extensions]
IETF, "Label Switched Path (LSP) Ping/Trace for Segment Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Routing Networks Using MPLS Dataplane", IETF, Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
http://datatracker.ietf.org/doc/ Extensions for Segment Routing", draft-ietf-isis-segment-
draft-kumar-mpls-spring-lsp-ping/, 2013. routing-extensions-06 (work in progress), December 2015.
[ID.sr-archi] [I-D.ietf-ospf-segment-routing-extensions]
IETF, "Segment Routing Architecture", IETF, Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
https://datatracker.ietf.org/doc/draft-filsfils-spring- Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
segment-routing/, 2014. Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-07 (work in progress), March 2016.
[ID.sr-isis] [I-D.ietf-spring-segment-routing]
IETF, "IS-IS Extensions for Segment Routing", IETF, Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
http://datatracker.ietf.org/doc/ and R. Shakir, "Segment Routing Architecture", draft-ietf-
draft-previdi-isis-segment-routing-extensions/, 2014. spring-segment-routing-07 (work in progress), December
2015.
[ID.sr-oam_detect] [I-D.ietf-spring-sr-oam-requirement]
IETF, "Detecting Multi-Protocol Label Switching (MPLS) Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
Data Plane Failures in Source Routed LSPs", IETF, and S. Litkowski, "OAM Requirements for Segment Routing
http://datatracker.ietf.org/doc/ Network", draft-ietf-spring-sr-oam-requirement-01 (work in
draft-kini-spring-mpls-lsp-ping/, 2013. progress), December 2015.
[ID.sr-use] [I-D.kumarkini-mpls-spring-lsp-ping]
IETF, "Segment Routing Use Cases", IETF, Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini,
http://datatracker.ietf.org/doc/ S., Gredler, H., and M. Chen, "Label Switched Path (LSP)
draft-filsfils-rtgwg-segment-routing-use-cases/, 2013. Ping/Trace for Segment Routing Networks Using MPLS
Dataplane", draft-kumarkini-mpls-spring-lsp-ping-06 (work
in progress), March 2016.
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 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 US
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
US US
Email: naikumar@cisco.com Email: naikumar@cisco.com
 End of changes. 38 change blocks. 
89 lines changed or deleted 106 lines changed or added

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