Re: [ippm] draft-ietf-ippm-connectivity-monitoring-02.txt and draft-mirsky-ippm-epm

[[e-mail]]

Hi Greg,

Yes, it is intended by the definition of the metric that an alarm and some suitable state maintenance may be linked to the metric. Alarm and state management are not part of the specification.

A draft definition of the metric is on the slides for IETF 111. The definition suggested is easy to measure and comprehensible. Timing aspects are mentioned too, as the reaction speed is linked to measurement loop delays. I for now prefer a comprehensive metric definition to one which allows for fast detection. The latter is possible, but requires more thought. The measurement loop delay will impact any metric definition, however.  To compare with BFD: there 3 consecutive packets dropped along one measurement loop indicate loss of connectivity. In the draft, one packet lost along each of three measurement loops indicate loss of connectivity. I don’t claim that timing aspects may compete with BFD (I’m not a BFD expert anyway).

Regards,

Rüdiger

Von: [e-mail] <[e-mail]>
Gesendet: Sonntag, 25. Juli 2021 04:34
An: Geib, Rüdiger <[e-mail]>
Cc: [e-mail]; [e-mail]
Betreff: Re:draft-ietf-ippm-connectivity-monitoring-02.txt and draft-mirsky-ippm-epm


Hi Ruediger,

I much appreciate you sharing your thoughts on draft-mirsky-ippm-epm. I will be taking your suggestions and questions to work on. In the meantime, I have a question about the interpretation of the terms "connectivity" and "loss of connectivity" in draft-ietf-ippm-connectivity-monitoring. In the Introduction, it is noted that:

a packet not reaching a destination indicates a loss of connectivity

Should a reader assume that that the connectivity is restored when a packet reaches the destination? What if that is the very next packet? And then, that process of lost/received packets continues. OSS/BSS I am familiar with detecting the network failure, and thus entering the Loss of Connectivity (or Continuity) state triggers an Alarm. And when the state is cleared, i.e., the continuity of the monitored path is restored according to FM OAM protocol, the Alarm is cleared. Should we assume that the same operational procedure can be applied to a system based on draft-ietf-ippm-connectivity-monitoring?



Regards,

Greg Mirsky



Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division


[cid:image001.gif@01D781F8.F73272B0]
[cid:image002.gif@01D781F8.F73272B0]
E: [e-mail]<mailto:[e-mail]>
www.zte.com.cn<http://www.zte.com.cn/>
Original Mail
Sender: [e-mail]<mailto:[e-mail]>
To: gregory mirsky10211915;
CC: [e-mail];[e-mail]<mailto:[e-mail];[e-mail]>;
Date: 2021/07/14 01:28
Subject: draft-ietf-ippm-connectivity-monitoring-02.txt and draft-mirsky-ippm-epm
Hi Greg,

I've read draft-mirsky-ippm-epm and I don't object to proposals transferring existing standards and definitions of other SDOs to the Internet, if organized well and in consensus. Monitoring availability of a physical connection or some other resource which is either UP or DOWN is simple, and then also Connectivity,  Severely Errored Seconds or Availability respectively can be defined easily. Once we move from links to routes between nodes, like sub-paths or terminals connected by e.g. TCP transport, these metrics and lightweight and useful ways to measure them require careful thought.

To go to detail: the metrics proposed by draft-ietf-ippm-connectivity can be used to determine Severely Errored Seconds, meaning high packet drop ratios. Especially a single random packet loss (without congestion or a behaviour lasting long enough to cause queuing or a drop of a second packet passing the same sub-path) can't be assigned to a particular monitored sub-path. In that case, it's unclear which of the sub-paths monitored has created the Errored Second. On the other hand, draft-ietf-ippm-connectivity allows to detect congestion without applying packet loss as the criterium. To me, that's a relevant point, if metrics are to characterize network behaviour above transmission layer. Added latency caused by a queue or counting ECN marks serve to indicate congestion faster and more reliable, than loss based metrics. Congestion aware transport usually limits loss to low single digit percentages under congestion, maybe even less. Reliably deciding on an Errored Second by a loss based metric under congestion requires creation and capturing of a high number of successfully exchanged packets to detect a low packet loss ratio during an evaluation interval.

While the metrics (or parameters) of ITU-T are quite comprehensible, capturing them at layers 2 and above may cause some effort (I think to understand, that the approach chosen by draft-mirsky-ippm-epm prefers a connection oriented network design).

Regards,

Rüdiger


-----Ursprüngliche Nachricht-----
Von: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Gesendet: Mittwoch, 14. Juli 2021 04:44
An: Geib, Rüdiger <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Betreff: Re:AW: Fw:[ippm] I-D Action: draft-ietf-ippm-connectivity-monitoring-02.txt

