Subject: [OPSAWG] Comment on draft-ietf-opsawg-sap-02

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 7 Mar 2022 18:24:07 +0000

I'm reading through this draft and generally okay with the flow (though
I not that provider is misspelled in Section 2), but one thing sticks out.

Why is attachment-interface a raw string on now a reference to an actual
interface?  Seeing Benoit credited on this work, I wonder what he'd say
since I know something he's passionate about is being able to have
meaningful references between objects (which YANG allows for) so that,
in this case, I can more easily and unambiguously determine services
attached to a given interface.

I'm fully ready to admit I might have missed a point on that.  But
reading through the example in the Appendix B still left me scratching
my head.

Thanks.

Joe

---

From: <[email-masked]>
Date: Tue, 8 Mar 2022 06:41:26 +0000

Hi Joe, 

That's on purpose. 

That leaf can point to a port or an interface. It can be a bridge reference or whatever identifier used for instantiating the service. For example, this can echo one of the various identifiers under LxNM connection and ip-connection containers. For example, any of the following identifiers can be used as an attachment-interface:   

** connection **
   |  +--rw l2-termination-point?      string
   |  +--rw local-bridge-reference?    string
   |  +--rw bearer-reference?          string
   |  |       {vpn-common:bearer-reference}?
   |  +--rw lag-interface {vpn-common:lag-interface}?
   |     +--rw lag-interface-id?   string

** ip-connection **

         |  +--rw l3-termination-point?     string

We will add an example to illustrate how the mapping/references are shared between SAP and LxNM. 

Cheers,
Med

> -----Message d'origine-----
> De : OPSAWG <[email-masked]> De la part de Joe Clarke (jclarke)
> Envoyé : lundi 7 mars 2022 19:24
> À : [email-masked]
> Objet : [OPSAWG] Comment on draft-ietf-opsawg-sap-02
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

_________________________________________________________________________________________________________________________

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.

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 8 Mar 2022 15:05:29 +0000

Thanks, Med.

As a consumer or operator of an implementation of this work, what would
you do with the value of attachment-interface?  How would you monitor
that to ensure the services attached there are healthy?  Assume the type
is phy.  You can't assume that the value is anything you can look up in
other YANG-modeled trees.

In your example, you use GE0/6/1 which may or may not be an interface
name in ietf-interfaces (as an example).  Again, just curious as an
operator what I do to measure overall health of this entity and still
tie that to all services that might be impacted?

Joe

---

From: <[email-masked]>
Date: Tue, 8 Mar 2022 16:10:04 +0000

Re-,

This is the responsibility of the controller. The saps will be fed in sync with the underlying device/interface modules/repo.

The attachment-interface can be set to, e.g., the interface-id under the vpn network access of LxNM or one of the various references mentioned in my previous reply. 

We will include an example with a focus on the mapping with LxNM service to illustrate how that leaf can be set. 

Cheers,
Med

> De : Joe Clarke (jclarke) <[email-masked]>
> Envoyé : mardi 8 mars 2022 16:05
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>;
> [email-masked]
> Cc : [email-masked]
> Objet : Re: Comment on draft-ietf-opsawg-sap-02
> 
> Thanks, Med.
> 
> > That leaf can point to a port or an interface. It can be a bridge
> reference or whatever identifier used for instantiating the service. For
> example, this can echo one of the various identifiers under LxNM
> connection and ip-connection containers. For example, any of the
> following identifiers can be used as an attachment-interface:
> >
> > ** connection **
> >> De : OPSAWG <[email-masked]> De la part de Joe Clarke
> >> (jclarke) Envoyé : lundi 7 mars 2022 19:24 À : [email-masked] Objet
> >> : [OPSAWG] Comment on draft-ietf-opsawg-sap-02
> >>
> >> I'm reading through this draft and generally okay with the flow
> >> (though I not that provider is misspelled in Section 2), but one
> >> thing sticks out.
> >>
> >> Why is attachment-interface a raw string on now a reference to an
> >> actual interface?  Seeing Benoit credited on this work, I wonder what
> >> he'd say since I know something he's passionate about is being able
> >> to have meaningful references between objects (which YANG allows for)
> >> so that, in this case, I can more easily and unambiguously determine
> >> services attached to a given interface.
> >>
> >> reading through the example in the Appendix B still left me
> >> scratching my head.
> >>
> >> Thanks.
> >>
> >> Joe
> >>
> > ______________________________________________________________________
> > ___________________________________________________
> >
> > 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.

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Wed, 9 Mar 2022 15:55:27 +0000

