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 <[email protected]<mailto:[email protected]>>
Envoyé : mercredi 22 juin 2022 12:16
À : BOUCADAIR Mohamed INNOV/NET
<[email protected]<mailto:[email protected]>>; Tianran
Zhou
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[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
