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

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

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]>;
> > [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.