Thanks, Med. As you say, the controller could use some unambiguous reference for the SAP interface. I look forward to the mapping text.
Joe On 3/8/22 11:11, [email protected] wrote: > 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 > >> -----Message d'origine----- >> De : Joe Clarke (jclarke) <[email protected]> >> Envoyé : mardi 8 mars 2022 16:05 >> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; >> [email protected] >> Cc : [email protected] >> 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 >> >> On 3/8/22 01:41, [email protected] wrote: >>> 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 protected]> De la part de Joe Clarke >>>> (jclarke) Envoyé : lundi 7 mars 2022 19:24 À : [email protected] 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. >>>> >>>> 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 >>>> >>>> _______________________________________________ >>>> OPSAWG mailing list >>>> [email protected] >>>> 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. >>> >>> > > _________________________________________________________________________________________________________________________ > > 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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
