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> 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> 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 >> https://www.ietf.org/mailman/listinfo/opsawg >> > > _______________________________________________ > OPSAWG mailing listOPSAWG@ietf.orghttps://www.ietf.org/mailman/listinfo/opsawg > > >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
