Hi Jean, The changes are great. I like how you updated Section 3.2, in particular.
I have one last comment: the document uses “Network service YANG modules”, “service model”, and “network model” terms which may be confusing for some readers not familiar with the topic to understand the subtleties among them. A pointer for the first term is already provided (RFC8199), for the remaining two I suggest to make this change: == OLD: If the SAIN orchestrator supports it, the service model NEW : If the SAIN orchestrator supports it, the service model (Section 2 of [RFC8309]) or the network model (Section 2.1 of [RFC8969]) == Alternatively, you can add this sentence at the beginning of Section 2: == NEW: This document makes use of the terms defined in [RFC8199], [RFC8309], and [RFC8969]. In addition, the document defines the following terms: == Feel free to release a new version with this change or leave it for the next iteration. I think that this version is stable enough and support advancing it to the IESG. Thank you for all your effort. Cheers, Med De : Jean Quilbeuf <jean.quilb...@huawei.com> Envoyé : mercredi 22 juin 2022 23:57 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; Tianran Zhou <zhoutianran=40huawei....@dmarc.ietf.org>; opsawg@ietf.org Objet : RE: WGLC for draft-ietf-opsawg-service-assurance-architecture-03 Hi Med, Thanks for the follow-up. Here is the diff https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-architecture-05. See below for the answers. Best, Jean * If you want to assure the service, I guess that the dependency graph will be a function of how the service is put into effect in the network. As such, the SAIN orchestrator is likely to consume the (internal) view of the service, that is the network model, not the one exposed to the customer. For example, shouldn’t the L2NM/L3NM be passed to the SAIN orchestrator instead of the L2SM/L3SM for the VPN service case? I would add some clarification about this. The draft kind of assumes the following: Service Model -–[Service Orchestrator]--> Device Model But, you’re right, it could also be: Service Model ----[Service Orchestrator]----> Network Model ----[Controller]-----> Device Model In terms of architecture, the differences lies between what the SAIN orchestrator is aware of. Being aware of the device model allows interpreting the configuration pushed to the device without needed to know about the service or network model. Being aware of the service or network model enables a finer interpretation, notably including details that are not part of the device model, such as VPN sites, but requires more implementation effort as more models need to be processed. I tried to clarify that in the text. Thank you. Cheers, Med De : Jean Quilbeuf <jean.quilb...@huawei.com<mailto:jean.quilb...@huawei.com>> Envoyé : mercredi 22 juin 2022 12:16 À : 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-architecture-03 Hi Med, thanks again for your extensive review. For the benefit of the list, I reproduced your high-level comments here and add some answers. The diff is here https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-service-assurance-architecture-04 for all the details. Title: MED: "A YANG-based Service Assurance Architecture" We want to keep the current title. I think that the document clarifies that we consider the service approach as an primitive intent-based approach, and the architecture can accommodate more explicit intent declarations. Abstract: About "network root cause" MED: I see some text in the intro and security sections. I’m afraid that including this claim in the abstract need to be backed with more discussion in the document. Removed "root cause" from the abstract and stated in the introduction how our approach can help with root cause. Introduction: About " an assurance graph, deduced from the service definition and from the network configuration" MED: It would be helpful to clarify if it only consumes network models (e.g., L2NM, L3NM) or the collection of the various device modules that are enabled in all network nodes. Clarified that our approach does not assume that the SAIN orchestrator knows the Service model. If it is known, then it can be interpreted, otherwise only device model can be exploited. Section 3.2: About: "Try to capture the intent of the service instance" MED: Why not providing the intent in the first place rather than inferring it from the configuration? Explictly providing the intent might mean modifying current service models or at least defining a mapping from them to the intent. Added in text that if service model is known to the SAIN orchestrator, then it can be used to provide intent. Section 3.8: About "Flexible Architecture" MED: I think you just meant the arch is a functional one, not an organic arch. Renamed the section "Functional Flexible Architecture" I am available for any further comments and addressing your comments on the companion -yang draft as well. Thanks again, Jean From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> Sent: Monday 20 June 2022 15:12 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-architecture-03 Hi all, Many thanks to the authors for the effort put into this document. I think that the document is better compared to the last time I reviewed it. However, I think that some changes are needed to better articulate the intended behavior and overall operation. I had to jump several times between the terminology section (and some key elements in the introduction) and the core text to digest the concept that are being discussed. The flow can be worked better. FWIW, some more detailed comments can be seen at: * pdf: https://raw.githubusercontent.com/boucadair/IETF-Drafts-Reviews/master/draft-ietf-opsawg-service-assurance-architecture-03-rev%20Med.pdf * doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-opsawg-service-assurance-architecture-03-rev%20Med.doc Cheers, Med De : OPSAWG <opsawg-boun...@ietf.org<mailto:opsawg-boun...@ietf.org>> De la part de Tianran Zhou Envoyé : mercredi 8 juin 2022 12:00 À : opsawg@ietf.org<mailto:opsawg@ietf.org> Objet : [OPSAWG] WGLC for draft-ietf-opsawg-service-assurance-architecture-03 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 _________________________________________________________________________________________________________________________ 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. _________________________________________________________________________________________________________________________ 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. _________________________________________________________________________________________________________________________ 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