Hi Rudiger,
thank you for explaining the goal of this work in great detail; much appreciated. It could be that there's some similarity between the purpose of this draft and what we're trying to quantify in https://datatracker.ietf.org/doc/draft-mirsky-ippm-epm/. The availability/unavailability metric, defined for the constant-rate media, is applied to the packet-switched network in that draft.
I agree with you that there's a need for a single metric that combines performance metrics measured for the particular path with the Loss of the Path Continuity state. I think that, as services set forth different QoS requirements (Service Level Objectives), such SLOs play a significant role in determining the resulting metric.
I greatly appreciate it if you can share your thoughts and comments on the approach in general and the proposed measurement method discussed in Error Performance Measurement draft.

Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: [e-mail]<mailto:[e-mail]>
www.zte.com.cn<http://www.zte.com.cn>
------------------Original Mail------------------
Sender: [e-mail]<mailto:[e-mail]>
To: gregory mirsky10211915;
CC: [e-mail];[e-mail]<mailto:[e-mail];[e-mail]>;
Date: 2021/07/12 23:19
Subject: AW: Fw:[ippm] I-D Action: draft-ietf-ippm-connectivity-monitoring-02.txt
Hi Greg,
Thanks. I'm open to terminology changes. I'll use connectivity for now and I mean ability to forward packets from A to B. My thoughts so far (well written text needs to be added)
- find a metric, which is deterministic in expressing no forwarding / no connectivity
- for an interface connecting A and B, that's simple if Adj-SIDs are applied: packets are dropped.
- in most core nets, a path will be re-routed. Delay often changes, but there are cases, when one can't rely on that. So I stopped working on a delay based connectivity metric.
- Using Node-SIDs with a loss based metric is an option too - Adj-SIDs are the better choice if links connecting neighbors are monitored (text will have to express that).
- Defining loss of connectivity I'll end up with something similar to routing/BFD but here 3 different measurement loops indicate loss (in the end, 3 dropped packets within one evaluation interval, are the minimum criterium, that's the similarity, but here meaning one of each measurement loop).
- To continue that analogy, regarding timing issues: if each measurement loop forwards one packet every 60 ms, 6 measurement loops send one packet each within 50 ms. That's the worst case temporal distance which two or three of the measurement loops are apart. Then that determines speed of decision (at the sender....measurement loop delays can be different, depending on the kind of sub-path monitored and that may have an impact).
I've added more statements than you've asked for, just to indicate that there's a concept for the missing metrics. I didn't have time to work out good text, as I figured out how to proceed within the last days only.
Regards,
Rüdiger
-----Ursprüngliche Nachricht-----
Von: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Gesendet: Dienstag, 13. Juli 2021 04:50
An: Geib, Rüdiger <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Betreff: Fw:[ippm] I-D Action: draft-ietf-ippm-connectivity-monitoring-02.txt
Hi Rudiger,
thank you for the extensive and beneficial updates to the document.
I have a question about the use of the term "connectivity" in the draft. As I understand, as you've referenced earlier IETF document RFC 2678, "connectivity" is interpreted as an ability to transport a packet from one system to another. I agree that interpretation is often used in IETF documents. At the same time, in the field of fault management OAM, e.g., Ethernet CFM, we know of two mechanisms - Continuity Check (CC) and Connectivity Verification (CV). To illustrate the difference between them, I'll use the analogy of electrical wires. Then, CC verifies that a wire that connects circuits A and B exists and is operational. CV function is similar, but it verifies that if nodes are connected by red, blue, and orange wires, the red circuit receives electric current only from the red wire. If that is not the case and that state persists over a pre-defined number of consecutive checks, the state of misconnection is determined, and, usually, an alarm is raised.
As it appears to me, the term "connectivity" in the draft is not used in the same context as in the FM OAM. I think we can find a better term to characterize the metric discussed in the document.
Regards,
Greg Mirsky
Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部  Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division
E: [e-mail]<mailto:[e-mail]>
www.zte.com.cn<http://www.zte.com.cn>
------------------Original Mail------------------
Sender: [e-mail]<mailto:[e-mail]>
To: [e-mail]<mailto:[e-mail]> ;
CC: [e-mail]<mailto:[e-mail]>;
Date: 2021/07/12 07:47
Subject: [ippm] I-D Action: draft-ietf-ippm-connectivity-monitoring-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Performance Measurement WG of the IETF.
Title           : A Connectivity Monitoring Metric for IPPM
Author          : Ruediger Geib
Filename        : draft-ietf-ippm-connectivity-monitoring-02.txt
Pages           : 25
Date            : 2021-07-12
Abstract:
Within a Segment Routing domain, segment routed measurement packets can be sent along pre-determined paths.  This enables new kinds of measurements.  Connectivity monitoring allows to supervise the state and performance of a connection or a (sub)path from one or a few central monitoring systems.  This document specifies a suitable type-P connectivity monitoring metric.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ippm-connectivity-monitoring/
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-connectivity-monitoring-02
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-connectivity-monitoring-02
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
ippm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ippm