Hi Med,
Thanks again.
See inline for some points
On 6/27/2022 10:44 AM, 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..)
Therefore, it makes sense to have globally unique Ids
* 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?
If you configure an old assurance graph version, does it mean that you
want to network to go back to this old version?
If you configure an new assurance graph version, does it mean that you
know better than the SAIN architecture and that you impose it?
* 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.
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>
*Envoyé :* vendredi 24 juin 2022 20:56
*À :* 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-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
<mailto:opsawg-boun...@ietf.org>] *On Behalf Of
*mohamed.boucad...@orange.com
*Sent:* Tuesday 21 June 2022 09:02
*To:* Tianran Zhou <zhoutianran=40huawei....@dmarc.ietf.org>;
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
<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> *De la part de* Tianran Zhou
*Envoyé :* mercredi 8 juin 2022 12:04
*À :* 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.
_________________________________________________________________________________________________________________________
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
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
