< draft-ietf-bier-pmmm-oam-05.txt | draft-ietf-bier-pmmm-oam-06.txt > | |||
---|---|---|---|---|
BIER Working Group G. Mirsky | BIER Working Group G. Mirsky | |||
Internet-Draft ZTE Corp. | Internet-Draft ZTE Corp. | |||
Intended status: Standards Track L. Zheng | Intended status: Standards Track L. Zheng | |||
Expires: June 13, 2019 M. Chen | Expires: December 31, 2019 M. Chen | |||
Huawei Technologies | ||||
G. Fioccola | G. Fioccola | |||
Telecom Italia | Huawei Technologies | |||
December 10, 2018 | June 29, 2019 | |||
Performance Measurement (PM) with Marking Method in Bit Index Explicit | Performance Measurement (PM) with Marking Method in Bit Index Explicit | |||
Replication (BIER) Layer | Replication (BIER) Layer | |||
draft-ietf-bier-pmmm-oam-05 | draft-ietf-bier-pmmm-oam-06 | |||
Abstract | Abstract | |||
This document describes a hybrid performance measurement method for | This document describes a hybrid performance measurement method for | |||
multicast service over Bit Index Explicit Replication (BIER) domain. | multicast service through a Bit Index Explicit Replication domain. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 June 13, 2019. | This Internet-Draft will expire on December 31, 2019. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 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 | |||
2. Conventions used in this document . . . . . . . . . . . . . . 2 | 2. Conventions used in this document . . . . . . . . . . . . . . 2 | |||
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 | 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
3. OAM Field in BIER Header . . . . . . . . . . . . . . . . . . 3 | 3. OAM Field in BIER Header . . . . . . . . . . . . . . . . . . 3 | |||
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 3 | 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 | |||
4.1. Single Mark Enabled Measurement . . . . . . . . . . . . . 4 | 4.1. Single-Marking Enabled Measurement . . . . . . . . . . . 4 | |||
4.2. Double Mark Enabled Measurement . . . . . . . . . . . . . 5 | 4.2. Double-Marking Enabled Measurement . . . . . . . . . . . 5 | |||
4.3. Operational Considerations . . . . . . . . . . . . . . . 6 | ||||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 | 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 6 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 7 | 8.2. Informative References . . . . . . . . . . . . . . . . . 8 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
1. Introduction | 1. Introduction | |||
[RFC8279] introduces and explains Bit Index Explicit Replication | [RFC8279] introduces and explains the Bit Index Explicit Replication | |||
(BIER) architecture and how it supports forwarding of multicast data | (BIER) architecture and how it supports the forwarding of multicast | |||
packets. [RFC8296] specified that in case of BIER encapsulation in | data packets. [RFC8296] specified that in the case of BIER | |||
MPLS network a BIER-MPLS label, the label that is at the bottom of | encapsulation in an MPLS network, a BIER-MPLS label, the label that | |||
the label stack, uniquely identifies the multicast flow. [RFC8321] | is at the bottom of the label stack, uniquely identifies the | |||
describes hybrid performance measurement method, per [RFC7799] | multicast flow. [RFC8321] describes a hybrid performance measurement | |||
classification of measurement methods. Packet Network Performance | method, per RFC7799's classification of measurement methods | |||
Monitoring (PNPM), which can be used to measure packet loss, latency, | [RFC7799]. The method, called Packet Network Performance Monitoring | |||
and jitter on live traffic. Because this method is based on marking | (PNPM), can be used to measure packet loss, latency, and jitter on | |||
consecutive batches of packets the method often referred to as | live traffic complies with requirements #5 and #12 listed in | |||
Marking Method (MM). | [I-D.ietf-bier-oam-requirements]. Because this method is based on | |||
marking consecutive batches of packets, the method is often referred | ||||
to as a marking method. | ||||
This document defines how marking method can be used on BIER layer to | This document defines how the marking method can be used on the BIER | |||
measure packet loss and delay metrics of a multicast flow in MPLS | layer to measure packet loss and delay metrics of a multicast flow in | |||
network. | an MPLS network. | |||
2. Conventions used in this document | 2. Conventions used in this document | |||
2.1. Terminology | 2.1. Terminology | |||
BFR: Bit-Forwarding Router | BFR: Bit-Forwarding Router | |||
BFER: Bit-Forwarding Egress Router | BFER: Bit-Forwarding Egress Router | |||
BFIR: Bit-Forwarding Ingress Router | BFIR: Bit-Forwarding Ingress Router | |||
BIER: Bit Index Explicit Replication | ||||
MM: Marking Method | BIER: Bit Index Explicit Replication | |||
OAM: Operations, Administration and Maintenance | OAM: Operations, Administration and Maintenance | |||
2.2. Requirements Language | 2.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 BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
3. OAM Field in BIER Header | 3. OAM Field in BIER Header | |||
[RFC8296] defined the two-bit long field, referred to as OAM, | [RFC8296] defined the two-bits long field, referred to as OAM. The | |||
designated for the marking performance measurement method. The OAM | OAM field can be used for the marking performance measurement method. | |||
field MUST NOT be used in defining forwarding and/or quality of | ||||
service treatment of a BIER packet. The OAM field MUST be used only | ||||
for the performance measurement of data traffic in BIER layer. | ||||
Because the setting of the field to any value does not affect | Because the setting of the field to any value does not affect | |||
forwarding and/or quality of service treatment of a packet, the | forwarding and/or quality of service treatment of a packet, using the | |||
marking method in BIER layer can be viewed as the example of the | OAM field for PNPM in BIER layer can be viewed as the example of the | |||
hybrid performance measurement method. | hybrid performance measurement method. | |||
The Figure 1 displays format of the OAM field | Figure 1 displays the interpretation of the OAM field defined in this | |||
specification for the use by PNPM method. | ||||
0 | 0 | |||
0 1 | 0 1 | |||
+-+-+-+-+ | +-+-+-+-+ | |||
| L | D | | | S | D | | |||
+-+-+-+-+ | +-+-+-+-+ | |||
Figure 1: OAM field of BIER Header format | Figure 1: OAM field of BIER Header format | |||
where: | where: | |||
o L - Loss flag; | o S - Single-Marking flag; | |||
o D - Delay flag. | o D - Double-Marking flag. | |||
4. Theory of Operation | 4. Theory of Operation | |||
The marking method can be successfully used in the multicast | The marking method can be used in the multicast environment supported | |||
environment supported by BIER layer. Without limiting any generality | by BIER layer. Without limiting any generality consider multicast | |||
consider multicast network presented in Figure 2. Any combination of | network presented in Figure 2. Any combination of markings can be | |||
markings, Loss and/or Delay, can be applied to a multicast flow by | applied to a multicast flow by the Bit Forwarding Ingress Router | |||
any Bit Forwarding Router (BFR) at either ingress or egress point to | (BFIR) at either ingress or egress point to perform node, link, | |||
perform node, link, segment or end-to-end measurement to detect | segment or end-to-end measurement to detect performance degradation | |||
performance degradation defect and localize it efficiently. | defect and localize it efficiently. | |||
----- | ----- | |||
--| D | | --| D | | |||
----- / ----- | ----- / ----- | |||
--| B |-- | --| B |-- | |||
/ ----- \ ----- | / ----- \ ----- | |||
/ --| E | | / --| E | | |||
----- / ----- | ----- / ----- | |||
| A |--- ----- | | A |--- ----- | |||
----- \ --| F | | ----- \ --| F | | |||
\ ----- / ----- | \ ----- / ----- | |||
--| C |-- | --| C |-- | |||
----- \ ----- | ----- \ ----- | |||
--| G | | --| G | | |||
----- | ----- | |||
Figure 2: Multicast network | Figure 2: Multicast network | |||
Using the marking method, a BFR creates distinct sub-flows in the | Using the marking method, a BFIR creates distinct sub-flows in the | |||
particular multicast traffic over BIER layer. Each sub-flow consists | particular multicast traffic over BIER layer. Each sub-flow consists | |||
of consecutive blocks, consisting of identically marked packets, that | of consecutive blocks of identically marked packets. For example, a | |||
are unambiguously recognizable by a monitoring point at any BFR and | block of N packets, with each packet being marked as X, is followed | |||
can be measured to calculate packet loss and/or packet delay metrics. | by the block of M packets with each packet being marked as Y. These | |||
It is expected that the marking values be set and cleared at the edge | blocks are unambiguously recognizable by a monitoring point at any | |||
of BIER domain. Thus for the scenario presented in Figure 2 if the | Bit Forwarding Router (BFR) and can be measured to calculate packet | |||
operator initially monitors A-C-G and A-B-D segments he may enable | loss and/or packet delay metrics. It is expected that the marking | |||
measurements on segments C-F and B-E at any time. | values be set and cleared at the edge of BIER domain. Thus for the | |||
scenario presented in Figure 2 if the operator initially monitors the | ||||
A-C-G and A-B-D segments he may enable measurements on segments C-F | ||||
and B-E at any time. | ||||
4.1. Single Mark Enabled Measurement | 4.1. Single-Marking Enabled Measurement | |||
As explained in the [RFC8321], marking can be applied to delineate | As explained in [RFC8321], marking can be applied to delineate blocks | |||
blocks of packets based either on the equal number of packets in a | of packets based either on the equal number of packets in a block or | |||
block or based on equal time interval. The latter method offers | based on the equal time interval. The latter method offers better | |||
better control as it allows better account for capabilities of | control as it allows a better account for capabilities of downstream | |||
downstream nodes to report statistics related to batches of packets | nodes to report statistics related to batches of packets and, at the | |||
and, at the same time, time resolution that affects defect detection | same time, time resolution that affects defect detection interval. | |||
interval. | ||||
If the Single Mark measurement used to measure packet loss, then the | If the Single-Marking measurement is used to measure packet loss, | |||
D flag MUST be set to zero on transmit and ignored by monitoring | then the D flag MUST be set to zero on transmit and ignored by the | |||
point. | monitoring point. | |||
The L flag is used to create alternate flows to measure the packet | The S flag is used to create sub-flows to measure the packet loss by | |||
loss by switching the value of the L flag every N-th packet or at | switching the value of the S flag every N-th packet or at certain | |||
certain time intervals. Delay metrics MAY be calculated with the | time intervals. Delay metrics MAY be calculated with the sub-flow | |||
alternate flow using any of the following methods: | using any of the following methods: | |||
o First/Last Packet Delay calculation: whenever the marking, i.e. | o First/Last Packet Delay calculation: whenever the marking, i.e., | |||
value of L flag changes, a BFR can store the timestamp of the | the value of S flag changes, a BFR can store the timestamp of the | |||
first/last packet of the block. The timestamp can be compared | first/last packet of the block. The timestamp can be compared | |||
with the timestamp of the packet that arrived in the same order | with the timestamp of the packet that arrived in the same order | |||
through a monitoring point at downstream BFR to compute packet | through a monitoring point at a downstream BFR to compute packet | |||
delay. Because timestamps collected based on order of arrival | delay. Because timestamps collected based on the order of arrival | |||
this method is sensitive to packet loss and re-ordering of packets | this method is sensitive to packet loss and re-ordering of packets | |||
(see Section 4.3 for more details). | ||||
o Average Packet Delay calculation: an average delay is calculated | o Average Packet Delay calculation: an average delay is calculated | |||
by considering the average arrival time of the packets within a | by considering the average arrival time of the packets within a | |||
single block. A BFR may collect timestamps for each packet | single block. A BFR may collect timestamps for each packet | |||
received within a single block. Average of the timestamp is the | received within a single block. Average of the timestamp is the | |||
sum of all the timestamps divided by the total number of packets | sum of all the timestamps divided by the total number of packets | |||
received. Then the difference between averages calculated at two | received. Then the difference between the average packet arrival | |||
monitoring points is the average packet delay on that segment. | time calculated for the downstream monitoring point and the same | |||
metric but calculated at the upstream monitoring point is the | ||||
average packet delay on the segment between these two points. | ||||
This method is robust to out of order packets and also to packet | This method is robust to out of order packets and also to packet | |||
loss (only a small error is introduced). This method only | loss on the segment between the measurement points (packet loss | |||
provides a single metric for the duration of the block and it | may cause a minor loss of accuracy in the calculated metric | |||
doesn't give the minimum and maximum delay values. This | because the number of packets used is different at each | |||
limitation could be overcome by reducing the duration of the block | measurement point). This method only provides a single metric for | |||
by means of a highly optimized implementation of the method. | the duration of the block, and it doesn't give the minimum and | |||
maximum delay values. This limitation of producing only the | ||||
single metric could be overcome by reducing the duration of the | ||||
block. As a result, the calculated value of the average delay | ||||
will better reflect the minimum and maximum delay values of the | ||||
block's duration time. | ||||
4.2. Double Mark Enabled Measurement | 4.2. Double-Marking Enabled Measurement | |||
Double Mark method allows measurement of minimum and maximum delays | Double-Marking method allows measurement of minimum and maximum | |||
for the monitored flow but it requires more nodal and network | delays for the monitored flow, but it requires more nodal and network | |||
resources. If the Double Mark method used, then the L flag MUST be | resources. If the Double-Marking method used, then the S flag is | |||
used to create the alternate flow, i.e. mark larger batches of | used to create the sub-flow, i.e., mark blocks of packets. The D | |||
packets. The D flag MUST be used to mark single packets to measure | flag is used to mark single packets within a block to measure delay | |||
delay jitter. | and jitter. | |||
The first marking (L flag alternation) is needed for packet loss and | The first marking (S flag alternation) is needed for packet loss and | |||
also for average delay measurement. The second marking (D flag is | also for average delay measurement. The second marking (D flag is | |||
put to one) creates a new set of marked packets that are fully | put to one) creates a new set of marked packets that are fully | |||
identified over the BIER network, so that a BFR can store the | identified over the BIER network, so that a BFR can store the | |||
timestamps of these packets; these timestamps can be compared with | timestamps of these packets; these timestamps can be compared with | |||
the timestamps of the same packets on a second BFR to compute packet | the timestamps of the same packets on a second BFR to compute packet | |||
delay values for each packet. The number of measurements can be | delay values for each packet. The number of measurements can be | |||
easily increased by changing the frequency of the second marking. | easily increased by changing the frequency of the second marking. On | |||
But the frequency of the second marking must be not too high in order | the other hand, the higher frequency of the second marking will cause | |||
to avoid out of order issues. This method is useful to measure not | a higher volume of the measurement data being transported through the | |||
only the average delay but also the minimum and maximum delay values | BIER domain. An operator should consider and balance both effects. | |||
and, in wider terms, to know more about the statistic distribution of | This method is useful to measure not only the average delay but also | |||
delay values. | the minimum and maximum delay values and, in wider terms, to know | |||
more about the statistic distribution of delay values. | ||||
4.3. Operational Considerations | ||||
For the ease of operational procedures, the initial marking of a | ||||
multicast flow is performed at BFIR. and cleared, by way of removing | ||||
BIER encapsulation form a payload packet, at the edge of the BIER | ||||
domain by BFERs. | ||||
Since at the time of writing this specification, there are no | ||||
proposals to using auto-discovery or signaling mechanism to inform | ||||
downstream nodes what methodology is used each monitoring point MUST | ||||
be configured beforehand. | ||||
Section 4.3 [RFC8321] provides a detailed analysis of how packet re- | ||||
ordering and the duration of the block in the Single-Marking mode of | ||||
the marking method impact the accuracy of the packet loss | ||||
measurement. Re-ordering of packets in the Single-Marking mode will | ||||
be noticeable only at the edge of a block of packets (re-ordering | ||||
within the block cannot be detected in the Single-Marking mode). If | ||||
the extra delay for some packets is much smaller than half of the | ||||
duration of a block, then it should be easier to attribute re-ordered | ||||
packets to the proper block and thus maintain the accuracy of the | ||||
packet loss measurement. | ||||
5. IANA Considerations | 5. IANA Considerations | |||
This document requests IANA to register format of the OAM field of | This document requests IANA to register format of the OAM field of | |||
BIER Header as the following: | BIER Header as the following: | |||
+--------------+---------+--------------------------+---------------+ | +--------------+---------+-----------------+---------------+ | |||
| Bit Position | Marking | Description | Reference | | | Bit Position | Marking | Description | Reference | | |||
+--------------+---------+--------------------------+---------------+ | +--------------+---------+-----------------+---------------+ | |||
| 0 | S | Single Mark Measurement | This document | | | 0 | S | Single-Marking | This document | | |||
| 1 | D | Double Mark Measurement | This document | | | 1 | D | Double-Marking | This document | | |||
+--------------+---------+--------------------------+---------------+ | +--------------+---------+-----------------+---------------+ | |||
Table 1: OAM field of BIER Header | Table 1: OAM field of BIER Header | |||
6. Security Considerations | 6. Security Considerations | |||
This document list the OAM requirement for BIER-enabled domain and | Regarding using the marking method, [RFC8321] stressed two types of | |||
does not raise any security concerns or issues in addition to ones | security concerns. First, the potential harm caused by the | |||
common to networking. | measurements, is a lesser threat as [RFC8296] defines OAM field used | |||
by the marking method so that the value of "two bits have no effect | ||||
on the path taken by a BIER packet and have no effect on the quality | ||||
of service applied to a BIER packet." Second security concern, | ||||
potential harm to the measurements can be mitigated by using policy, | ||||
suggested in [RFC8296], to accept BIER packets only from trusted | ||||
routers, not from customer-facing interfaces. | ||||
All the security considerations for BIER discussed in [RFC8296] are | ||||
inherited by this document. | ||||
7. Acknowledgement | 7. Acknowledgement | |||
TBD | TBD | |||
8. References | 8. References | |||
8.1. Normative References | 8.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 | |||
skipping to change at page 7, line 5 ¶ | skipping to change at page 8, line 5 ¶ | |||
[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>. | |||
[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>. | ||||
8.2. Informative References | 8.2. Informative References | |||
[I-D.ietf-bier-oam-requirements] | ||||
Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., | ||||
Aldrin, S., Zheng, L., Chen, M., Akiya, N., and S. | ||||
Pallagatti, "Operations, Administration and Maintenance | ||||
(OAM) Requirements for Bit Index Explicit Replication | ||||
(BIER) Layer", draft-ietf-bier-oam-requirements-07 (work | ||||
in progress), February 2019. | ||||
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with | [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with | |||
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, | Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, | |||
May 2016, <https://www.rfc-editor.org/info/rfc7799>. | May 2016, <https://www.rfc-editor.org/info/rfc7799>. | |||
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., | [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., | |||
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index | Przygienda, T., and S. Aldrin, "Multicast Using Bit Index | |||
Explicit Replication (BIER)", RFC 8279, | Explicit Replication (BIER)", RFC 8279, | |||
DOI 10.17487/RFC8279, November 2017, | DOI 10.17487/RFC8279, November 2017, | |||
<https://www.rfc-editor.org/info/rfc8279>. | <https://www.rfc-editor.org/info/rfc8279>. | |||
[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 | |||
Lianshu Zheng | Lianshu Zheng | |||
Huawei Technologies | Huawei Technologies | |||
skipping to change at page 7, line 39 ¶ | skipping to change at page 9, line 4 ¶ | |||
Lianshu Zheng | Lianshu Zheng | |||
Huawei Technologies | Huawei Technologies | |||
Email: vero.zheng@huawei.com | Email: vero.zheng@huawei.com | |||
Mach Chen | Mach Chen | |||
Huawei Technologies | Huawei Technologies | |||
Email: mach.chen@huawei.com | Email: mach.chen@huawei.com | |||
Giuseppe Fioccola | Giuseppe Fioccola | |||
Telecom Italia | Huawei Technologies | |||
Email: giuseppe.fioccola@telecomitalia.it | Email: giuseppe.fioccola@huawei.com | |||
End of changes. 44 change blocks. | ||||
118 lines changed or deleted | 166 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/ |