< draft-mirsky-ippm-hybrid-two-step-05.txt   draft-mirsky-ippm-hybrid-two-step-06.txt >
IPPM Working Group G. Mirsky IPPM Working Group G. Mirsky
Internet-Draft ZTE Corp. Internet-Draft ZTE Corp.
Intended status: Standards Track W. Lingqiang Intended status: Standards Track W. Lingqiang
Expires: October 16, 2020 G. Zhui Expires: April 29, 2021 G. Zhui
ZTE Corporation ZTE Corporation
April 14, 2020 H. Song
Futurewei Technologies
October 26, 2020
Hybrid Two-Step Performance Measurement Method Hybrid Two-Step Performance Measurement Method
draft-mirsky-ippm-hybrid-two-step-05 draft-mirsky-ippm-hybrid-two-step-06
Abstract Abstract
Development of, and advancements in, automation of network operations Development of, and advancements in, automation of network operations
brought new requirements for measurement methodology. Among them is brought new requirements for measurement methodology. Among them is
the ability to collect instant network state as the packet being the ability to collect instant network state as the packet being
processed by the networking elements along its path through the processed by the networking elements along its path through the
domain. This document introduces a new hybrid measurement method, domain. This document introduces a new hybrid measurement method,
referred to as hybrid two-step, as it separates the act of measuring referred to as hybrid two-step, as it separates the act of measuring
and/or calculating the performance metric from the act of collecting and/or calculating the performance metric from the act of collecting
skipping to change at page 1, line 39 skipping to change at page 1, line 41
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 October 16, 2020. This Internet-Draft will expire on April 29, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 15 skipping to change at page 2, line 17
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
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5
4.1. Operation of the HTS Ingress Node . . . . . . . . . . . . 6 4.1. Operation of the HTS Ingress Node . . . . . . . . . . . . 6
4.2. Operation of the HTS Transient Node . . . . . . . . . . . 7 4.2. Operation of the HTS Intermediate Node . . . . . . . . . 8
4.3. Operation of the HTS Egress Node . . . . . . . . . . . . 8 4.3. Operation of the HTS Egress Node . . . . . . . . . . . . 9
4.4. Considerations for HTS Timers . . . . . . . . . . . . . . 8 4.4. Considerations for HTS Timers . . . . . . . . . . . . . . 9
4.5. Deploying HTS in a Multicast Network . . . . . . . . . . 8 4.5. Deploying HTS in a Multicast Network . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
Successful resolution of challenges of automated network operation, Successful resolution of challenges of automated network operation,
as part of, for example, overall service orchestration or data center as part of, for example, overall service orchestration or data center
operation, relies on a timely collection of accurate information that operation, relies on a timely collection of accurate information that
reflects the state of network elements on an unprecedented scale. reflects the state of network elements on an unprecedented scale.
Because performing the analysis and act upon the collected Because performing the analysis and act upon the collected
information requires considerable computing and storage resources, information requires considerable computing and storage resources,
the network state information is unlikely to be processed by the the network state information is unlikely to be processed by the
skipping to change at page 3, line 20 skipping to change at page 3, line 22
defined methods to collect telemetry information in a separate packet defined methods to collect telemetry information in a separate packet
from each node traversed by the monitored data flow. Examples of from each node traversed by the monitored data flow. Examples of
this approach to collecting telemetry information are this approach to collecting telemetry information are
[I-D.ietf-ippm-ioam-direct-export] and [I-D.ietf-ippm-ioam-direct-export] and
[I-D.song-ippm-postcard-based-telemetry]. These methods allow data [I-D.song-ippm-postcard-based-telemetry]. These methods allow data
collection from any arbitrary path and avoid directly impacting data collection from any arbitrary path and avoid directly impacting data
packets. On the other hand, the correlation of data and the packets. On the other hand, the correlation of data and the
monitored flow requires that each packet with telemetry information monitored flow requires that each packet with telemetry information
also includes characteristic information about the monitored flow. also includes characteristic information about the monitored flow.
This document introduces Hybrid Two-Step (HTS) as a new hybrid This document introduces Hybrid Two-Step (HTS) as a new method of
measurement method that allows achieving better accuracy of a telemetry collection that improvers accuracy of a measurement by
measurement by separating the act of measuring or calculating the separating the act of measuring or calculating the performance metric
performance metric from the collecting and transporting this from the collecting and transporting this information while
information. The Hybrid Two-Step method extends the two-step mode of minimizing the overhead of the generated load in a network. HTS
Residence Time Measurement (RTM) defined in [RFC8169] to on-path method extends the two-step mode of Residence Time Measurement (RTM)
network state collection and transport. HTS allows the collection of defined in [RFC8169] to on-path network state collection and
telemetry information from any arbitrary path, does not change data transport. HTS allows the collection of telemetry information from
packets of the monitored flow and makes the process of attribution of any arbitrary path, does not change data packets of the monitored
telemetry to the data flow simple. flow and makes the process of attribution of telemetry to the data
flow simple.
2. Conventions used in this document 2. Conventions used in this document
2.1. Terminology 2.1. Terminology
RTM Residence Time Measurement RTM Residence Time Measurement
ECMP Equal Cost Multipath ECMP Equal Cost Multipath
MTU Maximum Transmission Unit MTU Maximum Transmission Unit
skipping to change at page 4, line 43 skipping to change at page 4, line 49
from the ideal case by any fixed amount and a correction can be from the ideal case by any fixed amount and a correction can be
applied to compute the same time difference taking into account the applied to compute the same time difference taking into account the
known fixed time associated with the actual measurement. In this known fixed time associated with the actual measurement. In this
way, the resulting time difference reflects any variable delay way, the resulting time difference reflects any variable delay
associated with queuing. associated with queuing.
Depending on the implementation, it may be a challenge to compute the Depending on the implementation, it may be a challenge to compute the
difference between message arrival and departure times and - on the difference between message arrival and departure times and - on the
fly - add the necessary residence time information to the same fly - add the necessary residence time information to the same
message. And that task may become even more challenging if the message. And that task may become even more challenging if the
packet is encrypted. Implementations SHOULD NOT record a message packet is encrypted. Recording the departure of a packet time in the
departure time that may be significantly inaccurate in the same same packet may be decremental to the accuracy of the measurement,
message, as the result of estimating the departure time that includes because the departure time includes the variable time component (such
the variable time component (such as that associated with buffering as that associated with buffering and queuing of the packet). A
and queuing of the message). A similar problem may cause a lower similar problem may lower the quality of, for example, information
quality of, for example, information that characterizes utilization that characterizes utilization of the egress interface. If unable to
of the egress interface. If unable to obtain the data consistently, obtain the data consistently, without variable delays for additional
without variable delays for additional processing, information may processing, information may not accurately reflect the egress
not accurately reflect the state at the egress interface. To interface state. To mitigate this problem [RFC8169] defined an RTM
mitigate this problem [RFC8169] defined an RTM two-step mode. two-step mode.
Another challenge associated with methods that collect network state Another challenge associated with methods that collect network state
information into the actual data packet is the risk to exceed the information into the actual data packet is the risk to exceed the
Maximum Transmission Unit (MTU) size, especially if the packet Maximum Transmission Unit (MTU) size, especially if the packet
traverses overlay domains or VPNs. Since the fragmentation is not traverses overlay domains or VPNs. Since the fragmentation is not
available at the transport network, operators may have to reduce MTU available at the transport network, operators may have to reduce MTU
size advertised to client layer or risk missing network state data size advertised to client layer or risk missing network state data
for the part, most probably the latter part, of the path. for the part, most probably the latter part, of the path.
4. Theory of Operation 4. Theory of Operation
The HTS method consists of the two phases: The HTS method consists of the two phases:
o performing a measurement or obtaining network state information, o performing a measurement or obtaining network state information,
one or more than one type, on a node; one or more than one type, on a node;
o collecting and transporting the measurement. o collecting and transporting the measurement.
HTS uses HTS Trigger carried in a data packet or a specially HTS uses HTS Trigger carried in a data packet or a specially
constructed test packet. Nature of the HTS Trigger is transport constructed test packet. For example, an HTS Trigger could be a
network layer specific, and its description is outside the scope of packet that includes iOAM Namespace-ID and IOAM-Trace-Type
this document. The packet that includes the HTS Trigger in this information [I-D.ietf-ippm-ioam-data] or a packet in the flow to
document also referred to as the trigger packet. which the Alternate-Marking method [RFC8321] is applied. Nature of
the HTS Trigger is a transport network layer-specific, and its
description is outside the scope of this document. The packet that
includes the HTS Trigger in this document is also referred to as the
trigger packet.
The HTS method uses the HTS Follow-up packet, in this document also The HTS method uses the HTS Follow-up packet, in this document also
referred to as the follow-up packet, to collect measurement and referred to as the follow-up packet, to collect measurement and
network state data from the nodes. The node that creates the HTS network state data from the nodes. The node that creates the HTS
Trigger also generates the HTS Follow-up packet. The follow-up Trigger also generates the HTS Follow-up packet. The follow-up
packet contains characteristic information, copied from the trigger packet contains characteristic information, copied from the trigger
packet, sufficient for participating HTS nodes to associate it with packet, sufficient for participating HTS nodes to associate it with
the original packet. The exact composition of the characteristic the original packet. The exact composition of the characteristic
information is specific for each transport network, and its information is specific for each transport network, and its
definition is outside the scope of this document. The follow-up definition is outside the scope of this document. The follow-up
skipping to change at page 6, line 42 skipping to change at page 7, line 5
Fields of the HTS shim are as follows: Fields of the HTS shim are as follows:
Version (Ver) is the two-bits long field. It specifies the Version (Ver) is the two-bits long field. It specifies the
version of the HTS shim format. This document defines the format version of the HTS shim format. This document defines the format
for the 0b00 value of the field. for the 0b00 value of the field.
HTS Shim Length is the six bits-long field. It defines the length HTS Shim Length is the six bits-long field. It defines the length
of the HTS shim in bytes. The minimal value of the field is four of the HTS shim in bytes. The minimal value of the field is four
bytes. bytes.
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F| Reserved |
+-+-+-+-+-+-+-+-+
Figure 2: Flags Field Format
Flags is eight-bits long field. The format of the Flags field Flags is eight-bits long field. The format of the Flags field
displayed in Figure 2. displayed in Figure 2.
Full (F) flag MUST be set to zero by the node originating the Full (F) flag MUST be set to zero by the node originating the
HTS follow-up packet and MUST be set to one by the node that HTS follow-up packet and MUST be set to one by the node that
does not add its telemetry data to avoid exceeding MTU size. does not add its telemetry data to avoid exceeding MTU size.
The node originating the follow-up packet MUST zero the The node originating the follow-up packet MUST zero the
Reserved field and ignore it on the receipt. Reserved field and ignore it on the receipt.
Sequence Number is 16 bits-long field. The value of the field Sequence Number is 16 bits-long field. The zero-based value of
reflects the number of the HTS follow-up packet in the sequence of the field reflects the place of the HTS follow-up packet in the
the HTS follow-up packets originated in response to the same HTS sequence of the HTS follow-up packets originated in response to
trigger. The ingress node MUST set the value of the field to the same HTS trigger. The ingress node MUST set the value of the
zero. field to zero.
Telemetry Data Profile is the optional variable length field of Telemetry Data Profile is the optional variable length field of
bit-size flags. Each flag indicates requested type of telemetry bit-size flags. Each flag indicates requested type of telemetry
data to be collected at the each HTS node. The increment of the data to be collected at the each HTS node. The increment of the
field is four bytes with a minimum length of zero. field is four bytes with a minimum length of zero. For example,
IOAM-Trace-Type information defined in [I-D.ietf-ippm-ioam-data]
can be used in the Telemetry Data Profile field.
0 0 1 2 3
0 1 2 3 4 5 6 7 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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F| Reserved | | Type | Length |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Flags Field Format Figure 3: Telemetry Data TLV Format
4.2. Operation of the HTS Transient Node Telemetry Data TLV is a variable-length field. Multiple TLVs MAY
be placed in an HTS packet. Additional TLVs may be enclosed
within a given TLV, subject to the semantics of the (outer) TLV in
question. Figure 3 presentes the format of a Telementry Data TLV,
where fields are defined as the following:
Upon receiving the trigger packet the HTS transient node MUST: Type - two-octet-long field that characterizes the
interpretation of the Value field.
Length - two-octet-long field equal to the length of the Value
field in octets.
Value - a variable-length field. Its interpretation and
encoding is determined by the value of the Type field. IOAM
data fields, defined in [I-D.ietf-ippm-ioam-data], MAY be
carried in the Value field.
All multibyte fields defined in this specification are in network
byte order.
4.2. Operation of the HTS Intermediate Node
Upon receiving the trigger packet the HTS intermediate node MUST:
o copy the transport information; o copy the transport information;
o start the HTS Follow-up Timer for the obtained flow. o start the HTS Follow-up Timer for the obtained flow.
Upon receiving the follow-up packet the HTS transient node MUST: Upon receiving the follow-up packet the HTS intermediate node MUST:
o verify that the matching transport information exists and the Full o verify that the matching transport information exists and the Full
flag is cleared, then stop the associated HTS Follow-up timer; flag is cleared, then stop the associated HTS Follow-up timer;
o collect telemetry data requested in the Telemetry Data Profile o collect telemetry data requested in the Telemetry Data Profile
field or defined by the local HTS policy; field or defined by the local HTS policy;
o if adding the collected telemetry would not exceed MTU, then o if adding the collected telemetry would not exceed MTU, then
append data into Telemetry Data TLVs field and transmit the append data into Telemetry Data TLVs field and transmit the
follow-up packet; follow-up packet;
o otherwise, set the value of the Full flag to one and transmit the o otherwise, set the value of the Full flag to one and transmit the
received a follow-up packet; received a follow-up packet;
o originate the new follow-up packet using the same transport o originate the new follow-up packet using the same transport
information. The value of the Sequence Number field in the HTS information. The value of the Sequence Number field in the HTS
shim MUST be set to the value of the field in the received follow- shim MUST be set to the value of the field in the received follow-
up packet incremented by one. Copy collected telemetry data and up packet incremented by one. Copy collected telemetry data and
transmit the packet. transmit the packet.
If the follow-up timer expires the transient node MUST: If the HTS Follow-up Timer expires, the intermediate node MUST:
o originate the follow-up packet using transport information o originate the follow-up packet using transport information
associated with the expired timer; associated with the expired timer;
o initialize the HTS shim by setting Version field to 0b00 and o initialize the HTS shim by setting Version field to 0b00 and
Sequence Number field to 0. Values of HTS Shim Length and Sequence Number field to 0. Values of HTS Shim Length and
Telemetry Data Profile fields MAY be set according to the local Telemetry Data Profile fields MAY be set according to the local
policy. policy.
o copy telemetry information into Telemetry Data TLVs field and o copy telemetry information into Telemetry Data TLVs field and
transmit the packet. transmit the packet.
If the intermediate node receives a "late" follow-up packet, i.e., a
packet to which the node has no associated HTS Follow-up timer, the
node MUST forward the "late" packet.
4.3. Operation of the HTS Egress Node 4.3. Operation of the HTS Egress Node
Upon receiving the trigger packet the HTS egress node MUST: Upon receiving the trigger packet the HTS egress node MUST:
o copy the transport information; o copy the transport information;
o start the HTS Collection timer for the obtained flow. o start the HTS Collection timer for the obtained flow.
When the egress node receives the follow-up packet for the known When the egress node receives the follow-up packet for the known
flow, i.e., the flow to which the Collection timer is running, the flow, i.e., the flow to which the Collection timer is running, the
skipping to change at page 9, line 14 skipping to change at page 10, line 13
be set based on multicast routing information or explicit information be set based on multicast routing information or explicit information
included in the special header, as, for example, in Bit-Indexed included in the special header, as, for example, in Bit-Indexed
Explicit Replication [RFC8296]. A replicating node processes HTS Explicit Replication [RFC8296]. A replicating node processes HTS
packet as defined below: packet as defined below:
o the first transmitted multicast packet MUST be followed by the o the first transmitted multicast packet MUST be followed by the
received corresponding HTS packet as described in Section 4.2; received corresponding HTS packet as described in Section 4.2;
o each consecutively transmitted copy of the original multicast o each consecutively transmitted copy of the original multicast
packet MUST be followed by the new HTS packet originated by the packet MUST be followed by the new HTS packet originated by the
replicating node that acts as a transient HTS node when the replicating node that acts as a intermediate HTS node when the HTS
Follow-up timer expired. Follow-up timer expired.
As a result, there are no duplicate copies of Telemetry Data TLV for As a result, there are no duplicate copies of Telemetry Data TLV for
the same pair of ingress and egress interfaces. At the same time, the same pair of ingress and egress interfaces. At the same time,
all ingress/egress pairs traversed by the given multicast packet all ingress/egress pairs traversed by the given multicast packet
reflected in their respective Telemetry Data TLV. Consequently, a reflected in their respective Telemetry Data TLV. Consequently, a
centralized controller would be able to reconstruct and analyze the centralized controller would be able to reconstruct and analyze the
state of the particular multicast distribution tree based on HTS state of the particular multicast distribution tree based on HTS
packets collected from egress nodes. packets collected from egress nodes.
skipping to change at page 10, line 31 skipping to change at page 11, line 30
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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in
P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, progress), July 2020.
d., and J. Lemon, "Data Fields for In-situ OAM", draft-
ietf-ippm-ioam-data-09 (work in progress), March 2020.
[I-D.ietf-ippm-ioam-direct-export] [I-D.ietf-ippm-ioam-direct-export]
Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F.,
Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ
OAM Direct Exporting", draft-ietf-ippm-ioam-direct- OAM Direct Exporting", draft-ietf-ippm-ioam-direct-
export-00 (work in progress), February 2020. export-01 (work in progress), August 2020.
[I-D.song-ippm-postcard-based-telemetry] [I-D.song-ippm-postcard-based-telemetry]
Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee,
"Postcard-based On-Path Flow Data Telemetry", draft-song- "Postcard-based On-Path Flow Data Telemetry", draft-song-
ippm-postcard-based-telemetry-07 (work in progress), April ippm-postcard-based-telemetry-07 (work in progress), April
2020. 2020.
[P4.INT] "In-band Network Telemetry (INT)", P4.org Specification, [P4.INT] "In-band Network Telemetry (INT)", P4.org Specification,
October 2017. October 2017.
skipping to change at page 11, line 20 skipping to change at page 12, line 16
and A. Vainshtein, "Residence Time Measurement in MPLS and A. Vainshtein, "Residence Time Measurement in MPLS
Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017, Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017,
<https://www.rfc-editor.org/info/rfc8169>. <https://www.rfc-editor.org/info/rfc8169>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non- for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>. 2018, <https://www.rfc-editor.org/info/rfc8296>.
[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>.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
ZTE Corp. ZTE Corp.
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
Wang Lingqiang Wang Lingqiang
ZTE Corporation ZTE Corporation
No 19 ,East Huayuan Road No 19 ,East Huayuan Road
skipping to change at line 518 skipping to change at page 13, line 4
Email: wang.lingqiang@zte.com.cn Email: wang.lingqiang@zte.com.cn
Guo Zhui Guo Zhui
ZTE Corporation ZTE Corporation
No 19 ,East Huayuan Road No 19 ,East Huayuan Road
Beijing 100191 Beijing 100191
P.R.China P.R.China
Phone: +86 10 82963945 Phone: +86 10 82963945
Email: guo.zhui@zte.com.cn Email: guo.zhui@zte.com.cn
Haoyu Song
Futurewei Technologies
2330 Central Expressway
Santa Clara
USA
Email: hsong@futurewei.com
 End of changes. 24 change blocks. 
63 lines changed or deleted 110 lines changed or added

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