Subject: [OPSAWG] Comments on draft-ietf-opsawg-service-assurance-yang-02

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 7 Mar 2022 21:59:20 +0000

I've been refreshing myself on the SAIN work, and jumped into this draft before the architecture.  I have two comments as I read this.

First, what is the purpose of assurance-graph-version?  It's a 32-bit counter that can increment when something goes in and out of maintenance (+2).  I can easily see this wrapping fir services with a lot of churn.  What is the impact of that?  Is this version number required if we have a last modified timestamp?

Second, is it intended that health-score-weight of all symptoms' health score weights for a given subservice add to 100?  If so, that is not clearly stated.  I guess I'm wondering what this might look like in practice if I have a degraded subservice with health 50 and two symptoms of weight 10 and 20 respectively.  Obviously, I would look at weight 20 first, but I might then wonder if something unseen is also affecting my subservice.

Joe

---

From: Jean Quilbeuf <[email-masked]>
Date: Wed, 9 Mar 2022 16:12:35 +0000

Hi Joe,
Thanks for your comments.

> First, what is the purpose of assurance-graph-version?  It's a 32-bit counter that can increment when something goes in and out of maintenance (+2).  I can easily see this wrapping fir services wit…

The purpose of assurance-graph-version is to enable  a consumer of this module to quickly check if they have the last version. It probably makes sense to use a larger counter. I'll modify it.

> Second, is it intended that health-score-weight of all symptoms' health score weights for a given subservice add to 100?  If so, that is not clearly stated.  I guess I'm wondering what this might l…

For now,  the relation between symptoms weights (health-score-weight) and health score is that a health score that is not optimal must be explained by at least one symptom with a weight greater than 0. 
It's also stated that the weight of the symptom is the impact incurred on the health score when the symptom is present, without précising what "incurred" means. 

To state think more clearly, we could define the health score as a function of the symptom weights, for instance health-score = max(0, 100 - sum(symptoms/health-score-weight)), but I am not sure that such a function is generic enough to be part of the draft.

The advantage of the current version is that we state that there is a relationship between the symptoms weights and the subservice health score, but we don't enforce the exact relation. We can also sort the symptoms by weight to know the most impacting one.

What do you think about adding the example above and stating that the relationship between the symptoms weights and the final health score is left to the implementation of the agent? Would that make things clearer?

Thanks,
Jean

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 24 Mar 2022 10:48:41 +0000

> The purpose of assurance-graph-version is to enable  a consumer of this module to quickly check if they have the last version. It probably makes sense to use a larger counter. I'll modify it.

How does it do that.  If I get a version of 324523457273456, how do I
know that's the latest?  It seems to me the date is as useful as that
number.  I still don't _know_ I have the latest version, but I can be
more confident if I have one from a couple of seconds ago, it's recent.

> To state think more clearly, we could define the health score as a function of the symptom weights, for instance health-score = max(0, 100 - sum(symptoms/health-score-weight)), but I am not sure th…

Understood.  Though this might make could implementor considerations as
potential ways to do this.

> What do you think about adding the example above and stating that the relationship between the symptoms weights and the final health score is left to the implementation of the agent? Would that mak…

Yes.  Offering some insight into how to best implement and then make use
of this would be much appreciated.

Joe

---

From: Benoit Claise <[email-masked]>
Date: Thu, 24 Mar 2022 13:20:57 +0100

Hi Joe,

On 3/24/2022 11:48 AM, Joe Clarke (jclarke) wrote:
> know that's the latest?
MdT on-change.

> It seems to me the date is as useful as that
Regards, Benoit

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 24 Mar 2022 12:42:20 +0000

>> How does it do that.  If I get a version of 324523457273456, how do I

Fair.  But then, as a consumer, I know it's the latest because it's the
update I just got.  And still, the date will be more useful...

I know I'm being difficult and bike-sheddy.  It doesn't really bother
me.  Just trying to make sure there's true use for it.

Joe

---

From: Jean Quilbeuf <[email-masked]>
Date: Fri, 25 Mar 2022 10:48:31 +0000

Hi Joe,

I updated the draft with some more details about the relation between healt-score and health-score-weight.

I left the counter so far, but changed it to 64 bits.

Best,
Jean

> -----Original Message-----
> From: Joe Clarke (jclarke) [mailto:[email-masked]]
> Sent: Thursday 24 March 2022 12:42
> To: Benoit Claise <benoit.claise=[email-masked]>; Jean
> Quilbeuf <[email-masked]>; [email-masked]
> Subject: Re: [OPSAWG] Comments on draft-ietf-opsawg-service-assurance-
> yang-02
> 
> >>>> First, what is the purpose of assurance-graph-version?  It's a 32-bit
> counter that can increment when something goes in and out of maintenance
> (+2).  I can easily see this wrapping fir services with a lot of churn.  What is the
> impact of that?  Is this version number required if we have a last modified
> timestamp?
> >>> The purpose of assurance-graph-version is to enable  a consumer of this
> module to quickly check if they have the last version. It probably makes
> sense to use a larger counter. I'll modify it.
> Fair.  But then, as a consumer, I know it's the latest because it's the update I
> just got.  And still, the date will be more useful...
> 
> I know I'm being difficult and bike-sheddy.  It doesn't really bother me.  Just
> trying to make sure there's true use for it.
> 
> Joe
>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 25 Mar 2022 11:57:08 +0100

