Control which notifications should be supported for the service

[boucadair]

See the description at: https://tools.ietf.org/html/rfc7297#section-3.13

The module can be used to aggregate notification data received via device modules and expose them at the service level.

[oscargdd]

This is a really interesting and hot topic and enters into the assurance part of the service (which we had not yet discussed properly, and we have to at some point). There is a draft from Benoit https://datatracker.ietf.org/doc/draft-claise-opsawg-service-assurance-architecture/?include_text=1 covers this topic in part.
Assuming the controller receives the device module notifications (propietary yang, IETF yang, openconfig, or traditional snmp….), we have two choices to move forward:
a) In this very same module, add state information that can be derived from the device data. That is, add the necessary leafs.
b) Separate work. Create a separate document for the L3NM assurance in which add:
b.1. Extra state information as leafs
b.2 Pointers to the device data models
Maybe, with a) we can define some of the most demanded state data.
I suggest starting the work in paralel, not impacting the work in the main module.

[boucadair]

Works for me.

I will start a separate document and share it with the group.

[oscargdd]

Let's close the issue and open new draft on the VPN Service assurance.

[boucadair]

https://datatracker.ietf.org/doc/html/draft-www-bess-yang-vpn-service-pm-06 can be used for this.

I suggest to cite this draft.