Re: [OPSAWG] AD review of draft-ietf-opsawg-sap-09

["Rob Wilton (rwilton)" <[e-mail]>]

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: [e-mail] <[e-mail]>
> Sent: 16 December 2022 14:17
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: [e-mail]; [e-mail]
> 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) <[e-mail]>
> > Envoyé : vendredi 16 décembre 2022 12:11
> > À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> > Cc : [e-mail]; [e-mail]
> > 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: [e-mail]
> > <[e-mail]>
> > > Sent: 12 December 2022 12:53
> > > To: Rob Wilton (rwilton) <[e-mail]>
> > > Cc: [e-mail]; [e-mail]
> > > 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) <[e-mail]> Envoyé :
> > vendredi 9
> > > > décembre 2022 15:22 À : BOUCADAIR Mohamed INNOV/NET
> > > > <[e-mail]>; draft-ietf-opsawg-
> > [e-mail];
> > > > [e-mail] 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: [e-mail]
> > <[e-mail]>
> > > > > Sent: 09 November 2022 15:11
> > > > > To: Rob Wilton (rwilton) <[e-mail]>; draft-ietf-
> > opsawg-
> > > > > [e-mail]; [e-mail]
> > > > > 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.