Hi Dhruv, Your comments have been taken into account in the last version: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-architecture-07
Thanks again Jean From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Dhruv Dhody Sent: Tuesday 28 June 2022 14:52 To: Benoit Claise <benoit.cla...@huawei.com> Cc: Tianran Zhou <zhoutianran=40huawei....@dmarc.ietf.org>; opsawg@ietf.org Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-architecture-03 Thanks Benoit for the clarifications. I would urge the authors to add some clarification text around these as they see fit. Thanks again for taking my comments into consideration. Regards, Dhruv On Tue, Jun 28, 2022 at 6:51 PM Benoit Claise <benoit.cla...@huawei.com<mailto:benoit.cla...@huawei.com>> wrote: Hi Dhruv, Thanks for your review. See inline On 6/26/2022 4:03 PM, Dhruv Dhody wrote: Hi WG, I think this work is very useful. I have some comments - Minor - We need a reference or some discussion of what we mean by "intent" before we jump into SAIN in the Introduction. We could reuse the definition from draft-irtf-nmrg-ibn-concepts-definitions Intent: A set of operational goals (that a network should meet) and outcomes (that a network is supposed to deliver), defined in a declarative manner without specifying how to achieve or implement them. - The statement "Such approaches are mainly suited for greenfield deployments" about intent is not clear to me. Is the intent-based approach (or SAIN) limited to new deployments? Maybe it is worth expanding on or providing a reference. We were trying to express that the brown field environments are move complex from a intent point of view (multi-vendors, different capabilities, different domains, silo organizations, etc.). I understand your confusion regarding this paragraph. We'll try to improve this paragraph. If still unclear, we propose to remove it. - It is not clear to me the various difference between the Expression graph, assurance graph, and computational graph. If the expression graph/computation is all about how the health score is to be calculated, why is that not in the YANG (which only talks of assurance graph)? Also, I don't understand the difference between subservice and service expressions! If the subservice has dependencies, does it become the same as the service expressions? The model YANG only has subservices BTW! Building the computational graph is an implementation choice. When discussing implementation, we thought this would be useful, even if it's out of scope of the draft. - Does SAIN orchestrator has any say in what metric to collect and how it impacts the health score? I understand in most cases it is to be analyzed from the configuration but at the same time can that not be influenced by the orchestrator? The subservice is an abstraction that should take care of the metric. Hence this is not the SAIN orchestrator job. However, the composition of the subservice health scores could be part of the SAIN orchestrator. However, this is an implementation choice. - Some examples of how the health score might be calculated as an integer between 0-100 would be nice in the example provided esp for a case where it is something in middle like "60". An interface down is 0 An interface losing packets is ... 50 or 40 or 60? basically, it depends on the service impact. So it's difficult to us to provide some guidance in this draft. Nits - Section 1, the closing parenthesis is missing -> (Section 3.3 of [RFC8969] - Expand on first use - L3VPN, dBM, - Add reference for kubernetes, Openconfig Thanks, Benoit Thanks! Dhruv On Wed, Jun 8, 2022 at 3:29 PM Tianran Zhou <zhoutianran=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>> wrote: Hi WG, This mail we start a two weeks working group last call for draft-ietf-opsawg-service-assurance-architecture-03. https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-architecture/ Please send over your comments before June 22. Please also indicate if you think this document is ready to progress. Cheers, Tianran, on behalf of chairs _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org<mailto:OPSAWG@ietf.org> https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org<mailto:OPSAWG@ietf.org> https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