Dear OPSAWG chairs,

As discussed during the WG session, the authors believe the two 
draft-ietf-opsawg-service-assurance drafts are ready for WGLC.

Regards, Benoit

On 3/25/2022 11:48 AM, Jean Quilbeuf wrote:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
> .

---

From: tom petch <[email-masked]>
Date: Mon, 28 Mar 2022 09:58:48 +0000

From: OPSAWG <[email-masked]> on behalf of Benoit Claise <benoit.claise=[email-masked]>
Sent: 25 March 2022 10:57

Dear OPSAWG chairs,

<tp>

May be.

This is the first module I can recall where the prefix is longer than any of the identifiers that are prefixed.  'service-assurance-interface:' does not make for an easy read IMHO.

Several places have an unfinished look.
- RFC xxxx: Title to be completed
- TO DO - Better type ...
- TLP ood
- YANG import no reference clause
-  line length in excess of 100 characters
- NMDA not mentioned
- string with no indication of acceptable characters sometimes attracts a DISCUSS
- mailto:[email-masked]

Tom Petch

Regards, Benoit

---

From: <[email-masked]>
Date: Mon, 28 Mar 2022 13:24:20 +0000

Hi all, 

In addition to the list provided by Tom, here is some additional items to be fixed. Most are easy-to-fix:

* s/This document proposes/This document specifies
* I'm still not sure why this is restricted to "Intent-based Networking Architecture" in the abstract.
* Move Section I to be positioned right after Section II
* fix the validation errors
* run "pyang -f yang --yang-canonical"
* run "pyang -f tree --tree-line-length 69" for generating the trees. 
* registered prefixes do not match the ones in the modules. 
* remove <CODE BEGINS> and <CODE ENDS> from the examples. 
* not sure what is the rationale for having only one address per device, two devices, why not a name is used to identify a device, etc. (Section 8.1). It seems this about unicast connectivity, and not cover multicast.
* Why only IS-IS is covered?

I'm not sure this version is ready for WGLC, though. 

Cheers,
Med

> -----Message d'origine-----
> De : OPSAWG <[email-masked]> De la part de tom petch
> Envoyé : lundi 28 mars 2022 11:59
> À : Benoit Claise <benoit.claise=[email-masked]>; Jean
> Quilbeuf <jean.quilbeuf=[email-masked]>; Joe Clarke
> (jclarke) <[email-masked]>; [email-masked]
> Objet : Re: [OPSAWG] Comments on draft-ietf-opsawg-service-assurance-
> yang-02
> 
> From: OPSAWG <[email-masked]> on behalf of Benoit Claise
> <benoit.claise=[email-masked]>
> As discussed during the WG session, the authors believe the two draft-
> ietf-opsawg-service-assurance drafts are ready for WGLC.
> 
> <tp>
> 
> May be.
> 
> This is the first module I can recall where the prefix is longer than
> any of the identifiers that are prefixed.  'service-assurance-
> interface:' does not make for an easy read IMHO.
> 
> >> counter that can increment when something goes in and out of
> >> maintenance (+2).  I can easily see this wrapping fir services with a
> >> lot of churn.  What is the impact of that?  Is this version number
> >> required if we have a last modified timestamp?
> >> module to quickly check if they have the last version. It probably
> >> makes sense to use a larger counter. I'll modify it.
> >>>> How does it do that.  If I get a version of 324523457273456, how do
> >>>> I know that's the latest?
> >>> MdT on-change.
> >> Fair.  But then, as a consumer, I know it's the latest because it's
> >> the update I just got.  And still, the date will be more useful...
> >>

_________________________________________________________________________________________________________________________

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: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 28 Mar 2022 13:49:58 +0000

Sometimes the threat of WG LC is enough to get some comments :-). 
Thanks, Med and Tom for doing this.

Joe

---

From: tom petch <[email-masked]>
Date: Mon, 28 Mar 2022 15:45:32 +0000

Joe

My post generated an automatic reply from the e-mail address that you are using but with no content; I was expecting 'I am out of the office ...' but no, nothing,

Tom Petch

________________________________________
From: Joe Clarke (jclarke) <[email-masked]>
Sent: 28 March 2022 14:49
To: [email-masked]; tom petch; Benoit Claise; Jean Quilbeuf; [email-masked]
Subject: Re: [OPSAWG] Comments on draft-ietf-opsawg-service-assurance-yang-02

Joe

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 28 Mar 2022 15:59:08 +0000

You're not the first to tell me that (Warren was).  I'd like to say I
have some control over Exchange, but I did everything "right".  Still,
thanks for the second report.  I'll see if I can fix that for future OOO
stints.

Joe