< draft-geib-ippm-connectivity-monitoring-00.txt   draft-geib-ippm-connectivity-monitoring-01.txt >
ippm R. Geib, Ed. ippm R. Geib, Ed.
Internet-Draft Deutsche Telekom Internet-Draft Deutsche Telekom
Intended status: Standards Track March 11, 2019 Intended status: Standards Track July 4, 2019
Expires: September 12, 2019 Expires: January 5, 2020
A Connectivity Monitoring Metric for IPPM A Connectivity Monitoring Metric for IPPM
draft-geib-ippm-connectivity-monitoring-00 draft-geib-ippm-connectivity-monitoring-01
Abstract Abstract
Segment Routed measurement packets can be sent along pre-determined Segment Routed measurement packets can be sent along pre-determined
paths. This allows new kinds of measurements. Connectivity paths. This allows new kinds of measurements. Connectivity
monitoring allows to supervise the state of a connection or a monitoring allows to supervise the state of a connection or a
(sub)path from one or a few central monitoring systems. This (sub)path from one or a few central monitoring systems. This
document specifies a suitable type-P connectivity monitoring metric. document specifies a suitable type-P connectivity monitoring metric.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. A brief segment routing connectivity monitoring framework . . 3 2. A brief segment routing connectivity monitoring framework . . 4
3. Singleton Definition for Type-P-Path-Connectivity-and- 3. Singleton Definition for Type-P-SR-Path-Connectivity-and-
Congestion . . . . . . . . . . . . . . . . . . . . . . . . . 6 Congestion . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 6 3.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 7
3.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Defintion . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Definition . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 7 3.6. Methodologies . . . . . . . . . . . . . . . . . . . . . . 8
3.7. Errors and Uncertainties . . . . . . . . . . . . . . . . 9 3.7. Errors and Uncertainties . . . . . . . . . . . . . . . . 10
3.8. Reporting the Metric . . . . . . . . . . . . . . . . . . 9 3.8. Reporting the Metric . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. Singleton Definition for Type-P-SR-Path-Round-Trip-Delay-
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 Estimate . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Segment Routing enables sending measurement packets along pre- Segment Routing enables sending measurement packets along pre-
determined segment routed paths [RFC8402]. A segment routed path may determined segment routed paths [RFC8402]. A segment routed path may
consist of pre-determined sub paths down to specific router- consist of pre-determined sub paths down to specific router-
interfaces. It may also consist of sub paths spanning multiple interfaces. It may also consist of sub paths spanning multiple
routers, given that all segments to address a desired path are routers, given that all segments to address a desired path are
available and known at the SR domain edge interface. available and known at the SR domain edge interface.
skipping to change at page 3, line 8 skipping to change at page 3, line 10
the CPU load caused by monitoring. the CPU load caused by monitoring.
The IPPM architecture was a first step to that direction [RFC2330]. The IPPM architecture was a first step to that direction [RFC2330].
Commodity IPPM solutions require dedicated measurement systems, a Commodity IPPM solutions require dedicated measurement systems, a
large number of measurement agents and synchronised clocks. large number of measurement agents and synchronised clocks.
Monitoring a domain from edge to edge by commodity IPPM solutions Monitoring a domain from edge to edge by commodity IPPM solutions
helps to increase scalability of the monitoring system, but helps to increase scalability of the monitoring system, but
localising a source cause of a detected change in network behaviour localising a source cause of a detected change in network behaviour
then may require network tomography methods. then may require network tomography methods.
The IPPM Metrics for Measuring Connectivity offer generic
connectivity metrics [RFC2678]. These metrics allow to measure
connectivity between end nodes without making any assumption on the
paths between them. The metric and the type-p packet specified by
this document follow a different approach: they are designed to
monitor connectivity of a specific single link or a path segment.
The underlying definition of connectivity is partially the same, a
packet not reaching a destination indicates a loss of connectivity.
An IGP re-route may indicate a loss of a link, while it might not
cause loss of connectivity beween end systems. The metric specified
here is able to detect the loss of a link, if the change in end-to-
end delay along a new route are differing from that of the original
path.
A Segment Routing PMS which is part of an SR domain is IGP topology A Segment Routing PMS which is part of an SR domain is IGP topology
aware, covering the IP and (if present) the MPLS layer topology aware, covering the IP and (if present) the MPLS layer topology
[RFC8402]. This enables to design a PMS which can steer packets [RFC8402]. This allows to design a PMS which can steer packets along
along arbitrary pre-determined concatenated sub-paths, identified by arbitrary pre-determined concatenated sub-paths, identified by
suitable segments. Combining the SR measurement path configuration suitable segments. Combining the SR measurement path configuration
with a priori network tomography assumptions and methods allows for with a priori network tomography assumptions and methods allows for
localisation of detected changes. The latter requires setting up localisation of detected changes. The latter requires setting up
multiple measurement paths which share sub-paths following the multiple measurement paths which share sub-paths following the
constraints derived from network tomography, and a suitable constraints derived from network tomography, and a suitable
evaluation. evaluation of measurement results.
This document specifies a type-p metric determining properties of an This document specifies a type-p metric determining properties of an
SR path which allows to monitor connectivity and congestion of SR path which allows to monitor connectivity and congestion of
interfaces and further allows to locate the connection or interface interfaces and further allows to locate the path or interface which
which caused a change in the reported type-p metric. This document caused a change in the reported type-p metric. This document is
is focussed on the MPLS layer, but the methodolgy may be applied focussed on the MPLS layer, but the methodolgy may be applied within
within SR doamins or MPLS domains in general. SR domains or MPLS domains in general.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. A brief segment routing connectivity monitoring framework 2. A brief segment routing connectivity monitoring framework
The Segment Routing IGP topology information consists of the IP and The Segment Routing IGP topology information consists of the IP and
(if present) the MPLS layer topology. The minimum SR topology (if present) the MPLS layer topology. The minimum SR topology
information are Node-Segment-Identifiers (Node-SID), identifying an information consists of Node-Segment-Identifiers (Node-SID),
SR router. The IGP exchange of Adjacency-SIDs [I-D.draft-ietf-isis- identifying an SR router. The IGP exchange of Adjacency-SIDs [I-
segment-routing-extensions], which identify local interfaces to D.draft-ietf-isis-segment-routing-extensions], which identify local
adjacent nodes, is optional. It is RECOMMENDED to distribute Adj- interfaces to adjacent nodes, is optional. It is RECOMMENDED to
SIDs in a domain operating a PMS to monitor connectivity as specified distribute Adj-SIDs in a domain operating a PMS to monitor
below. If Adj-SIDs aren't availbale, [RFC8029] provides methods how connectivity as specified below. If Adj-SIDs aren't availbale,
to steer packets along desired paths by the proper choice of an MPLS [RFC8029] provides methods how to steer packets along desired paths
Echo-request IP-destination address. A detailed description of by the proper choice of an MPLS Echo-request IP-destination address.
[RFC8029] methods as a replacement of Adj-SIDs is out of scope of A detailed description of [RFC8029] methods as a replacement of Adj-
this document. SIDs is out of scope of this document.
A round trip measurement between two adjacent nodes is a simple A round trip measurement between two adjacent nodes is a simple
method to monitor connectivity of a connecting link. If multiple method to monitor connectivity of a connecting link. If multiple
links are operational between two adjacent nodes and only a single links are operational between two adjacent nodes and only a single
one fails, a single plain round trip measurement may fail to identify one fails, a single plain round trip measurement may fail to identify
which link has failed. A round trip measurement also fails to which link has failed. A round trip measurement also fails to
identify which inteface is congested, even if only a single link identify which inteface is congested, even if only a single link
connects two adjacent nodes. connects two adjacent nodes.
Segment Routing enables the set-up of extended measurement loops. Segment Routing enables the set-up of extended measurement loops.
Several different measurement loops can be set up. If these form a Several different measurement loops can be set up. If these form a
partial overlay, any change in the network properties impacts more partial overlay, any change in the network properties impacts more
than a single loops round trip time (or drops packets of more than than a single loops round trip time (or causes drops of packets of
one loop). An randomly chosen paths may fail to produce unique more than one loop). Randomly chosen loop paths including the
result patterns. A centralised monitoring approach further benefits interfaces or paths to be monitored may fail to produce unique result
from keeping the number of measurement loops low, as this improves patterns. The approach picked here uses specified measurement loop
scalability one hand and keeps the number of results to be evaluated and path overlay design. A centralised monitoring approach benefits
and correlated low. from keeping the number of required measurement loops low. This
improves scalability by minimising the number of measurement loops.
This also keeps the number of required packets and results to be
evaluated and correlated low.
Segment Routing enables the set-up of extended measurement loops. An additional property of the measurement path set-up specified below
Several different measurement loops can be set up. If these form a is that it allows to estimate the packet round trip and the one way
partial overlay, any change in the network properties impacts more delay of a monitored link (or path). The delay along a single link
than a single loops round trip time (or drops packets of more than is not perfectly symmetric. Packet processing causes small delay
one loop). An randomly chosen paths may fail to produce unique differences per interface and direction. These cause an error, which
result patterns. A centralised monitoring approach further benefits can't be quantified or removed by the specified method. Quantifying
from keeping the number of measurement loops low, as this improves this error requires a different measurement set-up. As this will
scalability one hand and keeps the number of results to be evaluated introduce additional measurements loops, packets and evaluations, the
and correlated low. cost in terms of reduced scalability is not felt to be worth the
benefit in measurement accuracy. IPPM however honors precision more
than accuracy and the mentioned processing differences are relatively
stable, resulting in relatively precise delay estimates.
An example SR domain is shown below. The PMS shown should monitor An example SR domain is shown below. The PMS shown should monitor
the connectivity of all 6 links between nodes L100 and L200 one one the connectivity of all 6 links between nodes L100 and L200 one one
side and the connected nodes L050, L060 and L070 on the other side. side and the connected nodes L050, L060 and L070 on the other side.
The round trip times per measurement loop are assumed to exhibit The round trip times per measurement loop are assumed to exhibit
unique delays. unique delays.
+---+ +----+ +----+ +---+ +----+ +----+
|PMS| |L100|-----|L050| |PMS| |L100|-----|L050|
+---+ +----+\ /+----+ +---+ +----+\ /+----+
skipping to change at page 5, line 10 skipping to change at page 5, line 33
Connectivity verification with a PMS Connectivity verification with a PMS
Figure 1 Figure 1
The SID values are picked for convenient reading only. Node-SID: 100 The SID values are picked for convenient reading only. Node-SID: 100
identifies L100, Node-SID: 300 identifies L300 and so on. Adj-SID identifies L100, Node-SID: 300 identifies L300 and so on. Adj-SID
10050: Adjacency L100 to L050, Adj-SID 10060: Adjacency L100 to L060, 10050: Adjacency L100 to L050, Adj-SID 10060: Adjacency L100 to L060,
Adj-SID 60200: Adjacency L60 to L200 Adj-SID 60200: Adjacency L60 to L200
This requires 6 measurement paths, each of which has the following Monitoring the 6 links between Ln00 and L0m0 nodes requires 6
properties: measurement loops, each of which has the following properties:
o It follows a single round trip from one Ln00 to one L0m0 (e.g., o Each loop follows a single round trip from one Ln00 to one L0m0
between L100 and L050). (e.g., between L100 and L050).
o It passes two more links between that Ln00 one more L0m0 and the o Each loop passes two more links: one between that Ln00 and another
other Ln00 (e.g., between L100 and L060 and then L060 to L200) L0m0 and from there to the other Ln00 (e.g., between L100 and L060
and then L060 to L200)
o Every link is passed by a single round trip per measurement loop o Every link is passed by a single round trip per measurement loop
only once and only once unidirectional by two other loops, and the only once and only once unidirectional by two other loops, and the
latter two pass along opposing directions (that's three loops latter two pass along opposing directions (that's three loops
passing each single link, e.g., one having a round trip L100 to passing each single link, e.g., one having a round trip L100 to
L050 and back, a second passing L100 to L050 only and a third loop L050 and back, a second passing L100 to L050 only and a third loop
passing L050 to L100 only). passing L050 to L100 only).
Note that any 6 links between two to six nodes can be monitored that
way too (if multiple parallel links between two nodes are monitored,
the differences in delay may require a sufficiently high clock
resulotion, if applicable).
This results in 6 measurement loops for the given example (the start This results in 6 measurement loops for the given example (the start
and end of each measurement loop is PMS to L300 to L100 or L200 and a and end of each measurement loop is PMS to L300 to L100 or L200 and a
similar sub-path on the return leg. It is ommitted here for similar sub-path on the return leg. It is ommitted here for
brevity): brevity):
1. L100 -> L050 -> L100 -> L060 -> L200 1. M1 is the delay along L100 -> L050 -> L100 -> L060 -> L200
2. L100 -> L060 -> L100 -> L070 -> L200 2. M2 is the delay along L100 -> L060 -> L100 -> L070 -> L200
3. L100 -> L070 -> L100 -> L050 -> L200 3. M3 is the delay along L100 -> L070 -> L100 -> L050 -> L200
4. L200 -> L050 -> L200 -> L060 -> L100 4. M4 is the delay along L200 -> L050 -> L200 -> L060 -> L100
5. L200 -> L060 -> L200 -> L070 -> L100 5. M5 is the delay along L200 -> L060 -> L200 -> L070 -> L100
6. L200 -> L070 -> L200 -> L050 -> L100 6. M6 is the delay along L200 -> L070 -> L200 -> L050 -> L100
An example for a stack of a loop consisting of Node-SID segments
allowing to caprture M1 is (top to bottom): 100 | 050 | 100 | 060 |
200 | PMS.
An example for a stack of Adj-SID segments the loop resulting in M1
is (top to bottom): 100 | 10050 | 50100 | 10060 | 60200 | PMS. As
can be seen, the Node-SIDs 100 and PMS are present at top and bottom
of the segment stack. Their purpose is to transport the packet from
the PMS to the start of the measurement loop at L100 and return it to
the PMS from its end.
The measurement loops set up as shown have the following properties: The measurement loops set up as shown have the following properties:
o Any single complete loss of connectivity caused by a failing o If the loops are set up using Node-SIDs only, any single complete
single link briefly between any Ln00 and any L0m0 node disturbs loss of connectivity caused by a failing single link between any
(and changes the measured delay) of three loops. Ln00 and any L0m0 node briefly disturbs (and changes the measured
delay) of three loops. Traffic to Node-SIDs is rerouted.
o Whereas any congested single interface between any Ln00 and any o If the loops are set up using Adj-SIDs only (and Node-SIDs only to
L0m0 node only impacts the measured delay of two measurement send the packet from PMS to the loop starting point and from the
loops. loop end back to the PMS), any single complete loss of
connectivity caused by a failing single link between any Ln00 and
any L0m0 node terminates the traffic along three loops. The
packets of these loops will be dropped, until the link gets back
into service. Traffic to Adj-SIDs is not rerouted.
o Any congested single interface between any Ln00 and any L0m0 node
only impacts the measured delay of two measurement loops.
o As an example, the formula for a single Round Trip Delay (RTD) is
shown here 4 * RTD_L100-L050-L100 = 3 * M1 + M3 + M6 - M2 - M4 -
M5
A closer look reveals that each single event of interest for the A closer look reveals that each single event of interest for the
proposed metric, which are a loss of connectivity or a case of proposed metric, which are a loss of connectivity or a case of
congestion, uniquely only impacts a single a-priori determinable set congestion, uniquely only impacts a single a-priori determinable set
of measurement loops. If, e.g., connectivity is lost between L200 of measurement loops. If, e.g., connectivity is lost between L200
and L050, measurement loops (3), (4) and (6) indicate a change in the and L050, measurement loops (3), (4) and (6) indicate a change in the
measured delay. measured delay.
As a second example, if the interface L070 to L100 is congested, As a second example, if the interface L070 to L100 is congested,
measurement loops (3) and (5) indicate a change in the measured measurement loops (3) and (5) indicate a change in the measured
delay. Without listing all events, all cases of single losses of delay. Without listing all events, all cases of single losses of
connectivity or single events of congestion influence only delay connectivity or single events of congestion influence only delay
measurements of a unique set of measurement loops. measurements of a unique set of measurement loops.
3. Singleton Definition for Type-P-Path-Connectivity-and-Congestion A congestion event adding latency to two specific measurement loops
allows calculation of the delay added by the queue at the congested
interface. Thus, the resulting RTD increase can be assigned to a
single interface.
3. Singleton Definition for Type-P-SR-Path-Connectivity-and-Congestion
3.1. Metric Name 3.1. Metric Name
Type-P-Path-Connectivity-and-Congestion Type-P-SR-Path-Connectivity-and-Congestion
3.2. Metric Parameters 3.2. Metric Parameters
o Src, the IP address of a source host o Src, the IP address of a source host
o Dst, the IP address of a destination host if IP routing is o Dst, the IP address of a destination host if IP routing is
applicable; in the case of MPLS routing, a diagnostic address as applicable; in the case of MPLS routing, a diagnostic address as
specified by [RFC8029] specified by [RFC8029]
o T, a time o T, a time
skipping to change at page 7, line 9 skipping to change at page 8, line 16
o P, the specification of the packet type, over and above the source o P, the specification of the packet type, over and above the source
and destination addresses and destination addresses
o DS, a constant time interval between two type-P packets o DS, a constant time interval between two type-P packets
3.3. Metric Units 3.3. Metric Units
A sequence of consecutive time values. A sequence of consecutive time values.
3.4. Defintion 3.4. Definition
A moving average of AV time values per measurement path is compared A moving average of AV time values per measurement path is compared
by a change point detection algorithm. The temporal packet spacing by a change point detection algorithm. The temporal packet spacing
value DS represents the smallest period within which a change in value DS represents the smallest period within which a change in
connectivity or congestion may be detected. connectivity or congestion may be detected.
A single loss of connectivity of a sub-path between two nodes affects A single loss of connectivity of a sub-path between two nodes affects
three different measurement paths. Depending on the value chosen for three different measurement paths. Depending on the value chosen for
DS, packet loss might occur (note that the moving average evaluation DS, packet loss might occur (note that the moving average evaluation
needs to span a longer period than convergence time; alternatively, needs to span a longer period than convergence time; alternatively,
skipping to change at page 9, line 43 skipping to change at page 11, line 5
o Loss of connectivity and congestion along sub-paths connecting the o Loss of connectivity and congestion along sub-paths connecting the
measurement device(s) with the sub-paths to be monitored. measurement device(s) with the sub-paths to be monitored.
3.8. Reporting the Metric 3.8. Reporting the Metric
The metric reports loss of connectivity of monitored sub-path or The metric reports loss of connectivity of monitored sub-path or
congestion of an interface and identifies the sub-path and the congestion of an interface and identifies the sub-path and the
direction of traffic in the case of congestion. direction of traffic in the case of congestion.
4. IANA Considerations 4. Singleton Definition for Type-P-SR-Path-Round-Trip-Delay-Estimate
This section will be added in a later version, if there's interest in
picking up this work.
5. IANA Considerations
If standardised, the metric will require an entry in the IPPM metric If standardised, the metric will require an entry in the IPPM metric
registry. registry.
5. Security Considerations 6. Security Considerations
This draft specifies how to use methods specified or described within This draft specifies how to use methods specified or described within
[RFC8402] and [RFC8403]. It does not introduce new or additional SR [RFC8402] and [RFC8403]. It does not introduce new or additional SR
features. The security considerations of both references apply here features. The security considerations of both references apply here
too. too.
6. References 7. References
6.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, DOI 10.17487/RFC2678, September
1999, <https://www.rfc-editor.org/info/rfc2678>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <https://www.rfc-editor.org/info/rfc7679>. 2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/info/rfc7680>. 2016, <https://www.rfc-editor.org/info/rfc7680>.
skipping to change at page 10, line 37 skipping to change at page 12, line 10
Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
Switched (MPLS) Data-Plane Failures", RFC 8029, Switched (MPLS) Data-Plane Failures", RFC 8029,
DOI 10.17487/RFC8029, March 2017, DOI 10.17487/RFC8029, March 2017,
<https://www.rfc-editor.org/info/rfc8029>. <https://www.rfc-editor.org/info/rfc8029>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
6.2. Informative References 7.2. Informative References
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, "Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998, DOI 10.17487/RFC2330, May 1998,
<https://www.rfc-editor.org/info/rfc2330>. <https://www.rfc-editor.org/info/rfc2330>.
[RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. [RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N.
Kumar, "A Scalable and Topology-Aware MPLS Data-Plane Kumar, "A Scalable and Topology-Aware MPLS Data-Plane
Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July
2018, <https://www.rfc-editor.org/info/rfc8403>. 2018, <https://www.rfc-editor.org/info/rfc8403>.
 End of changes. 32 change blocks. 
79 lines changed or deleted 144 lines changed or added

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