Hi Greg,
Thanks for reading and supporting the draft.
See in-line.
On 5/5/2021 2:59 AM, Greg Mirsky wrote:
Dear All,
I've read the draft and support its adoption by the OPSAWG. The
proposed approach to service assurance is powerful and extensible.
I have several questions for the authors and appreciate their
consideration:
* Is the architecture intended to quantify service degradation?
Yes, exactly.
* A health score of 100 signifies a perfectly operational
sub-service according to the definition. If, for example, the
sub-service is an interface. how the "perfect operational level"
can be defined for packet drops?
Typical consulting engineer answer: it depends. :-)
It depends on the interface type, the type of packets, the protocol, and
higher applications.
You're right that sometimes it's difficult to quantify the effect on the
health score.
Note that it's important to report symptoms, even if you can't quantify
its effect
Example: you notice a change in the packet size distribution. This is an
important symptom to report but potentially doesn't affect the
subservice health, and as a consequence the service health
* Section 3.9 is stated:
The SAIN architecture requires the Network Time Protocol (NTP) ...
I agree that for the correlation of the information collected from
agents, clocks must be synchronized. And in fact, NTP is broadly
used to synchronized instances of the control and management
plane. But, on the other hand, other protocols are used, e.g.
IEEE-1588v2, a.k.a. PTP, to synchronize devices on the data plane.
It appears that it could be easier to indicate the format of a
timestamp used by the agent. Then the SAIN orchestrator can
convert timestamps as needed and correlate regardless of the clock
synchronization protocol and format used.
That's a very good point.
The requirement is for a synchronization protocol, not specifically NTP.
We will correct the language.
Regards,
Greg
On 4/27/21 14:01, Henk Birkholz wrote:
> Dear OPSAWG members,
>
> this starts a call for Working Group Adoption for
>
>>
https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-architecture-05
<https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-architecture-05>
> ending on Tuesday, May 18th.
>
> As a reminder, this I-D describes the health of an
interconnected system
> of network devices and (sub-)services located in that system. A
degraded
> health status is explained via symptom descriptions and the
resulting
> interconnected knowledge is aggregated in an assurance graph.
>
> Please reply with your support and especially any substantive
comments
> you may have.
>
>
> For the OPSAWG co-chairs,
>
> Henk
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org <mailto:OPSAWG@ietf.org>
> https://www.ietf.org/mailman/listinfo/opsawg
<https://www.ietf.org/mailman/listinfo/opsawg>
>
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org <mailto:OPSAWG@ietf.org>
https://www.ietf.org/mailman/listinfo/opsawg
<https://www.ietf.org/mailman/listinfo/opsawg>
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
