draft-ietf-mpls-rfc6374-sfl-01.txt   draft-ietf-mpls-rfc6374-sfl-02.txt 
MPLS Working Group S. Bryant MPLS Working Group S. Bryant
Internet-Draft M. Chen Internet-Draft M. Chen
Intended status: Standards Track Z. Li Intended status: Standards Track Z. Li
Expires: June 8, 2018 Huawei Expires: December 22, 2018 Huawei
G. Swallow G. Swallow
Southend Technical Center
S. Sivabalan S. Sivabalan
Cisco Systems Cisco Systems
G. Mirsky G. Mirsky
ZTE Corp. ZTE Corp.
G. Fioccola G. Fioccola
Telecom Italia Telecom Italia
December 05, 2017 June 20, 2018
RFC6374 Synonymous Flow Labels RFC6374 Synonymous Flow Labels
draft-ietf-mpls-rfc6374-sfl-01 draft-ietf-mpls-rfc6374-sfl-02
Abstract Abstract
This document describes a method of making RFC6374 performance This document describes a method of making RFC6374 performance
measurements on flows carried over an MPLS Label Switched path. This measurements on flows carried over an MPLS Label Switched path. This
allows loss and delay measurements to be made on multi-point to point allows loss and delay measurements to be made on multi-point to point
LSPs and allows the measurement of flows within an MPLS construct LSPs and allows the measurement of flows within an MPLS construct
using RFC6374. using RFC6374.
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 43
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 June 8, 2018. This Internet-Draft will expire on December 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 39 skipping to change at page 2, line 39
8. Sampled Measurement . . . . . . . . . . . . . . . . . . . . . 13 8. Sampled Measurement . . . . . . . . . . . . . . . . . . . . . 13
9. Carrying RFC6374 Packets over an LSP using an SFL . . . . . . 13 9. Carrying RFC6374 Packets over an LSP using an SFL . . . . . . 13
9.1. RFC6374 SFL TLV . . . . . . . . . . . . . . . . . . . . . 15 9.1. RFC6374 SFL TLV . . . . . . . . . . . . . . . . . . . . . 15
10. Applicability to Pro-active and On-demand Measurement . . . . 16 10. Applicability to Pro-active and On-demand Measurement . . . . 16
11. RFC6374 Combined Loss-Delay Measurement . . . . . . . . . . . 16 11. RFC6374 Combined Loss-Delay Measurement . . . . . . . . . . . 16
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
14.1. Allocation of PW Associated Channel Type . . . . . . . . 17 14.1. Allocation of PW Associated Channel Type . . . . . . . . 17
14.2. MPLS Loss/Delay TLV Object . . . . . . . . . . . . . . . 17 14.2. MPLS Loss/Delay TLV Object . . . . . . . . . . . . . . . 17
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
15.1. Normative References . . . . . . . . . . . . . . . . . . 17 15.1. Normative References . . . . . . . . . . . . . . . . . . 18
15.2. Informative References . . . . . . . . . . . . . . . . . 18 15.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
[RFC6374] was originally designed for use as an OAM protocol for use [RFC6374] was originally designed for use as an OAM protocol for use
with MPLS Transport Profile (MPLS-TP) [RFC5921] LSPs. MPLS-TP only with MPLS Transport Profile (MPLS-TP) [RFC5921] LSPs. MPLS-TP only
supports point-to-point and point-to-multi-point LSPs. This document supports point-to-point and point-to-multi-point LSPs. This document
describes how to use RFC6374 in the general MPLS case, and also describes how to use RFC6374 in the general MPLS case, and also
introduces a number of more sophisticated measurements of introduces a number of more sophisticated measurements of
applicability to both cases. applicability to both cases.
[I-D.ietf-mpls-flow-ident] describes the requirement for introducing [RFC8372] describes the requirement for introducing flow identities
flow identities when using RFC6374 [RFC6374] packet Loss Measurements when using RFC6374 [RFC6374] packet Loss Measurements (LM). In
(LM). In summary RFC6374 uses the loss-measurement (LM) packet as summary RFC6374 uses the loss-measurement (LM) packet as the packet
the packet accounting demarcation point. Unfortunately this gives accounting demarcation point. Unfortunately this gives rise to a
rise to a number of problems that may lead to significant packet number of problems that may lead to significant packet accounting
accounting errors in certain situations. For example: errors in certain situations. For example:
1. Where a flow is subjected to Equal Cost Multi-Path (ECMP) 1. Where a flow is subjected to Equal Cost Multi-Path (ECMP)
treatment packets can arrive out of order with respect to the LM treatment packets can arrive out of order with respect to the LM
packet. packet.
2. Where a flow is subjected to ECMP treatment, packets can arrive 2. Where a flow is subjected to ECMP treatment, packets can arrive
at different hardware interfaces, thus requiring reception of an at different hardware interfaces, thus requiring reception of an
LM packet on one interface to trigger a packet accounting action LM packet on one interface to trigger a packet accounting action
on a different interface which may not be co-located with it. on a different interface which may not be co-located with it.
This is a difficult technical problem to address with the This is a difficult technical problem to address with the
skipping to change at page 3, line 35 skipping to change at page 3, line 35
processor cores, leading to synchronization problems. processor cores, leading to synchronization problems.
4. Link aggregation techniques may also lead to synchronization 4. Link aggregation techniques may also lead to synchronization
issues. issues.
5. Some forwarder implementations have a long pipeline between 5. Some forwarder implementations have a long pipeline between
processing a packet and incrementing the associated counter again processing a packet and incrementing the associated counter again
leading to synchronization difficulties. leading to synchronization difficulties.
An approach to mitigating these synchronization issue is described in An approach to mitigating these synchronization issue is described in
[I-D.tempia-ippm-p3m] and [RFC8321] in which packets are batched by the sender and each batch
[I-D.chen-ippm-coloring-based-ipfpm-framework] in which packets are is marked in some way such that adjacent batches can be easily
batched by the sender and each batch is marked in some way such that recognized by the receiver.
adjacent batches can be easily recognized by the receiver.
An additional problem arises where the LSP is a multi-point to point An additional problem arises where the LSP is a multi-point to point
LSP, since MPLS does not include a source address in the packet. LSP, since MPLS does not include a source address in the packet.
Network management operations require the measurement of packet loss Network management operations require the measurement of packet loss
between a source and destination. It is thus necessary to introduce between a source and destination. It is thus necessary to introduce
some source specific information into the packet to identify packet some source specific information into the packet to identify packet
batches from a specific source. batches from a specific source.
[I-D.bryant-mpls-sfl-framework] describes a method of encoding per [I-D.ietf-mpls-sfl-framework] describes a method of encoding per flow
flow instructions in an MPLS label stack using a technique called instructions in an MPLS label stack using a technique called
Synonymous Flow Labels (SFL) in which labels which mimic the Synonymous Flow Labels (SFL) in which labels which mimic the
behaviour of other labels provide the packet batch identifiers and behaviour of other labels provide the packet batch identifiers and
enable the per batch packet accounting. This memo specifies how SFLs enable the per batch packet accounting. This memo specifies how SFLs
are used to perform RFC6374 packet loss and RFC6374 delay are used to perform RFC6374 packet loss and RFC6374 delay
measurements. measurements.
2. Requirements Language 2. 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC2119]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. RFC6374 Packet Loss Measurement with SFL 3. RFC6374 Packet Loss Measurement with SFL
The data service packets of the flow being instrumented are grouped The data service packets of the flow being instrumented are grouped
into batches, and all the packets within a batch are marked with the into batches, and all the packets within a batch are marked with the
SFL [I-D.ietf-mpls-flow-ident] corresponding to that batch. The SFL [RFC8372] corresponding to that batch. The sender counts the
sender counts the number of packets in the batch. When the batch has number of packets in the batch. When the batch has completed and the
completed and the sender is confident that all of the packets in that sender is confident that all of the packets in that batch will have
batch will have been received, the sender issues an RFC6374 Query been received, the sender issues an RFC6374 Query message to
message to determine the number actually received and hence the determine the number actually received and hence the number of
number of packets lost. The RFC6374 Query message is sent using the packets lost. The RFC6374 Query message is sent using the same SFL
same SFL as the co-responding batch of data service packets. The as the co-responding batch of data service packets. The format of
format of the Query and Response packet is described in Section 9. the Query and Response packet is described in Section 9.
4. RFC6374 Single Packet Delay Measurement 4. RFC6374 Single Packet Delay Measurement
RFC6374 describes how to measure the packet delay by measuring the RFC6374 describes how to measure the packet delay by measuring the
transit time of an RFC6374 packet over an LSP. Such a packet may not transit time of an RFC6374 packet over an LSP. Such a packet may not
need to be carried over an SFL since the delay over a particular LSP need to be carried over an SFL since the delay over a particular LSP
should be a function of the TC bits. should be a function of the TC bits.
However where SFLs are being used to monitor packet loss or where However, where SFLs are being used to monitor packet loss or where
label inferred scheduling is used [RFC3270] then the SFL would be label inferred scheduling is used [RFC3270] then the SFL would be
REQUIRED to ensure that the RFC6374 packet which was being used as a REQUIRED to ensure that the RFC6374 packet which was being used as a
proxy for a data service packet experienced a representative delay. proxy for a data service packet experienced a representative delay.
The format of an RFC6374 packet carried over the LSP using an SFL is The format of an RFC6374 packet carried over the LSP using an SFL is
shown in Section 9. shown in Section 9.
5. Data Service Packet Delay Measurement 5. Data Service Packet Delay Measurement
Where it is desired to more thoroughly instrument a packet flow and Where it is desired to more thoroughly instrument a packet flow and
to determine the delay of a number of packets it is undesirable to to determine the delay of a number of packets it is undesirable to
skipping to change at page 5, line 42 skipping to change at page 5, line 40
In case 1 of Figure 1 we show the case were loss measurement alone is In case 1 of Figure 1 we show the case were loss measurement alone is
being carried out on the flow under analysis. For illustrative being carried out on the flow under analysis. For illustrative
purposes consider that in the time interval being analyzed, 10 purposes consider that in the time interval being analyzed, 10
packets always flow. packets always flow.
Now consider case 2 of Figure 1 where a small batch of packets need Now consider case 2 of Figure 1 where a small batch of packets need
to analyzed for delay. These are marked with a different SFL type to analyzed for delay. These are marked with a different SFL type
indicating that they are to be monitored for both loss and delay. indicating that they are to be monitored for both loss and delay.
The SFL=A indicates loss batch A, SFL=D indicates a batch of packets The SFL=A indicates loss batch A, SFL=D indicates a batch of packets
that are to be instrumented for delay, but SFL D is synonymous with that are to be instrumented for delay, but SFL D is synonymous with
SFL A, which in turn is synonymous with the underlying FEC. Thus a SFL A, which in turn is synonymous with the underlying FEC. Thus, a
packet marked D will be accumulated into the A loss batch, into the packet marked D will be accumulated into the A loss batch, into the
delay statistics and will be forwarded as normal. Whether the packet delay statistics and will be forwarded as normal. Whether the packet
is actually counted twice (for loss and delay) or whether the two is actually counted twice (for loss and delay) or whether the two
counters are reconciled during reporting is a local matter. counters are reconciled during reporting is a local matter.
Now consider case 3 of Figure 1 where a small batch of packets are Now consider case 3 of Figure 1 where a small batch of packets are
marked for delay across a loss batch boundary. These packets need to marked for delay across a loss batch boundary. These packets need to
considered as part of batch A or a part of batch B, and any RFC6374 considered as part of batch A or a part of batch B, and any RFC6374
Query needs to take place after all the packets A or D (which ever Query needs to take place after all the packets A or D (which ever
option is chosen) have arrived at the receiving LSR. option is chosen) have arrived at the receiving LSR.
skipping to change at page 9, line 11 skipping to change at page 9, line 11
the Query message), then the Responder MUST respond with 0 packets in the Query message), then the Responder MUST respond with 0 packets in
each bucket until it has been configured for a full measurement each bucket until it has been configured for a full measurement
period. This indicates that it was configured at the time of the period. This indicates that it was configured at the time of the
last response message, and thus the response is valid for the whole last response message, and thus the response is valid for the whole
interval. As per the [RFC6374] convention the Number of pkts in interval. As per the [RFC6374] convention the Number of pkts in
Bucket fields are included in the Query message and set to zero. Bucket fields are included in the Query message and set to zero.
Out of band configuration is permitted by this mode of operation. Out of band configuration is permitted by this mode of operation.
Note this is a departure from the normal fixed format used in Note this is a departure from the normal fixed format used in
RFC6374. We need to establish if this is problematic or not. RFC6374.
This RFC6374 message is carried over an LSP in the way described in This RFC6374 message is carried over an LSP in the way described in
[RFC6374] and over an LSP with an SFL as described in Section 9. [RFC6374] and over an LSP with an SFL as described in Section 9.
7.2. Method 2 Classic Standard Deviation 7.2. Method 2 Classic Standard Deviation
In this method, provision is made for reporting the following delay In this method, provision is made for reporting the following delay
characteristics: characteristics:
1. Number of packets in the batch (n). 1. Number of packets in the batch (n).
skipping to change at page 9, line 46 skipping to change at page 9, line 46
Characteristics 1, 2 and 5 can be used to calculate the variance of Characteristics 1, 2 and 5 can be used to calculate the variance of
the inter-packet gap and hence the standard deviation giving a view the inter-packet gap and hence the standard deviation giving a view
of the distribution of packet delays and hence the jitter. The of the distribution of packet delays and hence the jitter. The
equation for the variance (var) is given by: equation for the variance (var) is given by:
var = (SS - S*S/n)/(n-1) var = (SS - S*S/n)/(n-1)
There is some concern over the use of this algorithm for measuring There is some concern over the use of this algorithm for measuring
variance, because SS and S*S/n can be similar numbers, particularly variance, because SS and S*S/n can be similar numbers, particularly
where variance is low. However the method commends it self by not where variance is low. However the method commends it self by not
requiring a division in the hardware. A future version of this requiring a division in the hardware.
document will look at using improved statistical methods such as the
assumed mean.
7.2.1. RFC6374 Multi-Packet Delay Measurement Message Format 7.2.1. RFC6374 Multi-Packet Delay Measurement Message Format
The packet format of an RFC6374 Multi-Packet Delay Measurement The packet format of an RFC6374 Multi-Packet Delay Measurement
Message is shown below: Message is shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length | |Version| Flags | Control Code | Message Length |
skipping to change at page 11, line 31 skipping to change at page 11, line 31
If detailed packet delay measurement is required then it might be If detailed packet delay measurement is required then it might be
possible to record the inter-packet gap for each packet pair. In possible to record the inter-packet gap for each packet pair. In
other that exception cases of slow flows or small batch sizes, this other that exception cases of slow flows or small batch sizes, this
would create a large demand on storage in the instrumentation system, would create a large demand on storage in the instrumentation system,
bandwidth to such a storage system and bandwidth to the analytics bandwidth to such a storage system and bandwidth to the analytics
system. Such a measurement technique is outside the scope of this system. Such a measurement technique is outside the scope of this
document. document.
7.4. Average Delay 7.4. Average Delay
Introduced in [I-D.ietf-ippm-alt-mark] is the concept of a one way Introduced in [RFC8321] is the concept of a one way delay measurement
delay measurement in which the average time of arrival of a set of in which the average time of arrival of a set of packets is measured.
packets is measured. In this approach the packet is time-stamped at In this approach the packet is time-stamped at arrival and the
arrival and the Responder returns the sum of the time-stamps and the Responder returns the sum of the time-stamps and the number of times-
number of times-tamps. From this the analytics engine can determine tamps. From this the analytics engine can determine the mean delay.
the mean delay. An alternative model is that the Responder returns An alternative model is that the Responder returns the time stamp of
the time stamp of the first and last packet and the number of the first and last packet and the number of packets. This method has
packets. This method has the advantage of allowing the average delay the advantage of allowing the average delay to be determined at a
to be determined at a number of points along the packet path and number of points along the packet path and allowing the components of
allowing the components of the delay to be characterized. the delay to be characterized.
The packet format of an RFC6374 Average Delay Measurement Message is The packet format of an RFC6374 Average Delay Measurement Message is
shown below: shown below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Flags | Control Code | Message Length | |Version| Flags | Control Code | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QTF | RTF | RPTF | Reserved | | QTF | RTF | RPTF | Reserved |
skipping to change at page 13, line 9 skipping to change at page 13, line 9
This RFC6374 message is carried over an LSP in the way described in This RFC6374 message is carried over an LSP in the way described in
[RFC6374] and over an LSP with an SFL as described in Section 9. As [RFC6374] and over an LSP with an SFL as described in Section 9. As
is the convention with RFC6374, the Query message contains is the convention with RFC6374, the Query message contains
placeholders for the Response message. The placeholders are sent as placeholders for the Response message. The placeholders are sent as
zero. zero.
8. Sampled Measurement 8. Sampled Measurement
In the discussion so far it has been assumed that we would measure In the discussion so far it has been assumed that we would measure
the delay characteristics of every packet in a delay measurement the delay characteristics of every packet in a delay measurement
interval defined by an SL of constant colour. In interval defined by an SL of constant colour. In [RFC8321] the
[I-D.ietf-ippm-alt-mark] the concept of a sampled measurement is concept of a sampled measurement is considered. That is the
considered. That is the Responder only measures a packet at the Responder only measures a packet at the start of a group of packets
start of a group of packets being marked for delay measurement by a being marked for delay measurement by a particular colour, rather
particular colour, rather than every packet in the marked batch. A than every packet in the marked batch. A measurement interval is not
measurement interval is not defined by the duration of a marked batch defined by the duration of a marked batch of packets but the interval
of packets but the interval between a pair of RFC6374 packets taking between a pair of RFC6374 packets taking a readout of the delay
a readout of the delay characteristic. This approach has the characteristic. This approach has the advantage that the measurement
advantage that the measurement is not impacted by ECMP effects. is not impacted by ECMP effects.
9. Carrying RFC6374 Packets over an LSP using an SFL 9. Carrying RFC6374 Packets over an LSP using an SFL
The packet format of an RFC6374 Query message using SFLs is shown in The packet format of an RFC6374 Query message using SFLs is shown in
Figure 5. Figure 5.
+-------------------------------+ +-------------------------------+
| | | |
| LSP | | LSP |
| Label | | Label |
skipping to change at page 17, line 44 skipping to change at page 17, line 44
IANA is request to allocate a new TLV from the 0-127 range on the IANA is request to allocate a new TLV from the 0-127 range on the
MPLS Loss/Delay Measurement TLV Object Registry: MPLS Loss/Delay Measurement TLV Object Registry:
Type Description Reference Type Description Reference
---- --------------------------------- --------- ---- --------------------------------- ---------
TBD Synonymous Flow Label This TBD Synonymous Flow Label This
A value of 4 is recommended. A value of 4 is recommended.
RFC Editor please delete this line
[RFC3032][I-D.bryant-mpls-sfl-control]
15. References 15. References
15.1. Normative References 15.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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
skipping to change at page 18, line 30 skipping to change at page 18, line 34
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011, <https://www.rfc- DOI 10.17487/RFC6374, September 2011, <https://www.rfc-
editor.org/info/rfc6374>. editor.org/info/rfc6374>.
[RFC7876] Bryant, S., Sivabalan, S., and S. Soni, "UDP Return Path [RFC7876] Bryant, S., Sivabalan, S., and S. Soni, "UDP Return Path
for Packet Loss and Delay Measurement for MPLS Networks", for Packet Loss and Delay Measurement for MPLS Networks",
RFC 7876, DOI 10.17487/RFC7876, July 2016, RFC 7876, DOI 10.17487/RFC7876, July 2016,
<https://www.rfc-editor.org/info/rfc7876>. <https://www.rfc-editor.org/info/rfc7876>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
15.2. Informative References 15.2. Informative References
[I-D.bryant-mpls-sfl-control] [I-D.bryant-mpls-sfl-control]
Bryant, S., Swallow, G., and S. Sivabalan, "MPLS Flow Bryant, S., Swallow, G., and S. Sivabalan, "MPLS Flow
Identification Considerations", draft-bryant-mpls-sfl- Identification Considerations", draft-bryant-mpls-sfl-
control-02 (work in progress), October 2017. control-02 (work in progress), October 2017.
[I-D.bryant-mpls-sfl-framework] [I-D.ietf-mpls-sfl-framework]
Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S.,
and G. Mirsky, "Synonymous Flow Label Framework", draft- and G. Mirsky, "Synonymous Flow Label Framework", draft-
bryant-mpls-sfl-framework-05 (work in progress), June ietf-mpls-sfl-framework-03 (work in progress), June 2018.
2017.
[I-D.chen-ippm-coloring-based-ipfpm-framework]
Chen, M., Zheng, L., Mirsky, G., Fioccola, G., and T.
Mizrahi, "IP Flow Performance Measurement Framework",
draft-chen-ippm-coloring-based-ipfpm-framework-06 (work in
progress), March 2016.
[I-D.ietf-ippm-alt-mark]
Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L.,
Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate Marking method for passive and hybrid
performance monitoring", draft-ietf-ippm-alt-mark-13 (work
in progress), October 2017.
[I-D.ietf-mpls-flow-ident]
Bryant, S., Pignataro, C., Chen, M., Li, Z., and G.
Mirsky, "MPLS Flow Identification Considerations", draft-
ietf-mpls-flow-ident-05 (work in progress), July 2017.
[I-D.tempia-ippm-p3m]
Capello, A., Cociglio, M., Fioccola, G., Castaldelli, L.,
and A. Bonda, "A packet based method for passive
performance monitoring", draft-tempia-ippm-p3m-03 (work in
progress), March 2016.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, Services", RFC 3270, DOI 10.17487/RFC3270, May 2002,
<https://www.rfc-editor.org/info/rfc3270>. <https://www.rfc-editor.org/info/rfc3270>.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010,
<https://www.rfc-editor.org/info/rfc5921>. <https://www.rfc-editor.org/info/rfc5921>.
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[RFC8372] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G.
Mirsky, "MPLS Flow Identification Considerations",
RFC 8372, DOI 10.17487/RFC8372, May 2018,
<https://www.rfc-editor.org/info/rfc8372>.
Authors' Addresses Authors' Addresses
Stewart Bryant Stewart Bryant
Huawei Huawei
Email: stewart.bryant@gmail.com Email: stewart.bryant@gmail.com
Mach Chen Mach Chen
Huawei Huawei
skipping to change at page 20, line 4 skipping to change at page 19, line 43
Mach Chen Mach Chen
Huawei Huawei
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
Zhenbin Li Zhenbin Li
Huawei Huawei
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
George Swallow George Swallow
Cisco Systems Southend Technical Center
Email: swallow.ietf@gmail.com Email: swallow.ietf@gmail.com
Siva Sivabalan Siva Sivabalan
Cisco Systems Cisco Systems
Email: msiva@cisco.com Email: msiva@cisco.com
Gregory Mirsky Gregory Mirsky
ZTE Corp. ZTE Corp.
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
 End of changes. 26 change blocks. 
83 lines changed or deleted 75 lines changed or added

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