draft-ietf-spring-oam-usecase-05.txt   draft-ietf-spring-oam-usecase-06.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: August 11, 2017 C. Pignataro, Ed. Expires: August 25, 2017 C. Pignataro, Ed.
N. Kumar N. Kumar
Cisco Systems, Inc. Cisco Systems, Inc.
February 7, 2017 February 21, 2017
A Scalable and Topology-Aware MPLS Dataplane Monitoring System A Scalable and Topology-Aware MPLS Dataplane Monitoring System
draft-ietf-spring-oam-usecase-05 draft-ietf-spring-oam-usecase-06
Abstract Abstract
This document describes features of a path monitoring system and This document describes features of a path monitoring system and
related use cases. Segment based routing enables a scalable 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 path trace, in a very features to the traditional MPLS ping and LSP path 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
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 August 7, 2017. This Internet-Draft will expire on August 25, 2017.
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 (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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. An MPLS Topology-Aware Path Monitoring System . . . . . . . . 6 4. An MPLS Topology-Aware Path Monitoring System . . . . . . . . 6
5. SR-based Path Monitoring Use Case Illustration . . . . . . . 7 5. SR-based Path Monitoring Use Case Illustration . . . . . . . 7
5.1. Use Case 1 - LSP Dataplane Monitoring . . . . . . . . . . 7 5.1. Use Case 1 - LSP Dataplane Monitoring . . . . . . . . . . 7
5.2. Use Case 2 - Monitoring a Remote Bundle . . . . . . . . . 10 5.2. Use Case 2 - Monitoring a Remote Bundle . . . . . . . . . 10
5.3. Use Case 3 - Fault Localization . . . . . . . . . . . . . 11 5.3. Use Case 3 - Fault Localization . . . . . . . . . . . . . 11
6. Failure Notification from PMS to LERi . . . . . . . . . . . . 11 6. Failure Notification from PMS to LERi . . . . . . . . . . . . 11
7. Applying SR to Monitoring non-SR based LSPs (LDP and possibly 7. Applying SR to Monitoring non-SR based LSPs (LDP and possibly
RSVP-TE) . . . . . . . . . . . . . . . . . . . . . . . . . . 12 RSVP-TE) . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. PMS Monitoring of Different Segment ID Types . . . . . . . . 13 8. PMS Monitoring of Different Segment ID Types . . . . . . . . 12
9. Connectivity Verification Using PMS . . . . . . . . . . . . . 13 9. Connectivity Verification Using PMS . . . . . . . . . . . . . 13
10. Extensions of Specifications Relevant to this Use Case . . . 13 10. Extensions of Specifications Relevant to this Use Case . . . 13
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 14 14.1. Normative References . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 14 14.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Acronyms 1. Acronyms
ECMP Equal-Cost Multi-Path ECMP Equal-Cost Multi-Path
skipping to change at page 3, line 20 skipping to change at page 3, line 20
2. Introduction 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. Monitoring packets paths observed by the transported user packets. Monitoring packets
are expected to be forwarded in dataplane in a similar way as user are 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 a system using MPLS data plane path
path monitoring capabilities. The use cases introduced here are monitoring capabilities. The use cases introduced here are limited
limited to a single Interior Gateway Protocol (IGP) MPLS domain. to a single Interior Gateway Protocol (IGP) MPLS domain.
The system applies to monitoring of pre Segment Routing LSP's ( like The system applies to monitoring of pre Segment Routing LSP's ( like
LDP) as well as to monitoring of Segment Routed LSP's (section 7 LDP) as well as to monitoring of Segment Routed LSP's (section 7
offers some more information). As compared to pre Segment Routing offers some more information). As compared to pre Segment Routing
approaches, Segment Routing is expected to simplify such a monitoring approaches, Segment Routing is expected to simplify such a monitoring
system by enabling MPLS topology detection based on IGP signaled system by enabling MPLS topology detection based on IGP signaled
segments as specified by specified by segments as specified by specified by
[I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-idr-bgp-ls-segment-routing-ext]. Thus a centralised and [I-D.ietf-idr-bgp-ls-segment-routing-ext]. Thus a centralised and
MPLS topology aware monitoring unit can be realized in a Segment MPLS topology aware monitoring unit can be realized in a Segment
Routed domain. This topology awareness can be used for OAM purposes Routed domain. This topology awareness can be used for OAM purposes
as described by this document. as described by this document.
The system offers several benefits for network monitoring: The system offers several benefits for network monitoring:
o A single centralized MPLS monitoring system which is able to o A single centralized MPLS monitoring system which is able to
perform a continuity check (ping) along all Label Switched Paths perform a continuity check (ping) along all Label Switched Paths
of the SR domain. Monitoring packets never leave data plane. of the SR domain.
o The MPLS ping (or continuity check) packets never leave the MPLS o The MPLS ping (or continuity check) packets never leave the MPLS
data plane. user data plane.
o SR allows to transport MPLS path trace or connectivity validation o SR allows to transport MPLS path trace or connectivity validation
packets for any existing Label Switched Path to all nodes of an SR packets for any existing Label Switched Path to all nodes of an SR
domain. This use case doesn't describe any new path trace domain. This use case doesn't describe any new path trace
features, but the system described here allows to set up an SR features, but the system described here allows to set up an SR
domain wide centralised connectivity validation. domain wide centralised connectivity validation.
o An MPLS monitoring system, maybe several ones if redundancy is o The system sending the monitoring packet is also receiving it.
desired, which apply SR for OAM purposes as described, offer the The payload of the monitoring packet may be chosen freely. This
possibilty to scale and design a flexible MPLS OAM platform as allows sending probing packets representing customer traffic,
suitable for a provider. possibly from multiple services (e.g., small VoIP packet, larger
HTTP packets) and embedding of useful monitoring data (e.g.,
accurate time stamps since both sender and receiver have the same
clock, sequence numbers to ease the measurement...).
o Set up of a flexible MPLS monitoring system in terms of
deployment: from one single centralized one to a set of
distributed systems (e.g., on a per region or service base), and
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.
Faults can be localized: Faults can be localized:
o by capturing the Interior Gateway Protocol (IGP) topology and o by capturing the Interior Gateway Protocol (IGP) topology and
analysing IGP messages indicating changes of it. analysing IGP messages indicating changes of it.
o by correlation between different SR based monitoring probes. o by correlation between different SR based monitoring probes.
o by setting up an MPLS traceroute packet for a path (or Segment) to o by setting up an MPLS traceroute packet for a path (or Segment) to
skipping to change at page 4, line 33 skipping to change at page 4, line 41
MPLS topology awareness to an IGP speaking device hence enables a MPLS topology awareness to an IGP speaking device hence enables a
simple and scalable data plane based monitoring mechanism. simple and scalable data plane based monitoring mechanism.
MPLS OAM offers flexible traceroute (connectivity verification) MPLS OAM offers flexible traceroute (connectivity verification)
features to recognise and execute data paths of an MPLS domain. By features to recognise and execute data paths of an MPLS domain. By
utilising the ECMP related tool set offered, e.g., by RFC 4379 utilising the ECMP related tool set offered, e.g., by RFC 4379
[RFC4379], a SR based MPLS monitoring system can be enabled to: [RFC4379], a SR based MPLS monitoring system can be enabled to:
o detect how to route packets along different ECMP routed paths. o detect how to route packets along different ECMP routed paths.
o construct ping packets respectively, which can be precisely o construct ping packets, which can be precisely steered to paths
steered to paths whose connectivity is to be checked, also if ECMP whose connectivity is to be checked, also if ECMP is present.
is present.
o limit the MPLS label stack of such a ping packet checking o limit the MPLS label stack of such a ping packet checking
continuity of every single IGP-Segment to the maximum number of 3 continuity of every single IGP-Segment to the maximum number of 3
labels. A smaller label stack may also be helpful, if any router labels. A smaller label stack may also be helpful, if any router
interprets a limited number of packet header bytes to determine an interprets a limited number of packet header bytes to determine an
ECMP path along which to route a packet. ECMP path along which to route a packet.
Alternatively, any path may be executed by building suitable label Alternatively, any path may be executed by building suitable label
stacks. This allows path execution without ECMP awareness. stacks. This allows path execution without ECMP awareness.
The MPLS Path Monitoring System may be any server residing at a The MPLS Path Monitoring System may be any server residing at a
single interface of the domain to be monitored. The PMS doesn't need single interface of the domain to be monitored. The PMS doesn't need
to support the complete MPLS routing or control plane. It needs to to support the complete MPLS routing or control plane. It needs to
be capable to learn and maintain an accurate MPLS and IGP topology. be capable to learn and maintain an accurate MPLS and IGP topology.
MPLS ping and traceroute packets need to be set up and sent with the MPLS ping and traceroute packets need to be set up and sent with the
correct segment stack. The PMS further must be able to receive and correct segment stack. The PMS further must be able to receive and
decode returning ping or traceroute packets. Packets used to check decode returning ping or traceroute packets. Packets used to check
continuity could have BFD or LSP Ping format, or have any other OAM continuity could have BFD or LSP Ping format, or have any other OAM
format supported by the PMS. As long as the packet used to check format supported by the PMS. As long as the packet used to check
continuity returns back to the server while no IGP change is continuity returns back to the server while no IGP change is
detected, the monitored path can be considered as validated. If the detected, the monitored path can be considered as validated. If
depth of label stacks to be pushed for the purpose of path monitoring monitoring requires pushing a large label stack, a software based
is of concern for a domain, a dedicated PMS server allows to push implementation is usually more flexible than an hardware based one.
monitoring related label stacks of arbitrary depth on this server. Hence router label stack depth and label composition limitations
Hence router label stack limitations don't limit MPLS OAM choices. don't limit MPLS OAM choices.
Documents discussing SR OAM requirements and MPLS traceroute Documents discussing SR OAM requirements and MPLS traceroute
enhancements adding functionality to the use cases described by this enhancements adding functionality to the use cases described by this
document are in work within IETF, see document are in work within IETF, see
[I-D.ietf-spring-sr-oam-requirement] and [I-D.ietf-spring-sr-oam-requirement] and
[I-D.draft-ietf-mpls-spring-lsp-ping]. [I-D.draft-ietf-mpls-spring-lsp-ping].
3. Terminology 3. Terminology
Continuity Check Continuity Check
skipping to change at page 5, line 33 skipping to change at page 5, line 41
RFC 7276 [RFC7276] defines Continuity Checks to be used to verify RFC 7276 [RFC7276] defines Continuity Checks to be used to verify
that a destination is reachable, and are typically sent that a destination is reachable, and are typically sent
proactively, though they can be invoked on-demand as well. proactively, though they can be invoked on-demand as well.
Segment Routing allows to realise a continuity check along any Segment Routing allows to realise a continuity check along any
given SR domain path within data plane. given SR domain path within data plane.
Connectivity Verification Connectivity Verification
RFC 7276 [RFC7276] defines Connectivity Verification as a RFC 7276 [RFC7276] defines Connectivity Verification as a
mechanism to check connectivity between two nodes by checking mechanism to check connectivity between two nodes by checking
whether a path between both can be used. RFC 4379 [RFC7276] whether a path between both can be used. RFC 4379 [RFC4379]
specifies a Connectivity Verification for MPLS domains. As RFC
7276 sates, Connectivity Verification and Continuity Checks are
considered complementary mechanisms and are often used in
conjunction with each other. The use cases following merely
treat SR based network monitoring as adding a new method to
realise a Continuity Check. In special cases, the SR based
Continuity Check offers limited Connectivity Verification
properties. This will be in the use case descriptions, if
applicable.
RFC 7276 [RFC7276] defines Connectivity Verification as a
mechanism to check connectivity between two nodes by checking
whether a path between both can be used. RFC 4379 [RFC7276]
specifies a Connectivity Verification for MPLS domains. As RFC specifies a Connectivity Verification for MPLS domains. As RFC
7276 sates, Connectivity Verification and Continuity Checks are 7276 states, Connectivity Verification and Continuity Checks are
considered complementary mechanisms and are often used in considered complementary mechanisms and are often used in
conjunction with each other. The use cases following merely conjunction with each other. This document proposes the use of
treat SR based network monitoring as adding a new method to SR based network monitoring as a new Continuity Check method. In
realise a Continuity Check. In special cases, the SR based some special cases, it also covers some limited Connectivity
Continuity Check offers limited Connectivity Verification Verification. When applicable, this is indicated in the
properties. This will be in the use case descriptions, if description of the use case.
applicable.
MPLS topology MPLS topology
The MPLS topology of an MPLS domain is the complete set of MPLS- The MPLS topology of an MPLS domain is the complete set of MPLS-
and IP-address information and all routing and data plane and IP-address information and all routing and data plane
information required to address and utilise every MPLS path information required to address and utilise every MPLS path
within this domain from an MPLS Path Monitoring System attached within this domain from an MPLS Path Monitoring System attached
to this MPLS domain at an arbitrary access. This document to this MPLS domain at an arbitrary access. This document
assumes availability of the MPLS topology (which can be detected assumes availability of the MPLS topology (which can be detected
with available protocols and interfaces). None of the use cases with available protocols and interfaces). None of the use cases
will describe how to set it up. will describe how to set it up.
This document further adopts the terminology and framework described This document further adopts the terminology and framework described
skipping to change at page 6, line 30 skipping to change at page 6, line 23
This document further adopts the terminology and framework described This document further adopts the terminology and framework described
in [I-D.ietf-spring-segment-routing]. in [I-D.ietf-spring-segment-routing].
4. An MPLS Topology-Aware Path Monitoring System 4. An MPLS Topology-Aware Path Monitoring System
Any node at least listening to the IGP of an SR domain is MPLS Any node at least listening to the IGP of an SR domain is MPLS
topology aware (the node knows all related IP addresses, SR SIDs and topology aware (the node knows all related IP addresses, SR SIDs and
MPLS labels). An MPLS PMS which is able to learn the IGP LSDB MPLS labels). An MPLS PMS which is able to learn the IGP LSDB
(including the SID's) is able to execute arbitrary chains of label (including the SID's) is able to execute arbitrary chains of label
switched paths. To monitor an MPLS SR domain, a PMS needs to set up switched paths. To monitor an MPLS SR domain, a PMS needs to set up
a topology data base of MPLS SR domain to be monitored. It may be a topology data base of the MPLS SR domain to be monitored. It may
used to send ping type packets to only check continuity along such a be used to send ping type packets to only check continuity along such
path chain based on the topology information only. In addition, the a path chain based on the topology information only. In addition,
PMS can be used to trace MPLS Label Switched Path and thus verify the PMS can be used to trace MPLS Label Switched Path and thus verify
their connectivity and correspondance between control and data plane, their connectivity and correspondence between control and data plane,
respectively. The PMS can direct suitable MPLS traceroute packets to respectively. The PMS can direct suitable MPLS traceroute packets to
any node along a path segment. any node along a path segment.
Let us describe how the PMS constructs a labels stack to transport a Let us describe how the PMS constructs a labels stack to transport a
packet to LER i, monitor its path to LER j and then receive the packet to LER i, monitor its path to LER j and then receive the
packet back. packet back.
The PMS may do so by sending packets carrying the following MPLS The PMS may do so by sending packets carrying the following MPLS
label stack information: label stack information:
skipping to change at page 8, line 16 skipping to change at page 8, line 10
configured with the same SRGB [I-D.ietf-spring-segment-routing]. configured with the same SRGB [I-D.ietf-spring-segment-routing].
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 set up a continuity check of the path between LER i and The aim is to set up a continuity check of the path between LER i and
LER j. As has been said, the monitoring packets are to be sent and LER j. As has been said, the monitoring packets are to be sent and
received by the PMS. Let's assume the design aim is to be able to received by the PMS. Let's assume the design aim is to be able to
work with the smallest possible SR label stack. In the given work with the smallest possible SR label stack. In the given
topology, a fairly simple option is to perform an MPLS path trace, as topology, a fairly simple option is to perform an MPLS path trace, as
specified by RFC4379. The starting point for the path trace is LER i specified by RFC4379 (using the Downstream (Detailed) Mapping
and the PMS sends the MPLS path trace packet to LER i. The MPLS echo information resulting from a "tree trace", see [RFC4379]). The
reply of LER i should be sent to the PMS. As a result, IP starting point for the path trace is LER i and the PMS sends the MPLS
destination address choices are detected, which are then used to path trace packet to LER i. The MPLS echo reply of LER i should be
target any one of the ECMP routed paths between LER i and LER j by sent to the PMS. As a result, IP destination address choices are
the MPLS ping packets to later check path continuity. The Label detected, which are then used to target any one of the ECMP routed
stack of these ping packets doesn't need to consist of more than 3 paths between LER i and LER j by the MPLS ping packets to later check
labels. Finally, the PMS sets up and sends packets to monitor path continuity. The Label stack of these ping packets doesn't need
connectivity of the ECMP routed paths. The PMS does this by creating to consist of more than 3 labels. Finally, the PMS sets up and sends
a measurement packet with the following label stack (top to bottom): packets to monitor connectivity of the ECMP routed paths. The PMS
20 - 30 - 10. The ping packets reliably use the monitored path, if does this by creating a measurement packet with the following label
the IP-address information which has been detected by the MPLS trace stack (top to bottom): 20 - 30 - 10. The ping packets reliably use
route is used as the IP destination address (note that this IP the monitored path, if the IP-address information which has been
address isn't used or required for any IP routing). detected by the MPLS trace route is used as the IP destination
address (note that this IP address isn't used or required for any IP
routing).
LER m forwards the packet received from the PMS to LSR1. Assuming LER m forwards the packet received from the PMS to LSR1. Assuming
Pen-ultimate Hop Popping to be deployed, LSR1 pops the top label and 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:
skipping to change at page 9, line 4 skipping to change at page 8, line 49
trace route may be used to exactly detect the data plane path trace route may be used to exactly detect the data plane path
taken for this MPLS Segment. It is usually sufficient to just taken for this MPLS Segment. It is usually sufficient to just
apply any of the existing Shortest Path routed paths. apply any of the existing Shortest Path routed paths.
o If ECMP is deployed, separate continuity checks monitoring all o If ECMP is deployed, separate continuity checks monitoring all
possible paths which a packet may use between LER i and LER j may possible paths which a packet may use between LER i and LER j may
be desired. This can be done by applying an MPLS trace route be desired. This can be done by applying an MPLS trace route
between LER i and LER j. Another option is to use SR routing, but between LER i and LER j. Another option is to use SR routing, but
this will likely require additional label information within the this will likely require additional label information within the
label stack of the ping packet. Further, if multiple links are label stack of the ping packet. Further, if multiple links are
deplyed between two nodes, SR methods to address each individual deployed between two nodes, SR methods to address each individual
path require an Adj-SID to be assigned to each single interface. path require an Adj-SID to be assigned to each single interface.
This method is based on control plane information - a connectivity This method is based on control plane information - a connectivity
verification based on MPLS traceroute seems to be a fairly good verification based on MPLS traceroute seems to be a fairly good
option to deal with ECMP and validation of control and data plane option to deal with ECMP and validation of control and data plane
correlation. correlation.
o The path LER j to PMS must be available (i.e., a continuity check o The path LER j to PMS must be available (i.e., a continuity check
only along the path from LER j to PMS must succeed). If desired, only along the path from LER j to PMS must succeed). If desired,
an MPLS trace route may be used to exactly detect the data plane an MPLS trace route may be used to exactly detect the data plane
path taken for this MPLS Segment. It is usually sufficient to path taken for this MPLS Segment. It is usually sufficient to
skipping to change at page 9, line 44 skipping to change at page 9, line 40
Determining a path to be executed prior to a measurement may also be Determining a path to be executed prior to a measurement may also be
done by setting up a label stack including all Node-SIDs along that done by setting up a label stack including all Node-SIDs along that
path (if LSR1 has Node SID 40 in the example and it should be passed path (if LSR1 has Node SID 40 in the example and it should be passed
between LER i and LER j, the label stack is 20 - 40 - 30 - 10). The between LER i and LER j, the label stack is 20 - 40 - 30 - 10). The
advantage of this method is, that it does not involve RFC 4379 advantage of this method is, that it does not involve RFC 4379
connectivity verification and, if there's only one physical 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, either additional connections exist between any two nodes, all Adj-SIDs along that path
information based on an MPLS trace route or additional Adj-SIDs are should be part of the label stack.
required to deal with ECMP.
In theory at least, a single PMS is able to monitor data plane In theory at least, a single PMS is able to monitor data plane
availability of all LSPs in the domain. The PMS may be a router, but availability of all LSPs in the domain. The PMS may be a router, but
could also be dedicated monitoring system. If measurement system could also be dedicated monitoring system. If measurement system
reliability is an issue, more than a single PMS may be connected to reliability is an issue, more than a single PMS may be connected to
the MPLS domain. 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
skipping to change at page 10, line 38 skipping to change at page 10, line 32
+---+ _ +--+ +-------+ +---+ _ +--+ +-------+
| | { } | |---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 addresses Lx by the Adjacency SID 99x, while R2 addresses Lx by In the figure, R1 addresses Link "x" Lx by the Adjacency SID 99x,
the Adjacency SID 66(x+1). while R2 addresses Link Lx by 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).
PMS sends the probe to its connected router. If the connected router PMS sends the probe to its connected router. The MPLS/SR domain then
is not SR compliant, a tunneling technique can be used to tunnel the forwards the probe to R2 (72 is the Node SID of R2). R2 forwards the
probe and its MPLS stack to the first SR router. The MPLS/SR domain probe to R1 over link L1 (Adjacency SID 662). R1 forwards the probe
then forwards the probe to R2 (72 is the Node SID of R2). R2 to R2 over link L2 (Adjacency SID 992). R2 forwards the probe to R1
forwards the probe to R1 over link L1 (Adjacency SID 662). R1 over link L3 (Adjacency SID 664). R1 then forwards the IP probe to
forwards the probe to R2 over link L2 (Adjacency SID 992). R2 PMS as per classic IP forwarding.
forwards the probe to R1 over link L3 (Adjacency SID 664). R1 then
forwards the IP probe to PMS as per classic IP forwarding.
As has been mentioned in section 5.1, the PMS must be able monitor As has been mentioned in section 5.1, the PMS must be able monitor
continuity of the path PMS to R2 (Node-SID 72) as well as continuity continuity of the path PMS to R2 (Node-SID 72) as well as continuity
from R1 to the PMS. If both are given and packets are lost, from R1 to the PMS. If both are given and packets are lost,
forwarding on one of the three interfaces connecting R1 to R2 must be forwarding on one of the three interfaces connecting R1 to R2 must be
disturbed. disturbed.
5.3. Use Case 3 - Fault Localization 5.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
skipping to change at page 12, line 44 skipping to change at page 12, line 34
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.
An implementation report on a PMS operating in an LDP domain is given An implementation report on a PMS operating in an LDP domain is given
in [I-D.leipnitz-spring-pms-implementation-report]. In addition, in [I-D.leipnitz-spring-pms-implementation-report]. In addition,
this report compares delays measured with a single PMS to the results this report compares delays measured with a single PMS to the results
measured by three IP Performance Measurement Work Group (IPPM WG) measured by three IP Performance Measurement Work Group (IPPM WG)
standard conformant Measurement Agents (connected to an MPLS domain standard conformant Measurement Agents (connected to an MPLS domain
at three different sites). The delay measurements of PMS and where at three different sites). The delay measurements of the PMS and the
compared based on a statistical test published by the IPPM WG IPPM Measurement Agents were compared based on a statistical test
[RFC6576]. The Anderson Darling k-sample test showed that the PMS published by the IPPM WG[RFC6576]. The Anderson Darling k-sample
round-trip delay measurements are equal to those captured by an IPPM test showed that the PMS round-trip delay measurements are equal to
conformant IP measurement system for 64 Byte measurement packets with those captured by an IPPM conformant IP measurement system for 64
95% confidence. Byte measurement packets with 95% confidence.
The authors are not aware of similar deployment for RSVP-TE. The authors are not aware of similar deployment for RSVP-TE.
Identification of tunnel entry- and transit-nodes may add complexity. Identification of tunnel entry- and transit-nodes may add complexity.
They are not within scope of this document. They are not within scope of this document.
8. PMS Monitoring of Different Segment ID Types 8. 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 PMS to monitor liveliness
of SIDs related to interfaces within the SR and IGP domain, of SIDs related to interfaces within the SR and IGP domain,
respectively. Tracing a path where an SR capable node assigns an respectively. Tracing a path where an SR capable node assigns an
Adj-SID for a non-SR-capable node may fail. This and other backward Adj-SID for a non-SR-capable node may fail. This and other backward
compatibility with non Segment Routing devices are discussed by compatibility with non Segment Routing devices are discussed by
[I-D.draft-ietf-mpls-spring-lsp-ping]. [I-D.draft-ietf-mpls-spring-lsp-ping].
To match control plane information with data plane information, MPLS To match control plane information with data plane information for
OAM functions as defined for example by RFC4379 [RFC4379] are all relevant types of Segment IDs,
enhanced to allow collection of data relevant to check all relevant [I-D.draft-ietf-mpls-spring-lsp-ping]enhances MPLS OAM functions
types of Segment IDs by [I-D.draft-ietf-mpls-spring-lsp-ping]. defined by RFC 4379 [RFC4379].
9. Connectivity Verification Using PMS 9. Connectivity Verification Using PMS
While the PMS based use cases explained in Section 5 are sufficient While the PMS based use cases explained in Section 5 are sufficient
to provide continuity check between LER i and LER j, it may not help to provide continuity 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.
skipping to change at page 14, line 27 skipping to change at page 14, line 16
picked up, some fundamental MPLS security properties need to be picked up, some fundamental MPLS security properties need to be
discussed. MPLS domains so far allow to separate the MPLS network discussed. MPLS domains so far allow to separate the MPLS network
from an IP network by allowing no tunneled MPLS access to an MPLS from an IP network by allowing no tunneled MPLS access to an MPLS
domain. domain.
13. Acknowledgements 13. 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. set of comments and suggestions. Finally, Bruno Decraene's shepherd
review led to a clarified document.
14. References 14. References
14.1. Normative References 14.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>.
 End of changes. 26 change blocks. 
91 lines changed or deleted 83 lines changed or added

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