From: OPSAWG <opsawg-boun...@ietf.org> on behalf of mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> Sent: 12 December 2022 12:52
Hi Rob, Thanks for the follow-up. After rereading the initial proposed updated text, I think that you have a valid point about the need for more clarity when describing the relationship between the various status data nodes. I released -11 with an attempt to make that better. Both the data nodes description and the examples are updated to reflect the intent. The relationship (including what should be considered as anomalies) are also described. The new text also clarifies that the per-SAP service status should not be confused with the global service status (which may involved more than one SAP). Adrian's comment that a SAP failure does not imply a service failure is true for that global service status, not for the (per-SAP) service status included in the SAP. <tp> I do not know if my confusion is along the same lines as his but.. I am left wondering if a SAP instance is limited to one service e.g. L2VPN or whether a SAP instance can support more than one e.g. both L2VPN and EVPN. The YANG module implies only the one. sap-list is a list of SAP with a single container oper-status which is the 'Operational status of the service...' i.e. a SAP has only one service status so a SAP has only one service If there were more than one then oper-status would be a list keyed on service In passing /povider/provider/ Tom Petch The new text is available at: URL: https://www.ietf.org/archive/id/draft-ietf-opsawg-sap-11.txt Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-sap-11 Hope this is better. Thanks. Cheers, Med > -----Message d'origine----- > De : Rob Wilton (rwilton) <rwil...@cisco.com> > Envoyé : vendredi 9 décembre 2022 15:22 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > draft-ietf-opsawg-sap....@ietf.org; opsawg@ietf.org > Objet : RE: AD review of draft-ietf-opsawg-sap-09 > > Hi Med, > > Sorry, still not clear (in my head) on the exact differentiation > between sap-status and service-status. > > Also, a few other nits that I spotted: > s/is capable to host/is capable of hosting/ (two places) s/ that > uniquely identifies SAP/ that uniquely identifies a SAP/ s/ are > tagged as ready to host/ are tagged as being capable of hosting/ > > Please see inline ... > > > -----Original Message----- > > From: mohamed.boucad...@orange.com > > <mohamed.boucad...@orange.com> > > Sent: 09 November 2022 15:11 > > To: Rob Wilton (rwilton) <rwil...@cisco.com>; draft-ietf-opsawg- > > sap....@ietf.org; opsawg@ietf.org > > Subject: RE: AD review of draft-ietf-opsawg-sap-09 > > > > > > > > > > > > But how do you distinguish between a SAP that hasn't been > > > > > provisioned yet to a service vs a SAP that has been > provisioned > > > > > but the service is down? E.g., trying to find a free SAP > just > > > > > by looking for a SAP with a service-status of op-down > doesn't > > > > > appear to be sufficient on its own. > > > > > > > > [Med] A SAP that is not provisioned yet will have a > > > > sap-status=down, > > > while > > > > the one that is provision but the service is not activated > will > > > > have > > > sap- > > > > status=up and service-status=down. Isn't that sufficient? > > > > > > I would have assumed: > > > - If sap-status is down then the service-status must also be > down, > > > right? > > > > [Med] Actually, no. The service status indicates whether a > service is > > associated with the SAP. Added both the admin and op status of > the > > service status and added this NEW text: > > > > "This data node indicates whether a service is bound to this SAP > and, > > as such, it is not influenced by the value of the 'sap-status'." > [Rob Wilton (rwilton)] > > " 'service-status': Reports the status of the service for a given > SAP. ...". This states that it is reporting the status of the > service for a given SAP. > > For the service-status/admin-status I can see how the service can > be admin-up for a SAP that is down (e.g., perhaps there is a > broken fiber such that the physical interface or sub-interface is > down). But I would still find it confusing to say that the > service at the SAP is operationally up on a SAP that is down. > > Specifically, if a customer was to ask whether there are able to > get service at a particular SAP, is it sufficient for the operator > to check service-status/oper-status on the SAP, or must they check > both service-status/oper-status and service-status/sap-status to > know whether or not they will be receiving service at a particular > SAP? > > If the draft description, and perhaps even more critically, the > YANG model description, can be really clear on this, I think that > will help implementors and users. > > Regards, > Rob _________________________________________________________________________________________________________________________ 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
