Hi Benoit, Please see inline.
Cheers, Med De : Benoit Claise <benoit.cla...@huawei.com> Envoyé : mardi 28 juin 2022 15:33 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; Jean Quilbeuf <jean.quilb...@huawei.com>; Tianran Zhou <zhoutianran=40huawei....@dmarc.ietf.org>; opsawg@ietf.org Objet : Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05 Hi Med, Thanks again. See inline for some points On 6/27/2022 10:44 AM, mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: Hi Jean, Thank you for the update and the replies. This version looks better. Please see below some pending comments on -06: * I don’t think that the “id” MUST be globally unique”, but only within a domain/network. I understand your logic. However, the YANG assurance graph between different domains can be connected... and we expect they will connected in the future (core, DC, etc..) [Med] Yes, I had that in mind as well. I assumed that some coordination will be in place so that SAIN agents generate non-conflicting ids even within a single network. Local uniqueness may be ensured by a variety of means (concatenate an id generated by a SAIN agent and its identity, timestamping, etc.). Therefore, it makes sense to have globally unique Ids [Med] If this is justified, I’m afraid that a mechanism to ensure such a uniqueness + the behavior when a conflict is detected should be called out. * Can you please update the description of the “description”/”label” as suggested in my previous review. It seems that you retrieved an older version of the review files. * You may want add some text to clarify how that version is useful/used. * I do still see some value in allowing assurance-graph-version to be rw. This can be, for example, used to force aligning the version among several servers that manipulate the same assurance graph. Another usage would be to revert or force an assurance graph version. Some change in the structure may be needed to manipulate a list of graphs for the same service indexed by their version. I have to push back on this one. We already have some issues regarding the source of truth in networking. By adding the ability to configure the assurance-graph-version, we're going to add to the complexity. What does it mean in terms of intent? [Med] What is authoritative is still the characterization in terms of subservices and dependencies. You may, for example, bump the version but the characterization is still the same so that all your controllers are in sync. If you configure an old assurance graph version, does it mean that you want to network to go back to this old version? [Med] Explicitly configuring an assurance graph can be a corrective action to a graph that was automatically generated. If we assume that explicitly configured graphs will take precedence, there are no implications on the service itself. If you configure an new assurance graph version, does it mean that you know better than the SAIN architecture and that you impose it? [Med] Yes. The SAIN orchestrator knowledge is (and will be) limited. * A server may manipulate multiple services, and thus multiple service assurance graphs are maintained. How these various graphs are identified/demuxed? Actually, a server maintains one graph, composed of all the service instances. [Med] Yes, I got that. My comment is that don’t see how we can retrieve the assurance graph of a specific service type (e.g., EVPN or L3VPN) using the current structure. Thanks. We explained this at the end of Section 3.1 By specifying service instances and their dependencies in terms of subservices, one defines a global assurance graph. That assurance graph is the result of merging all the individual assurance graphs for the assured service instances. Each subservice instance is expected to appear only one in the global assurance graph even if several service instances depend on it. For example, an instance of the device subservice is a dependency of every service instance that rely on the corresponding device. The assurance graph of a specific service instance is the subgraph obtained by traversing the global assurance graph through the dependencies starting from the specific service instance. Thanks and Regards, Benoit Cheers, Med De : Jean Quilbeuf <jean.quilb...@huawei.com><mailto:jean.quilb...@huawei.com> Envoyé : vendredi 24 juin 2022 20:56 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com><mailto:mohamed.boucad...@orange.com>; Tianran Zhou <zhoutianran=40huawei....@dmarc.ietf.org><mailto:zhoutianran=40huawei....@dmarc.ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org> Objet : RE: WGLC for draft-ietf-opsawg-service-assurance-yang-05 Hi Med, thanks again for your very thorough comments on the draft about the YANG modules for service assurance. The diff is here: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-yang-06 I think that I addressed most of your comments. The main one remaining is: About maintenance-contact MED: "Shouldn’t this be an URI?" "A pattern should then be provided to comply with this?" Tried to add a pattern about adding monitor in front: pattern "(monitor:)?.*"; The I realized that it does not restrict anything. The description in English says what it should be while leaving things open. We might want to restrict more and I am open to any suggestion. Below are some answers to most important comments. Section 3 (ietf-service-assurance) YANG model About assurance-graph-version counter MED: "Shouldn’t this version be configurable when a new one is installed?" That counter should be automatically incremented each time any config node of the model is changed, should not be the responsibility of the client. Clarified in the text and the YANG model. About parameters MED: "I guess this is how you bind a service assurance to a service (or a service instance). If so, why isn’t this at the upper level? " Clarified in the text that service instances are a particular type of subsrevice and the link between a service and its graph is obtained by following the dependencies from the subservice representing the service instance. About the base identity for the susbservice types MED: "Shouldn’t a list of such identities be defined here as well?" and about the parameters MED: "Why is this defined as a choice?" Clarified in concepts before tree diagram that an augmentation is expected for each subservice type and that only the service instance type is defined in the base model. Clarified in the text after the tree that the parameters choice is the place where this augmentation takes place. Also made that choice mandatory so that a data instance without an entry in the parameter choice is invalid. (The drawback is that subservices that do not need any parameters, should they exist, will need to specify an augment with an empty container. At least it will be explicit that no parameters are needed.) About type of the subservice in the model MED: "Do you need a check to enforce that service instances are modeled as particular subservices ... ?" I don’t think that we can check that. However, each model augmenting the base model by defining a new subservice type must also augment the "parameter" choice by specifying which parameters are mandatory for that type. In the case of service instances, the parameters are indeed mandatory. About the symptoms start and end date. MED: "Stop should be > that start." Actually tried to encode that in a must constraint, but XPATH 1.0 does not have any date related function (FYI XPATH 3.0 does!) and I got a yanglint error trying to compare strings (luckily because I didn’t realize that yang:date-and-time is a string). So I just put that in the description of the leaf. Thanks again for all your reviews. Best, Jean From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> Sent: Tuesday 21 June 2022 09:02 To: Tianran Zhou <zhoutianran=40huawei....@dmarc.ietf.org<mailto:zhoutianran=40huawei....@dmarc.ietf.org>>; opsawg@ietf.org<mailto:opsawg@ietf.org> Subject: Re: [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05 Hi all, Please find below my comments to this version. * pdf: https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-ietf-opsawg-service-assurance-yang-05-rev%20Med.pdf * doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-opsawg-service-assurance-yang-05-rev%20Med.doc I think that some further work is needed. Cheers, Med PS: I didn’t review the appendices. De : OPSAWG <opsawg-boun...@ietf.org<mailto:opsawg-boun...@ietf.org>> De la part de Tianran Zhou Envoyé : mercredi 8 juin 2022 12:04 À : opsawg@ietf.org<mailto:opsawg@ietf.org> Objet : [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-yang-05 Hi WG, This mail we start a two weeks working group last call for draft-ietf-opsawg-service-assurance-yang-05. https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-assurance-yang/ 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 _________________________________________________________________________________________________________________________ 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.
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
