Hi Med,
Great, thanks. I've request IETF LC on -12.
If any clarifications or changes are required based on the question raised by
Tom then please can you resolve that as part of the IETF LC.
Regards,
Rob
> -----Original Message-----
> From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>
> Sent: 16 December 2022 14:17
> To: Rob Wilton (rwilton) <rwil...@cisco.com>
> Cc: draft-ietf-opsawg-sap....@ietf.org; opsawg@ietf.org
> Subject: RE: AD review of draft-ietf-opsawg-sap-09
>
> Hi Rob,
>
> The proposed edits look good to me. These are now implemented in the public -
> 12. Thanks.
>
> cheers,
> Med
>
> > -----Message d'origine-----
> > De : Rob Wilton (rwilton) <rwil...@cisco.com>
> > Envoyé : vendredi 16 décembre 2022 12:11
> > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>
> > Cc : draft-ietf-opsawg-sap....@ietf.org; opsawg@ietf.org
> > Objet : RE: AD review of draft-ietf-opsawg-sap-09
> >
> > Hi Med,
> >
> > Thanks for persevering, I think that we are pretty much there.
> >
> > I've have proposed some minor tweaks the description and YANG leaf
> > descriptions that I think may improve clarity, but I'll leave it
> > to you to decide whether it would be helpful to incorporate these.
> > Please either merge/some all of these and post an updated version
> > or indicate whether you would like to stick with -11, and then I
> > can kick off the IETF LC.
> >
> > OLD:
> > 'service-status': Indicates the administrative and operational
> > status of the service for a given SAP. This information is
> > particularly useful when many services are enabled for the
> > same
> > SAP, but only a subset of these services are activated. As
> > such,
> > the administrative 'service-status' MUST NOT be influenced
> > by the
> > value of the 'sap-status'.
> >
> > The service 'oper-status' reflects the service operational
> > status
> > as observed for a specific SAP, not the status that is
> > determined
> > at the network level for a service that involves many SAPs.
> > That
> > network level status can be retrieved using specific network
> > models, e.g., Section 7.3 of [RFC9182] or Section 7.3 of
> > [RFC9291].
> >
> > In order to assess the service delivery status for a given
> > SAP, it
> > is recommended to check both the administrative and
> > operational
> > service status ('service-status') in addition to the 'sap-
> > status'.
> > In doing so, a network controller (or an operator) can
> > detect
> > anomalies. For example, if a service is administratively
> > enabled
> > for a SAP and the 'sap-status' of that SAP is reported as
> > being
> > down, the service 'oper-status' is also expected to be down.
> > Retrieving a distinct service operational status under these
> > conditions can be used as a trigger to detect an anomaly.
> > Likewise, administrative status and operational status can
> > be used
> > as a trigger to detect service-specific SAP activation
> > anomalies.
> > For example, a service that is administratively declared as
> > inactive for a SAP but reported as operationally active for
> > that
> > SAP is an indication that some service provision actions are
> > needed to align the observed service status with the
> > expected
> > service status.
> >
> > NEW:
> > 'service-status': Indicates the administrative and
> > operational
> > status of the service for a given SAP. This information is
> > particularly useful when many services are provisioned for
> > the same
> > SAP, but only a subset of these services are activated. As
> > such,
> > the administrative 'service-status' MUST NOT be influenced
> > by the
> > value of the operational 'sap-status'.
> >
> > The service 'oper-status' reflects the operational status of
> > the
> > service only as observed at a specific SAP, not the overall
> > network level status of the service connecting many SAPs.
> > The
> > network level service status can be retrieved using specific
> > network models, e.g., Section 7.3 of [RFC9182] or Section
> > 7.3 of
> > [RFC9291].
> >
> > In order to assess the service delivery status for a given
> > SAP, it
> > is recommended to check both the administrative and
> > operational
> > service status ('service-status') in addition to the 'sap-
> > status'.
> > In doing so, a network controller (or operator) can detect
> > anomalies. For example, if a service is administratively
> > enabled
> > for a SAP and the 'sap-status' of that SAP is reported as
> > being
> > down, the service 'oper-status' is also expected to be down.
> > Retrieving a distinct service operational status under these
> > conditions can be used as a trigger to detect an anomaly.
> > Likewise, administrative status and operational status can
> > be
> > compared to detect service-specific SAP activation
> > anomalies.
> > For example, a service that is administratively declared as
> > inactive for a SAP but reported as operationally active for
> > that
> > SAP is an indication that some service provision actions are
> > needed to align the observed service status with the
> > expected
> > service status.
> >
> > Some proposed tweaks to YANG container/leaf descriptions:
> >
> > container sap-status {
> > config false;
> > description
> > "Indicates the operational status of the SAP,
> > independent
> > of any service provisioned over it.";
> >
> > container admin-status {
> > description
> > "Administrative service status.";
> > leaf status {
> > type identityref {
> > base vpn-common:administrative-status;
> > }
> > description
> > "Administrative status of the service provisioned
> > at the SAP.";
> > }
> > leaf last-change {
> > ...
> > }
> >
> > container oper-status {
> > config false;
> > description
> > "Operational status of the service provisioned at
> > the SAP.";
> > uses vpn-common:oper-status-timestamp;
> > }
> > }
> > }
> > }
> >
> > Regards,
> > Rob
> >
> >
> > > -----Original Message-----
> > > From: mohamed.boucad...@orange.com
> > <mohamed.boucad...@orange.com>
> > > Sent: 12 December 2022 12:53
> > > To: Rob Wilton (rwilton) <rwil...@cisco.com>
> > > Cc: draft-ietf-opsawg-sap....@ietf.org; opsawg@ietf.org
> > > Subject: RE: AD review of draft-ietf-opsawg-sap-09
> > >
> > > 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.
> > >
> > > 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.
>
>
> ________________________________________________________________
> _________________________________________________________
>
> 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
