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

From: Henk Birkholz <[email-masked]>
Date: Tue, 27 Apr 2021 20:00:28 +0200

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

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

---

From: <[email-masked]>
Date: Wed, 28 Apr 2021 06:55:47 +0000

Hi all, 

I support adoption but I suggest to merge this document with I-D.claise-opsawg-service-assurance-yang. Also, I'm not sure SAIN is specific to IBN, though. 

It would be good to position this work in the context of the framework defined in RFC8969.

FWIW, some quick comments for the authors can be found at:

* pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-claise-opsawg-service-assurance-architecture-05-rev%20Med.pdf 
* doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-claise-opsawg-service-assurance-architecture-05-rev%20Med.docx 

Cheers,
Med

> -----Message d'origine-----
> De : OPSAWG [mailto:[email-masked]] De la part de Henk
> Birkholz
> Envoyé : mardi 27 avril 2021 20:00
> À : opsawg <[email-masked]>
> Objet : [OPSAWG] 🔔 WG Adoption Call for draft-claise-opsawg-service-
> assurance-architecture-05
> 
> Dear OPSAWG members,
> 
> > https://datatracker.ietf.org/doc/html/draft-claise-opsawg-service-
> assu
> > rance-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.
> 
> Please reply with your support and especially any substantive
> comments you may have.
> 
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 28 Apr 2021 09:29:47 +0200

Dear all,

As author, I obviously support the call for adoption for the two related 
drafts: draft-claise-opsawg-service-assurance-architecture-05 & 
draft-claise-opsawg-service-assurance-yang-07

I'm a strong believer that, in order to solve Intent-based 
Networking/Autonomous Driving Networking/Self-* Networks/you-name-it, we 
must first tackle the service assurance and closed loop automation 
issues, which can only be solved by dividing the service assurance into 
the assurance of smaller components, called a subservice in the drafts.

What I want to stress is that those two drafts are the result of:
     - many discussions with operators, which will hopefully show their 
support here,
     - some university research, with some opensource code (as presented 
at the last IETF)

Regards, Benoit

On 4/27/2021 8:00 PM, Henk Birkholz wrote:
> 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.
>
> .

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 29 Apr 2021 06:01:32 +0000

Without any hat, I support the adoption of this document by OPSAWG.

Having worked for 2 years on a very similar project/proof of concept, the architecture has been proven valid.

-éric

-----Original Message-----
From: OPSAWG <[email-masked]> on behalf of Henk Birkholz <[email-masked]>
Date: Tuesday, 27 April 2021 at 20:01
To: opsawg <[email-masked]>
Subject: [OPSAWG] 🔔 WG Adoption Call for draft-claise-opsawg-service-assurance-architecture-05

    Dear OPSAWG members,

    Henk

---

From: "maqiufang (A)" <[email-masked]>
Date: Thu, 29 Apr 2021 12:43:40 +0000

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

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

Dear OPSAWG members,

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.

Henk