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

[[e-mail]]

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.