< draft-geib-spring-oam-usecase-02.txt   draft-geib-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: January 3, 2015 C. Pignataro Expires: April 17, 2015 C. Pignataro
N. Kumar N. Kumar
Cisco Systems, Inc. Cisco Systems, Inc.
July 2, 2014 October 14, 2014
Use case for a scalable and topology aware MPLS data plane monitoring Use case for a scalable and topology aware MPLS data plane monitoring
system system
draft-geib-spring-oam-usecase-02 draft-geib-spring-oam-usecase-03
Abstract Abstract
This document describes features and a use case of a path monitoring This document describes features and a use case of a path monitoring
system. Segment based routing enables a scalable and simple method system. Segment based routing enables a scalable and simple method
to monitor data plane liveliness of the complete set of paths to monitor data plane liveliness of the complete set of paths
belonging to a single domain. Compared with legacy MPLS ping and belonging to a single domain. Compared with legacy MPLS ping and
path trace, MPLS topology awareness reduces management and control path trace, MPLS topology awareness reduces management and control
plane involvement of OAM measurements while enabling new OAM plane involvement of OAM measurements while enabling new OAM
features. features.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 January 3, 2015. This Internet-Draft will expire on April 17, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. An MPLS topology aware path monitoring system . . . . . . . . 4 2. An MPLS topology aware path monitoring system . . . . . . . . 4
3. SR based OAM use case illustration . . . . . . . . . . . . . . 5 3. SR based path monitoring use case illustration . . . . . . . . 6
3.1. Use-case 1 - LSP dataplane liveliness detection and 3.1. Use-case 1 - LSP dataplane monitoring . . . . . . . . . . 6
monitoring . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Use-case 2 - Monitoring a remote bundle . . . . . . . . . 8 3.2. Use-case 2 - Monitoring a remote bundle . . . . . . . . . 8
3.3. Use-Case 3 - Fault localization . . . . . . . . . . . . . 8 3.3. Use-Case 3 - Fault localization . . . . . . . . . . . . . 8
4. Failure Notification from PMS to LERi . . . . . . . . . . . . 9 4. Failure Notification from PMS to LERi . . . . . . . . . . . . 9
5. Applying SR to monitor LDP paths . . . . . . . . . . . . . . . 9 5. Applying SR to monitor LDP paths . . . . . . . . . . . . . . . 9
6. PMS monitoring of different Segment ID types . . . . . . . . . 9 6. PMS monitoring of different Segment ID types . . . . . . . . . 9
7. Connectivity Verification using PMS . . . . . . . . . . . . . 10 7. Connectivity Verification using PMS . . . . . . . . . . . . . 10
8. Extensions of related standards . . . . . . . . . . . . . . . 10 8. Extensions of related standards helpful for this use case . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. 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
must be forwarded in dataplane in a similar way as user packets. is expected to be forwarded in dataplane in a similar way as user
Problem localization is required. packets. Segment Routing enables forwarding of packets along pre-
defined paths and segments and thus a Segment Routed monitoring
This document describes a solution to this problem statement and packet can stay in dataplane while passing along one or more segments
illustrates it with use-cases. to be monitored.
The solution is described for a single IGP MPLS domain. This document describes illustrates use-cases based on data plane
path monitoring capabilities. The use case is limited to a single
IGP MPLS domain.
The solution applies to monitoring of LDP LSP's as well as to The use case applies to monitoring of LDP LSP's as well as to
monitoring of Segment Routed LSP's. Segment Routing simplifies the monitoring of Segment Routed LSP's. As compared to LDP, Segment
solution by the use of IGP-based signalled segments as specified by Routing is expected to simplify the use case by enabling MPLS
[ID.sr-isis]. Thus a centralised monitoring unit is MPLS topology topology detection based on IGP signaled segments as specified by
aware in a Segment Routed domain and this topology awareness is used [ID.sr-isis]. Thus a centralised and MPLS topology aware monitoring
for OAM purposes. The MPLS path monitoring system described by this unit can be realized in a Segment Routed domain. This topology
document can be realised with pre-Segment based Routing (SR) awareness can be used for OAM purposes as described by this use case.
technology. Making such a monitoring system aware of a domains The MPLS path monitoring system described by this document can be
complete MPLS topology requires e.g. management plane access. To realised with pre-Segment based Routing (SR) technology. Making such
avoid the use of stale MPLS label information, IGP must be monitored a pre-SR MPLS monitoring system aware of a domains complete MPLS
and MPLS topology must be timely aligned with IGP topology. topology requires e.g. management plane access. To avoid the use of
Obviously, enhancing IGPs to exchange of MPLS topology information stale MPLS label information, IGP must be monitored and MPLS topology
significantly simplifies and stabilises such an MPLS path monitoring must be timely aligned with IGP topology. Obviously, enhancing IGPs
system. to exchange of MPLS topology information as done by SR significantly
simplifies and stabilises such an MPLS path monitoring system.
This document adopts the terminology and framework described in This document adopts the terminology and framework described in
[ID.sr-archi]. It further adopts the editorial simplification [ID.sr-archi]. It further adopts the editorial simplification
explained in section 1.2 of the segment routing use-cases explained in section 1.2 of the segment routing use-cases
[ID.sr-use]. [ID.sr-use].
The proposed solution offers several benefits for network monitoring. The use case offers several benefits for network monitoring. A
A single centralized monitoring device is able to monitor the single centralized monitoring device is able to monitor the complete
complete set of a domains forwarding paths. OAM packets never leave set of a domains forwarding paths. Monitoring packets never leave
data plane. Legacy path trace is still required. In addition to data plane. MPLS path trace function (whose specification and
Segment Routing related IGP extensions, also RFC 4379 features should features are not part of this use case) is required, if the actual
be extended to support detection of SR routed paths. They further data plane of a router should be checked against its control plane.
should be enhanced to support all deployed IP/MPLS entropy options. SR capabilities allow to direct MPLS OAM packets from a centralized
In an IPv6 domain, a MPLS like tree trace functionality is desirable. monitoring system to any router within a domain whose path should be
traced.
In addition to monitoring paths, problem localization is required.
Faults can be localized: Faults can be localized:
o by IGP LSA analysis. o by IGP LSA analysis.
o by correlation between different probes. o correlation between different SR based monitoring probes.
o by MPLS traceroute and adapted ping messages. o by any MPLS traceroute method (possibly in combination with SR
based path stacks).
The proposed solution requires topology awareness as well as a Topology awareness is an essential part of link state IGPs. Adding
suitable security architecture. Topology awareness is an essential MPLS topology awareness to an IGP speaking device hence enables a
part of link state IGPs. Adding MPLS topology awareness to an IGP simple and scalable data plane based monitoring mechanism.
speaking device hence enables a simple and scaleable data plane
monitoring mechanism.
MPLS OAM offers flexible features to recognise an execute data paths MPLS OAM offers flexible features to recognise an execute data paths
of an MPLS domain. By utilsing the ECMP related tool set of RFC 4379 of an MPLS domain. By utilsing the ECMP related tool set offered
[RFC4379], a segment based routing LSP monitoring system may: e.g. by RFC 4379 [RFC4379], a segment based routing LSP monitoring
system may:
o easily detect ECMP functionality and properties of paths at data o easily detect ECMP functionality and properties of paths at data
level. level.
o construct monitoring packets executing desired paths also if ECMP o construct monitoring packets executing desired paths also if ECMP
is present. is present.
o limit the MPLS label stack of an OAM packet to a minmum of 3 o limit the MPLS label stack of an OAM packet to a minmum of 3
labels. labels.
MPLS OAM supports detection and execution of ECMP paths quite smart.
This document is foscused on MPLS path monitoring.
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 a specialised system residing The MPLS path monitoring system may be a any server residing at a
at a single interface of the domain to be monitored. As long as single interface of the domain to be monitored. It doesn't have to
measurement packets return to this or another interface to a support any specialised protocol stack, it just should be capable of
specialised OAM system, the MPLS monitoring system is the single understanding the topology and building the probe packet with the
entity pushing monitoring packet label stacks. Concerns about router right segment stack. As long as measurement packets return to this
label stack pushing capabilities don't apply in this case. or another interface connecting such a server, the MPLS monitoring
servers are the single entities pushing monitoring packet label
stacks. If the depth of label stacks to be pushed by a PMS are of
concern for a domain, a dedicated server based path monitoring
architecture allows limiting monitoring related label stack pushes to
these servers.
First drafts discussing requirements, extensions of RFC4379 and First drafts discussing SR OAM requirements and possible solutions to
possible solutions to allow SR usage as described by this document allow SR usage as described by this document have been submitted
are at hand, see [ID.sr-4379ext] and [ID.sr-oam_detect]. already, see [ID.sr-4379ext] and [ID.sr-oam_detect].
2. An MPLS topology aware path monitoring system 2. An MPLS topology aware path monitoring system
An MPLS path monitoring system (PMS) which is able to learn the IGP An MPLS path monitoring system (PMS) which is able to learn the IGP
LSDB (including the SID's) is able to build a measurement packet LSDB (including the SID's) is able to execute arbitrary chains of
which executes every arbitrary chain of paths. A node connected to label switched paths. It can send pure monitoring packets along such
an SR domain is MPLS topology aware (the node knows all related IP a path chain or it can direct suitable MPLS OAM packets to any node
adresses, MPLS SIDs and labels). along a path segment. Segment Routing here is used as a means of
adding label stacks and hence transport to standard MPLS OAM packets,
which then detect correspondence of control and data plane of this
(or any other addressed) path. Any node connected to an SR domain is
MPLS topology aware (the node knows all related IP addresses, SR SIDs
and MPLS labels). Thus a PMS connected to an MPLS SR domain just
needs to set up a topology data base for monitoring purposes.
Let us describe how the PMS can check the liveliness of the MPLS Let us describe how the PMS constructs a labels stack to transport a
transport path between LER i and LER j and then monitor it. packet to LER i, monitor the path of it to LER j and then receive the
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 infomation: label stack infomation:
o Top Label: a path from PMS to LER i This is expressed as Node SID o Top Label: a path from PMS to LER i This is expressed as Node SID
of LER i. 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 AdjSID. connected interfaces), it can be expressed by the related AdjSID.
skipping to change at page 5, line 35 skipping to change at page 5, line 48
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 the
probe just needs to return to the PMS. This is best achieved by probe just needs to return to the PMS. This is best achieved by
popping the MPLS stack and revealing a probe packet with PMS as 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).
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 provding 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 OAM use case illustration 3. SR based path monitoring use case illustration
3.1. Use-case 1 - LSP dataplane liveliness detection and 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 liveness detection and Example of a PMS based LSP dataplane monitoring
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 [ID.sr-archi], as described by section
1.2 of [ID.sr-use]. 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.
The aim is to check liveliness of the path LER i to LER j and to To be able to work with the smallest possible SR label stack, first A
monitor availability of that path afterwards. The PMS does this by suitable MPLS OAM method is used to detect the ECMP routed path
creating a measurement packet with the following label stack (top to between LER i to LER j which is to be monitored (and the required
bottom): 20 - 30 - 10. address information to direct a packet along it). Afterwards the PMS
sets up and sends packets to monitor availability of the detected
path. The PMS does this by creating a measurement packet with the
following label stack (top to bottom): 20 - 30 - 10. The packet will
only reliably use the monitored path, if the label and address
information used in combination with the MPLS OAM method of choice is
identical to that of the monitoring packet.
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 Pen-ultimate Hop Popping to be 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. This path must be o The path PMS to LER i must be available. This path must be
detectable, but it is usually sufficient to apply an SPF based detectable, but it is usually sufficient to apply an SPF based
path. path.
o If ECMP is deployed, it may be desired to measure along both o If ECMP is deployed, it may be desired to measure along both
possible paths, a packet may use between LER i and LER j. To do possible paths which a packet may use between LER i and LER j. To
so, in a first step the PMS sends MPLS OAM packets to execute a so do so, the MPLS OAM mechanism chosen to detect ECMP must reveal
called tree trace between LER i and LER j and stores the IP the required information (an example is a so called tree trace)
destination addresses required to execute each detected path. between LER i and LER j. This method of dealing with ECMP based
This method of dealing with load balancing paths requires the load balancing paths requires the smallest SR label stacks if
smallest label stacks if long term monitoring of paths is applied monitoring of paths is applied after the tree trace completion.
after the tree trace completion.
o The path LER j to PMS to must be be available. This path must be o The path LER j to PMS to must be available. This path must be
detectable, but it is usually sufficient to apply an SPF based detectable, but it is usually sufficient to apply an SPF based
path. path.
Once the MPLS paths (Node SIDs) and the required IP address Once the MPLS paths (Node SIDs) and the required information to deal
information has been detected, the LER i to LER j can be monitored by with ECMP has been detected, the paths of LER i to LER j can be
the PMS. Monitoring doesn't require MPLS OAM functionality, it is monitored by the PMS. Monitoring itself does not require MPLS OAM
purely based on forwarding. To ensure reliable results, the PMS functionality. All monitoring packets stay on dataplane, hence path
should be aware of any changes in IGP or MPLS topology. Further monitoring does no longer require control plane interaction in any
changes in ECMP functionality at LER i will impact results. Either LER or LSR of the domain. To ensure reliable results, the PMS should
the PMS should be notified of such changes or they should be limited be aware of any changes in IGP or MPLS topology. Further changes in
to planned maintenance. After a topology change, MPLS OAM will be ECMP functionality at LER i will impact results. Either the PMS
useful to detect the impact of the change. should be notified of such changes or they should be limited to
planned maintenance. After a topology change, a suitable MPLS OAM
mechanism may be useful to detect the impact of the change.
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 including all node SIDs along that path done by setting up a label stack including all Node SIDs along that
(if LER1 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 MPLS OAM advantage of this method is, that it does not involve MPLS OAM
functionality and it is independent of ECMP functionalities. The functionality and it is independent of ECMP functionalities. The
method still is able to monitor all link combinations of all paths of method still is able to monitor all link combinations of all paths of
an MPLS domain. If correct forwarding along the desired paths has to an MPLS domain. If correct forwarding along the desired paths has to
be checked, RFC4739 functionality should be applied also in this be checked, some suitable MPLS OAM mechanism may be applied also in
case. this case.
Obviously, the PMS is able to check and monitor data plane liveliness In theory at least, a single PMS is able to monitor data plane
of all LSPs in the domain. The PMS may be a router, but could also availability of all LSPs in the domain. The PMS may be a router, but
be dedicated monitoring system. If measurement system reliability is could also be dedicated monitoring system. If measurement system
an issue, more than a single PMS may be connected to the MPLS domain. 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 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
executes MPLS OAM functions everywhere in the MPLS domain. It does could be enabled to send MPLS OAM packets with the label stacks and
not require access to LSR/LER management interfaces to do so. MPLS address information identical to those of the monitoring packets to
traceroutes as specified above should be executed only during off any node of the MPLS domain. It does not require access to LSR/LER
peak times (and then with limited parallel MPLS ping/trace load). management interfaces or their control plane to do so.
3.2. Use-case 2 - Monitoring a remote bundle 3.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
R1 adresses Lx by the Adjacency SID 99x, while R2 adresses Lx by the R1 addresses Lx by the Adjacency SID 99x, while R2 addresses Lx by
Adjacency SID 66(x+1). the Adjacency 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 dataplane
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).
skipping to change at page 9, line 12 skipping to change at page 9, line 20
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 4. 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 te\he failure to LERi. This document of-band mechanism to signal the failure to LER i. This document does
does not not propose any specific mechanism and Operators can choose not propose any specific mechanism and operators can choose any
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 5. Applying SR to monitor 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 parrallel 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 6. 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, To match control plane information with data plane information, MPLS
RFC4379 should be enhanced to allow collection of data relevant to OAM functions as defined by e.g. RFC4379 should be enhanced to allow
check all relevant types of Segment IDs. collection of data relevant to check all relevant types of Segment
IDs.
7. Connectivity Verification using PMS 7. Connectivity Verification using PMS
While the PMS based use cases explained in Section 3 is sufficient to While the PMS based use cases explained in Section 3 are sufficient
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 remove the top segment ID and forward to LER i and LER j erroneously removes the top segment ID and forwards a
PMS based on bottom segment ID leading to falsified path liveliness monitoring packet to the PMS based on the bottom segment ID leading
to 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 intermittely setting the TTL to 1 in bottom label so LER j like intermittely setting the TTL to 1 in bottom label so LER j
selectively perform connectivity verification. A detailed selectively perform connectivity verification. Other methods are
explanation will be added in later version. possible and may be added when requirements and solutions are
specified.
8. Extensions of related standards 8. Extensions of related standards helpful for this use case
The following activities are welcome enhancements supporting this use
case, but they are not part of it:
RFC4379 functions should be extended to support Flow- and Entropy RFC4379 functions should be extended to support Flow- and Entropy
Label based ECMP. Further, an RFC4379 like functionality may be Label based ECMP.
desirable for IPv6 networks.
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
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, asigning 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 shoulddn'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 11. Acknowledgement
The authors would like to thank Nobo Akiya for his cotribution. The authors would like to thank Nobo Akiya for his contribution.
12. References 12. References
12.1. Normative References 12.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,
February 2006. February 2006.
12.2. Informative References 12.2. Informative References
[ID.sr-4379ext] [ID.sr-4379ext]
IETF, "Label Switched Path (LSP) Ping/Trace for Segment IETF, "Label Switched Path (LSP) Ping/Trace for Segment
Routing Networks Using MPLS Dataplane", IETF, http:// Routing Networks Using MPLS Dataplane", IETF, http://
datatracker.ietf.org/doc/draft-kumar-mpls-spring-lsp- datatracker.ietf.org/doc/draft-kumar-mpls-spring-lsp-
ping/, 2013. ping/, 2013.
[ID.sr-archi] [ID.sr-archi]
IETF, "Segment Routing Architecture", IETF, https:// IETF, "Segment Routing Architecture", IETF, https://
datatracker.ietf.org/doc/ datatracker.ietf.org/doc/
draft-filsfils-rtgwg-segment-routing/, 2013. draft-filsfils-spring-segment-routing/, 2014.
[ID.sr-isis] [ID.sr-isis]
IETF, "IS-IS Extensions for Segment Routing", IETF, http: IETF, "IS-IS Extensions for Segment Routing", IETF, http:
//datatracker.ietf.org/doc/ //datatracker.ietf.org/doc/
draft-previdi-isis-segment-routing-extensions/, 2013. draft-previdi-isis-segment-routing-extensions/, 2014.
[ID.sr-oam_detect] [ID.sr-oam_detect]
IETF, "Detecting Multi-Protocol Label Switching (MPLS) IETF, "Detecting Multi-Protocol Label Switching (MPLS)
Data Plane Failures in Source Routed LSPs", IETF, http:/ Data Plane Failures in Source Routed LSPs", IETF, http:/
/datatracker.ietf.org/doc/draft-kini-spring-mpls-lsp- /datatracker.ietf.org/doc/draft-kini-spring-mpls-lsp-
ping/, 2013. ping/, 2013.
[ID.sr-use] [ID.sr-use]
IETF, "Segment Routing Use Cases", IETF, http:// IETF, "Segment Routing Use Cases", IETF, http://
datatracker.ietf.org/doc/ datatracker.ietf.org/doc/
 End of changes. 49 change blocks. 
129 lines changed or deleted 155 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/