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

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

Hi Tom,

My understanding is that service is the top list (i.e., node/service) and the saps are in the per service child list:

            augment /nw:networks/nw:network/nw:node:
              +--rw service* [service-type]
                 +--rw service-type                   identityref
                 +--rw sap* [sap-id]

The text is section 5 states:

   'sap-id':  Includes an identifier that uniquely identifies a SAP
      within a node.

      The same SAP may appear under distinct service types.  In such a
      case, the same identifier is used for these service types in
      association.

So, I think that the answer is yes, the same SAP can support multiple services, but they are keyed by service then sap, rather than the other way round, and some presumably common SAP properties will appear duplicated per service.  For SAP properties that must be common across all services on the same SAP then I think that the authors and WG considered have a separate per node SAP list but presumably decided that aligning this under the service made the model easier to use, particularly in the case where there is only a single service per SAP.

Regards,
Rob


> -----Original Message-----
> From: tom petch <[e-mail]>
> Sent: 19 December 2022 12:19
> To: [e-mail]; Rob Wilton (rwilton)
> <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: AD review of draft-ietf-opsawg-sap-09
> 
> From: OPSAWG <[e-mail]> on behalf of
> [e-mail] <[e-mail]>
> 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) <[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.
> 
> _______________________________________________
> OPSAWG mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsawg