Re: [Netconf] Monitor the whole operation state vs Monitor applied configuration from intended

[Kent Watsen <[e-mail]>]

Hi Qin,

Related to your base-notifications draft is Alex’s NMDA-diff draft [1], which will be presented on Friday in NETMOD session 2.  This seems to be the RPC I was asking about yesterday.

We may want to move this draft to that WG also.

I think that we may want three kinds of notifications:

  - one for when the system starts applying <intended>

  - one for when the system is unable to apply something

  - one for when the system has finished trying to apply <intended>

[1] https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00.

Kent

On Jul 17, 2018, at 7:18 AM, Qin Wu <[e-mail]<mailto:[e-mail]>> wrote:

Hi, All:
When we discussed NMDA base event draft (https://tools.ietf.org/html/draft-wu-netconf-base-notification-nmda-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwu-2Dnetconf-2Dbase-2Dnotification-2Dnmda-2D01&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=1plcIxboqyr85aJ4aCLZfaYP33crrYJihpJfDF5ZBoY&s=Hb6_5CzXLXS_dUMyulBzCPWVI4t78io1BdH3gr7jWGk&e=>), one issues raised is about whether we should monitor operational state via subscription and see whether it converge. I think this is close to what we proposed in (https://datatracker.ietf.org/meeting/102/materials/slides-102-netconf-base-notifications-for-nmda-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_meeting_102_materials_slides-2D102-2Dnetconf-2Dbase-2Dnotifications-2Dfor-2Dnmda-2D01&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=1plcIxboqyr85aJ4aCLZfaYP33crrYJihpJfDF5ZBoY&s=P28K2mMsZqHgE8NJ80clH3KkBDyGyOOLDiAwRvxljuk&e=>), but I don’t understand when you subscribe something, but you don’t expect notification to be sent from the server. So notification is necessary, otherwise you may send RPC query message every time. the application or client can choose not subscribe these data if they are not interested in it, just like what RFC6470 is doing.

In our proposal, we only monitor applied configuration from intended, we don’t monitor the whole operational state, we don’t monitor learned configuration, system configuration, default configuration, since this is something we can not control based on NMDA architecture, when we only monitor applied configuration from intended, see whether they are validated correctly based on figure 2 of RFC8342, the server should know when these small amount of configuration data can be applied comparing with the whole operational state.

Also I believe in your BGP route converging case, it indicate you are interested in how system state or learned configuration, etc are validated, however this is not specified in NMDA architecture of RFC8342, based on figure 2 of RFC8342, the only configuration data that is subject to validation are the configuration data that is applied from intended.
<image001.png>
Also I believe when you apply configuration on linecard that is not present, this can be detected by the server since this is just a internal operation. Figure 2 of RFC8342 has already listed this as example of misresource.

-Qin
_______________________________________________
Netconf mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=1plcIxboqyr85aJ4aCLZfaYP33crrYJihpJfDF5ZBoY&s=tz0NhuIwKmlGrcU2ips-CLNsBHVI48tNZfewPGFhbaQ&e=