draft-ietf-spring-oam-usecase-03.txt   draft-ietf-spring-oam-usecase-04.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 24, 2016 C. Pignataro, Ed. Expires: April 23, 2017 C. Pignataro, Ed.
N. Kumar N. Kumar
Cisco Cisco
April 22, 2016 October 20, 2016
A Scalable and Topology-Aware MPLS Dataplane Monitoring System A Scalable and Topology-Aware MPLS Dataplane Monitoring System
draft-ietf-spring-oam-usecase-03 draft-ietf-spring-oam-usecase-04
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 trace, in a very features to the traditional MPLS ping and LSP trace, in a very
complementary way. MPLS topology awareness reduces management and complementary way. MPLS topology awareness reduces management and
control plane involvement of OAM measurements while enabling new OAM control plane involvement of OAM measurements while enabling new OAM
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 October 24, 2016. This Internet-Draft will expire on April 23, 2017.
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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. An MPLS Topology-Aware Path Monitoring System . . . . . . . . 4 3. An MPLS Topology-Aware Path Monitoring System . . . . . . . . 4
4. SR-based Path Monitoring Use Case Illustration . . . . . . . 5 4. SR-based Path Monitoring Use Case Illustration . . . . . . . 6
4.1. Use Case 1 - LSP Dataplane Monitoring . . . . . . . . . . 6 4.1. Use Case 1 - LSP Dataplane Monitoring . . . . . . . . . . 6
4.2. Use Case 2 - Monitoring a Remote Bundle . . . . . . . . . 8 4.2. Use Case 2 - Monitoring a Remote Bundle . . . . . . . . . 8
4.3. Use Case 3 - Fault Localization . . . . . . . . . . . . . 8 4.3. Use Case 3 - Fault Localization . . . . . . . . . . . . . 9
5. Failure Notification from PMS to LERi . . . . . . . . . . . . 9 5. Failure Notification from PMS to LERi . . . . . . . . . . . . 9
6. Applying SR to Monitoring LDP Paths . . . . . . . . . . . . . 9 6. Applying SR to Monitoring non-SR based LSPs (LDP and possibly
7. PMS Monitoring of Different Segment ID Types . . . . . . . . 9 RSVP-TE) . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. PMS Monitoring of Different Segment ID Types . . . . . . . . 10
8. Connectivity Verification Using PMS . . . . . . . . . . . . . 10 8. Connectivity Verification Using PMS . . . . . . . . . . . . . 10
9. Extensions of Specifications Relevant to this Use Case . . . 10 9. Extensions of Specifications Relevant to this Use Case . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
13.1. Normative References . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . 11 13.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Acronyms 1. Acronyms
ECMP Equal-Cost Multi-Path ECMP Equal-Cost Multi-Path
IGP Interionr Gateway Protocol IGP Interionr Gateway Protocol
LER Label Edge Router LER Label Edge Router
LSP Label Switched Path LSP Label Switched Path
LSR Label Switching Router LSR Label Switching Router
OAM Operations, Administration, and Maintenance OAM Operations, Administration, and Maintenance
PMS Path Monitoring System PMS Path Monitoring System
SID Segment Identifier SID Segment Identifier
SR Segment Routing SR Segment Routing
SRGB Segment Routing Global Block SRGB Segment Routing Global Block
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. The monitoring flow paths observed by the transported user packets. The monitoring
is expected to be forwarded in dataplane in a similar way as user packet is expected to be forwarded in dataplane in a similar way as
packets. Segment Routing enables forwarding of packets along pre- user packets. Segment Routing enables forwarding of packets along
defined paths and segments and thus a Segment Routed monitoring pre-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 case introduced here is monitoring capabilities. The use cases introduced here is limited to
limited to a single IGP MPLS domain. 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 at detection based on IGP signaled segments as specified at
[I-D.ietf-isis-segment-routing-extensions] and [I-D.ietf-isis-segment-routing-extensions] and
[I-D.ietf-ospf-segment-routing-extensions]. Thus a centralised and [I-D.ietf-ospf-segment-routing-extensions]. 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 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 Routing (SR) based technology. Making such
a pre-SR MPLS monitoring system aware of a domains complete MPLS a pre-SR MPLS monitoring system aware of a domain's 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
[I-D.ietf-spring-segment-routing]. [I-D.ietf-spring-segment-routing].
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 domain's 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.
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:
skipping to change at page 4, line 12 skipping to change at page 4, line 12
o correlation between different SR based monitoring probes. o correlation between different SR based monitoring probes.
o by any MPLS traceroute method (possibly in combination with SR o by any MPLS traceroute method (possibly in combination with SR
based path stacks). based path stacks).
Topology awareness is an essential part of link state IGPs. Adding Topology awareness is an essential part of link state IGPs. Adding
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 features to recognise an execute data paths MPLS OAM offers flexible features to recognise and execute data paths
of an MPLS domain. By utilising the ECMP related tool set offered of an MPLS domain. By utilising the ECMP related tool set offered
e.g. by RFC 4379 [RFC4379], a segment based routing LSP monitoring e.g. by RFC 4379 [RFC4379], a segment based routing LSP monitoring
system may: 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.
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 any server residing at a The MPLS Path Monitoring System (PMS) may be any server residing at a
single interface of the domain to be monitored. It doesn't have to single interface of the domain to be monitored. It doesn't have to
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 monitoring probe packet
right segment stack. As long as measurement packets return to this with the right segment stack. The monitoring probe packet could be
or another interface connecting such a server, the MPLS monitoring BFD or LSP Ping packet or any other OAM format that PMS supports. As
servers are the single entities pushing monitoring packet label long as the monitoring packet returns back to the server, the path
stacks. If the depth of label stacks to be pushed by a path can be considered as validated. The MPLS monitoring servers are the
monitoring system (PMS) are of concern for a domain, a dedicated single entities pushing monitoring packet label stacks. If the depth
server based path monitoring architecture allows limiting monitoring of label stacks to be pushed by a path monitoring system (PMS) are of
related label stack pushes to these servers. concern for a domain, a dedicated server based path monitoring
architecture allows limiting monitoring related label stack pushes to
these servers.
Documents 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 [I-D.ietf-spring-sr-oam-requirement] and already, see [I-D.ietf-spring-sr-oam-requirement] and
[I-D.kumarkini-mpls-spring-lsp-ping]. [I-D.ietf-mpls-spring-lsp-ping].
3. 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
labels). Thus a PMS connected to an MPLS SR domain just needs to set labels). Thus a PMS connected to an MPLS SR domain just needs to set
up a topology data base for monitoring purposes. up a topology data base for monitoring purposes.
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 the path of it 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 infomation: label stack infomation:
o Top Label: a path from PMS to LER i, which is expressed as Node o Top Label: a path from PMS to LER i, which is expressed as Node
SID of LER i. SID of LER i.
o Next Label: the path that needs to be monitored from LER i to LER o Next Label: the path that needs to be monitored from LER i to LER
j. If this path is a single physical interface (or a bundle of j. If this path is a single physical interface (or a bundle of
skipping to change at page 5, line 42 skipping to change at page 5, line 44
o Next Label or address: the path back to the PMS. Likely, no o Next Label or address: the path back to the PMS. Likely, no
further segment/label is required here. Indeed, once the packet further segment/label is required here. Indeed, once the packet
reaches LER j, the 'steering' part of the solution is done and the reaches LER j, the 'steering' part of the solution is done and 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: a deployment might prefer not to connect the PMS to the MPLS
PMS can send its probe with the list of SIDs/Labels onto a suitable domain. if the PMS is an IP host not connected to the MPLS domain,
tunnel providing an MPLS access to a router which is part of the the PMS can send its probe with the list of SIDs/Labels onto a
monitored MPLS domain. suitable tunnel providing an MPLS access to a router which is part of
the monitored MPLS domain.
4. SR-based Path Monitoring Use Case Illustration 4. SR-based Path Monitoring Use Case Illustration
4.1. Use Case 1 - LSP Dataplane Monitoring 4.1. Use Case 1 - LSP Dataplane Monitoring
+---+ +----+ +-----+ +---+ +----+ +-----+
|PMS| |LSR1|-----|LER i| |PMS| |LSR1|-----|LER i|
+---+ +----+ +-----+ +---+ +----+ +-----+
| / \ / | / \ /
| / \__/ | / \__/
+-----+/ /| +-----+/ /|
|LER m| / | |LER m| / |
+-----+\ / \ +-----+\ / \
skipping to change at page 7, line 17 skipping to change at page 7, line 17
First algorithm based path. First algorithm based 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 which a packet may use between LER i and LER j. To possible paths which a packet may use between LER i and LER j. To
do so, the MPLS OAM mechanism chosen to detect ECMP must reveal do so, the MPLS OAM mechanism chosen to detect ECMP must reveal
the required information (an example is a so called tree trace) the required information (an example is a so called tree trace)
between LER i and LER j. This method of dealing with ECMP based between LER i and LER j. This method of dealing with ECMP based
load balancing paths requires the smallest SR label stacks if load balancing paths requires the smallest SR label stacks if
monitoring of paths is applied after the tree trace completion. monitoring of paths is applied after the tree trace completion.
o The path LER j to PMS to must be available. This path must be o The path LER j to PMS 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 information to deal Once the MPLS paths (Node SIDs) and the required information to deal
with ECMP has been detected, the paths of LER i to LER j can be with ECMP has been detected, the paths of LER i to LER j can be
monitored by the PMS. Monitoring itself does not require MPLS OAM monitored by the PMS. Monitoring itself does not require MPLS OAM
functionality. All monitoring packets stay on dataplane, hence path functionality. All monitoring packets stay on dataplane, hence path
monitoring does no longer require control plane interaction in any monitoring does no longer require control plane interaction in any
LER or LSR of the domain. To ensure reliable results, the PMS should LER or LSR of the domain. To ensure reliable results, the PMS should
be aware of any changes in IGP or MPLS topology. Further changes in be aware of any changes in IGP or MPLS topology. Further changes in
skipping to change at page 8, line 7 skipping to change at page 8, line 7
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 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. Prior to monitoring a path, MPLS OAM
management interfaces or their control plane to do so. may be used to detect ECMP dependant forwarding of a packet. A PMS
may be designed to learn the IP address information required to
execute a particular ECMP routed path and interfaces along that path.
This allows to monitor these paths with label stacks reduced to a
limited number of Node-SIDs resulting from SPF routing. The PMS does
not require access to LSR/LER management interfaces or their control
plane to do so.
4.2. Use Case 2 - Monitoring a Remote Bundle 4.2. Use Case 2 - Monitoring a Remote Bundle
+---+ _ +--+ +-------+ +---+ _ +--+ +-------+
| | { } | |---991---L1---662---| | | | { } | |---991---L1---662---| |
|PMS|--{ }-|R1|---992---L2---663---|R2 (72)| |PMS|--{ }-|R1|---992---L2---663---|R2 (72)|
| | {_} | |---993---L3---664---| | | | {_} | |---993---L3---664---| |
+---+ +--+ +-------+ +---+ +--+ +-------+
SR based probing of all the links of a remote bundle SR based probing of all the links of a remote bundle
skipping to change at page 9, line 24 skipping to change at page 9, line 33
5. 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.
6. Applying SR to Monitoring LDP Paths 6. Applying SR to Monitoring non-SR based LSPs (LDP and possibly RSVP-
TE)
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 or RSVP-TE in parallel in all nodes may use SR
transmit packets to and from start and end points of LDP paths to be paths to transmit packets to and from start and end points of non-SR
monitored. In the above example, the label stack top to bottom may based LSP paths to be monitored. In the above example, the label
be as follows, when sent by the PMS: stack top to bottom may 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 or RSVP-TE 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 or RSVP-TE topology, the PMS may learn the
topology by IGP and use this information. SR MPLS topology by IGP and use this information.
An implementation report on a PMS operating in an LDP domain is given
in [I-D.leipnitz-spring-pms-implementation-report].
7. 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 for example by RFC 4379 [RFC4379] should be OAM functions as defined for example by RFC 4379 [RFC4379] should be
enhanced to allow collection of data relevant to check all relevant enhanced to allow collection of data relevant to check all relevant
skipping to change at page 10, line 47 skipping to change at page 11, line 12
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.
12. Acknowledgements 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. The authors would
also like to thank Faisal Iqbal for an insightful review and a useful
set of comments and suggestions.
13. References 13. References
13.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>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-isis-segment-routing-extensions] [I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Litkowski, S., Decraene, B., and j. jefftant@gmail.com,
Extensions for Segment Routing", draft-ietf-isis-segment- "IS-IS Extensions for Segment Routing", draft-ietf-isis-
routing-extensions-06 (work in progress), December 2015. segment-routing-extensions-08 (work in progress), October
2016.
[I-D.ietf-mpls-spring-lsp-ping]
Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini,
S., Gredler, H., and M. Chen, "Label Switched Path (LSP)
Ping/Trace for Segment Routing Networks Using MPLS
Dataplane", draft-ietf-mpls-spring-lsp-ping-00 (work in
progress), May 2016.
[I-D.ietf-ospf-segment-routing-extensions] [I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-07 (work in progress), March 2016. routing-extensions-09 (work in progress), July 2016.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and R. Shakir, "Segment Routing Architecture", draft-ietf- and R. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-07 (work in progress), December spring-segment-routing-09 (work in progress), July 2016.
2015.
[I-D.ietf-spring-sr-oam-requirement] [I-D.ietf-spring-sr-oam-requirement]
Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G., Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
and S. Litkowski, "OAM Requirements for Segment Routing and S. Litkowski, "OAM Requirements for Segment Routing
Network", draft-ietf-spring-sr-oam-requirement-01 (work in Network", draft-ietf-spring-sr-oam-requirement-02 (work in
progress), December 2015. progress), July 2016.
[I-D.kumarkini-mpls-spring-lsp-ping] [I-D.leipnitz-spring-pms-implementation-report]
Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini, Leipnitz, R. and R. Geib, "A scalable and topology aware
S., Gredler, H., and M. Chen, "Label Switched Path (LSP) MPLS data plane monitoring system", draft-leipnitz-spring-
Ping/Trace for Segment Routing Networks Using MPLS pms-implementation-report-00 (work in progress), June
Dataplane", draft-kumarkini-mpls-spring-lsp-ping-06 (work 2016.
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
 End of changes. 33 change blocks. 
62 lines changed or deleted 86 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/