< draft-mirsky-ippm-hybrid-two-step-03.txt   draft-mirsky-ippm-hybrid-two-step-04.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 11, 2019 G. Zhui Expires: April 10, 2020 G. Zhui
ZTE Corporation ZTE Corporation
April 9, 2019 October 8, 2019
Hybrid Two-Step Performance Measurement Method Hybrid Two-Step Performance Measurement Method
draft-mirsky-ippm-hybrid-two-step-03 draft-mirsky-ippm-hybrid-two-step-04
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 39
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 11, 2019. This Internet-Draft will expire on April 10, 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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . 3
3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 3
4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
4.1. Operation of the HTS Ingress Node . . . . . . . . . . . . 5 4.1. Operation of the HTS Ingress Node . . . . . . . . . . . . 5
4.2. Operation of the HTS Transient Node . . . . . . . . . . . 7 4.2. Operation of the HTS Transient Node . . . . . . . . . . . 7
4.3. Operation of the HTS Egress Node . . . . . . . . . . . . 8 4.3. Operation of the HTS Egress Node . . . . . . . . . . . . 8
4.4. Considerations for HTS Timers . . . . . . . . . . . . . . 8 4.4. Considerations for HTS Timers . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4.5. Deploying HTS in a Multicast Network . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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,
skipping to change at page 8, line 35 skipping to change at page 8, line 35
telemetry information for processing and analysis to a local or telemetry information for processing and analysis to a local or
remote agent. remote agent.
4.4. Considerations for HTS Timers 4.4. Considerations for HTS Timers
This specification defines two timers - HTS Follow-up and HTS This specification defines two timers - HTS Follow-up and HTS
Collection. Because for the particular flow there MUST be not more Collection. Because for the particular flow there MUST be not more
than one HTS Trigger, values of HTS timers bounded by the rate of the than one HTS Trigger, values of HTS timers bounded by the rate of the
trigger generation for that flow. trigger generation for that flow.
4.5. Deploying HTS in a Multicast Network
Previous sections discussed the operation of HTS in a unicast
network. Multicast services are important, and the ability to
collect telemetry information is an invaluable component in
delivering a high quality of experience. While the replication of
data packets is necessary, replication of HTS follow-up packets is
not. Replication of multicast data packets down a multicast tree may
be set based on multicast routing information or explicit information
included in the special header, as, for example, in Bit-Indexed
Explicit Replication [RFC8296]. A replicating node processes HTS
packet as defined below:
o the first transmitted multicast packet MUST be followed by the
received corresponding HTS packet as described in Section 4.2;
o each consecutively transmitted copy of the original multicast
packet MUST be followed by the new HTS packet originated by the
replicating node that acts as a transient HTS node when the
Follow-up timer expired.
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,
all ingress/egress pairs traversed by the given multicast packet
reflected in their respective Telemetry Data TLV. Consequently, a
centralized controller would be able to reconstruct and analyze the
state of the particular multicast distribution tree based on HTS
packets collected from egress nodes.
5. IANA Considerations 5. IANA Considerations
TBD TBD
6. Security Considerations 6. Security Considerations
Nodes that practice HTS method are presumed to share a trust model Nodes that practice HTS method are presumed to share a trust model
that depends on the existence of a trusted relationship among nodes. that depends on the existence of a trusted relationship among nodes.
This is necessary as these nodes are expected to correctly modify the This is necessary as these nodes are expected to correctly modify the
specific content of the data in the follow-up packet, and the degree specific content of the data in the follow-up packet, and the degree
skipping to change at page 9, line 45 skipping to change at page 10, line 25
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., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
"Data Fields for In-situ OAM", draft-ietf-ippm-ioam- "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
data-05 (work in progress), March 2019. data-07 (work in progress), September 2019.
[P4.INT] "In-band Network Telemetry (INT)", P4.org Specification, [P4.INT] "In-band Network Telemetry (INT)", P4.org Specification,
October 2017. October 2017.
[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>.
[RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., [RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S.,
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.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>.
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
Beijing 100191 Beijing 100191
P.R.China P.R.China
Phone: +86 10 82963945 Phone: +86 10 82963945
Email: wang.lingqiang@zte.com.cn Email: wang.lingqiang@zte.com.cn
Guo Zhui Guo Zhui
 End of changes. 10 change blocks. 
11 lines changed or deleted 46 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/