Thanks, Med.  As you say, the controller could use some unambiguous
reference for the SAP interface.  I look forward to the mapping text.

Joe

---

From: Benoit Claise <[email-masked]>
Date: Thu, 24 Mar 2022 14:18:41 +0100

Hi,

I've been looking through (most of) the diffs.
I believe my initial comments are addressed.
I'm also looking forward to the mapping text.
In the end, I would like to make sure that we can reuse this SAP concept 
with the Service Assurance for Intent-based Network drafts, to be able 
to determine to which new SAP we could re-deploy a service in case of 
degradation/failure. I'll go through a paper example myself.
I guess I will arrive to the same conclusion as Med: "This is the 
responsibility of the controller/orchestrator to get the right mapping"

Regards, Benoit

On 3/9/2022 4:55 PM, Joe Clarke (jclarke) wrote:
> .

---

From: <[email-masked]>
Date: Thu, 24 Mar 2022 13:25:46 +0000

Hi Benoît, 

Thank you for sharing this feedback. 

The latest version includes mapping examples in both the core text and a new appendix. Please check that version and let me know if any tweaking is needed. Thanks. 

Cheers,
Med

> De : Benoit Claise <[email-masked]>
> Envoyé : jeudi 24 mars 2022 14:19
> À : Joe Clarke (jclarke) <jclarke=[email-masked]>; BOUCADAIR
> Mohamed INNOV/NET <[email-masked]>; [email-masked]
> Objet : Re: [OPSAWG] Comment on draft-ietf-opsawg-sap-02
> 
> Hi,
> 
> with the Service Assurance for Intent-based Network drafts, to be able to
> determine to which new SAP we could re-deploy a service in case of
> >> This is the responsibility of the controller. The saps will be fed in
> sync with the underlying device/interface modules/repo.
> >>
> >> The attachment-interface can be set to, e.g., the interface-id under the
> vpn network access of LxNM or one of the various references mentioned in my
> previous reply.
> >>
> >>> De : Joe Clarke (jclarke) <[email-masked]> Envoyé : mardi 8 mars
> >>> 2022 16:05 À : BOUCADAIR Mohamed INNOV/NET
> >>> <[email-masked]>; [email-masked] Cc :
> >>> [email-masked] Objet : Re: Comment on
> >>> draft-ietf-opsawg-sap-02
> >>>
> >>> Thanks, Med.
> >>>
> >>> As a consumer or operator of an implementation of this work, what
> >>> would you do with the value of attachment-interface?  How would you
> >>> monitor that to ensure the services attached there are healthy?
> >>> Assume the type is phy.  You can't assume that the value is anything
> >>> you can look up in other YANG-modeled trees.
> >>>
> >>> In your example, you use GE0/6/1 which may or may not be an
> >>> interface name in ietf-interfaces (as an example).  Again, just
> >>> curious as an operator what I do to measure overall health of this
> >>> entity and still tie that to all services that might be impacted?
> >>>
> >>> Joe
> >>>
> >>> reference or whatever identifier used for instantiating the service.
> >>> For example, this can echo one of the various identifiers under LxNM
> >>>>> actual interface?  Seeing Benoit credited on this work, I wonder
> >>>>> what he'd say since I know something he's passionate about is
> >>>>> being able to have meaningful references between objects (which
> >>>>> YANG allows for) so that, in this case, I can more easily and
> >>>>> unambiguously determine services attached to a given interface.
> >>>>>
> >>>> ___________________________________________________________________
> >>>> ___ ___________________________________________________
> >>>>
> >>>> 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.
> >>>> 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.
> >>>>
> >>>>
> >> _____________________________________________________________________
> >> ____________________________________________________
> >>
> >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que
> les pieces jointes. Les messages electroniques etant susceptibles
> >> privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.