Subject: Re: [OPSAWG] 🔔 WG Adoption Call for draft-claise-opsawg-service-assurance-architecture-05

From: <[email-masked]>
Date: Sun, 2 May 2021 06:10:35 +0000

Dear OPSAWG wg,

I support the adoption of draft-claise-opsawg-service-assurance-architecture and draft-claise-opsawg-service-assurance-yang.

From a network operators point of view I see these two drafts as an important contribution towards closed-loop automation. Enabling service decomposition which is much needed for service assurance with Network Telemetry.

Best wishes
Thomas

-----Original Message-----
From: OPSAWG <[email-masked]> On Behalf Of Henk Birkholz
Sent: Tuesday, April 27, 2021 8:00 PM
To: opsawg <[email-masked]>
Subject: [OPSAWG] 🔔 WG Adoption Call for draft-claise-opsawg-service-assurance-architecture-05

Dear OPSAWG members,

this starts a call for Working Group Adoption for

> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-claise-opsawg-service-assurance-
> architecture-05&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C12365b
> fbdaca46b6936208d909a6712a%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%
> 7C637551432726202431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Ortrw5RGQZ0
> X3XPy3v3uqs8xDbkqHoI%2BnIcLJaMOkaA%3D&amp;reserved=0

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
[email-masked]
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg&amp;data=04%7C01%7CThomas.Graf%40swisscom.com%7C12365bfbdaca46b6936208d909a6712a%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637551432726202431%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6gyWluhh8miNoGpPzLAY%2BcmIqNh0qayLwFPwcQODRao%3D&amp;reserved=0

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 3 May 2021 12:51:14 +0000

As a contributor, I support this work.  This work is useful outside of
the "IBN" space in expressing how one can understand the inter-relations
of services and more intelligently monitor them. 

Joe

On 4/27/21 14:01, Henk Birkholz wrote:
>> https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-architecture-05
> 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.
>
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 4 May 2021 17:59:40 -0700

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?
   - 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?
   - 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.

Regards,
Greg

---

From: Giuseppe Fioccola <[email-masked]>
Date: Thu, 6 May 2021 14:08:05 +0000

Dear All,
I support its adoption as relevant document for the closed loop automation.

Regards,

Giuseppe

-----Original Message-----
From: OPSAWG [mailto:[email-masked]] On Behalf Of Henk Birkholz
Sent: Tuesday, April 27, 2021 8:00 PM
To: opsawg <[email-masked]>
Subject: [OPSAWG] 🔔 WG Adoption Call for draft-claise-opsawg-service-assurance-architecture-05

Dear OPSAWG members,

Henk

---

From: Benoit Claise <[email-masked]>
Date: Fri, 7 May 2021 18:56:10 +0200

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.
>   * 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:
>     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.
>     <https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-architecture-05>
>     > Please reply with your support and especially any substantive
>     comments
>     > you may have.
>     >
>     >
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/opsawg>
>     >
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/opsawg>
>
>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 10 May 2021 11:17:35 +0200

Hi Ma,

Thanks for reading and supporting the draft.
You're right that the figure 2 is a little bit simplistic. We will 
improve it to represent a DAG.

Regards, Benoit

On 4/29/2021 2:43 PM, maqiufang (A) wrote:
> Hi, all
> I support the adoption of this draft.
>
> Needless to say, real-time monitoring and making sure that the network indeed complies with the desired service intent is the key to IBN.
>
> I have just one comment: the assurance graph for the tunnel service depicted in Fig.2 looks more like a tree structure(undirected graph),rather than a DAG.
> Authors,  could you please show the dependency relations in that graph?
>
> Best Regards,
> Qiufang Ma
>
> Sent: Wednesday, April 28, 2021 2:00 AM

---

From: "Thangam Arumugam (tarumuga)" <[email-masked]>
Date: Fri, 14 May 2021 16:41:21 +0000

I support the adoption of this document by the OPSAWG. As a co-author, I am committed to working more on this document with the co-authors and the WG reviews

-----Original Message-----
From: Henk Birkholz <[email-masked]> 
Sent: Tuesday, April 27, 2021 11:00 AM
To: opsawg <[email-masked]>
Subject: [OPSAWG] 🔔 WG Adoption Call for draft-claise-opsawg-service-assurance-architecture-05

Henk

---

From: "Thangam Arumugam (tarumuga)" <[email-masked]>
Date: Fri, 14 May 2021 17:36:21 +0000

Regards,
Thangavelu

-----Original Message-----
From: Henk Birkholz <[email-masked]> 
Sent: Tuesday, April 27, 2021 11:00 AM
To: opsawg <[email-masked]>
Subject: [OPSAWG] 🔔 WG Adoption Call for draft-claise-opsawg-service-assurance-architecture-05

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 19 May 2021 20:59:55 +0200

Dear OPSAWG members,

this email concludes the call for Working Group Adoption on 
https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-assurance-architecture-05.

We received a large number of positive replies, no objections, and 
various significant comments.

The chairs believe this I-D is ready for adoption and for the working 
group to work on.

Authors, please rename the I-D to 
draft-ietf-opsawg-service-assurance-architecture-00, keeping the content 
as is, and resubmit.

Additionally, please continue to discuss the scope of this document and 
its relationship to IBN as well as other topics in an open discussion on 
the list. As highlighted by the comments, service assurance and closed 
loop automation can be in support of various network-related 
requirements. Scoping decisions to that regard will have an impact on 
the shape of this document.

Henk

---

From: Benoit Claise <[email-masked]>
Date: Fri, 21 May 2021 18:09:48 +0200

Thanks Henk.

Done.

Regards, Benoit
On 5/19/2021 8:59 PM, Henk Birkholz wrote:
> draft-ietf-opsawg-service-assurance-architecture-00, keeping the 
> content as is, and resubmit.
>
> Additionally, please continue to discuss the scope of this document 
> and its relationship to IBN as well as other topics in an open 
> discussion on the list. As highlighted by the comments, service 
> assurance and closed loop automation can be in support of various 
> network-related requirements. Scoping decisions to that regard will 
> have an impact on the shape of this document.
>
>
>> 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.
>>
>> comments you may have.
> .