Hi Jean,
Thank you for addressing most of the comments.
Please find below the remaining points I have on -04:
* Please move the first para to the end of the Introduction. The arch is
not yet introduced at this stage.
* Remove the text about normative language from Section 2 as none of these
terms are used in the document.
* Change "Service Configuration Orchestrator" in Figure 1 to "Service
Orchestrator" to be consistent with RFC8309. I don't think there is "Service
Configuration Orchestrator" is present in RFC8199 as well.
* I suggest changing "The overall SAIN architecture is presented in Figure
1. Based on the service configuration," to "The overall SAIN architecture is
presented in Figure 1. Based on the service configuration provided by the
service orchestrator,"
* Shouldn't this part of Figure 1 be updated to cover when the service
configuration is retrieved at the initiative of the SAIN orchestrator. Of
course, subsequent updates can be sent by the service orchestrator.
OLD:
+-----------------+
| Service |
| Configuration |<--------------------+
| Orchestrator | |
+-----------------+ |
| | |
| | Network |
| | Service | Feedback
| | Instance | Loop
| | Configuration |
| | |
| V |
NEW:
+-----------------+
| Service |
| Configuration |<--------------------+
| Orchestrator | |
+-----------------+ |
| ^ |
| | Network |
| | Service | Feedback
| | Instance | Loop
| | Configuration |
| | |
| V |
* "Monitored Entities" are not called out in the description text. As you
are using "network system" in many parts of the doc, I wonder whether you can
simply use it in the figure as well instead of the "Monitored Entities".
* 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.
* nits
* Expand SAIN at first use.
* s/RFC3164/RFC5424
* Please fix: "The parameters that such a service would take as
parameters are..."
* s/These modules is intended/These modules are intended
* s/a subservice also define its assurance/a subservice also defines its
assurance
Thank you.
Cheers,
Med
De : Jean Quilbeuf <[email protected]>
Envoyé : mercredi 22 juin 2022 12:16
À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; Tianran Zhou
<[email protected]>; [email protected]
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:[email protected]] On Behalf Of
[email protected]<mailto:[email protected]>
Sent: Monday 20 June 2022 15:12
To: Tianran Zhou
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
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 <[email protected]<mailto:[email protected]>> De la
part de Tianran Zhou
Envoyé : mercredi 8 juin 2022 12:00
À : [email protected]<mailto:[email protected]>
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.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
