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

From: Qin Wu <[email-masked]>
Date: Tue, 17 Jul 2018 21:03:40 +0000

Hi,
发件人: Kent Watsen [mailto:[email-masked]]
发送时间: 2018年7月17日 21:19
收件人: Qin Wu <[email-masked]>
抄送: [email-masked]
主题: Re: [Netconf] Monitor the whole operation state vs Monitor applied configuration from intended

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.

[Qin]: I have no strong opinion on this, stay in netconf, move to netmod, Okay with either choice.
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>

[Qin]: It seems to me these three notifications are similar to netconf-session-start and netconf-session-end proposed in RFC6470, which will inform the client when applying <intended> start and when applying intended complete.
With these three notification, I believe it can address comments raised in yesterday netconf session. Thanks for that.

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

Kent

On Jul 17, 2018, at 7:18 AM, Qin Wu <[email-masked]<mailto:[email-masked]>> 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.
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
[email-masked]<mailto:[email-masked]>
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=