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

Qin Wu <bill.wu@huawei.com> Tue, 17 July 2018 21:04 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B0D130DE2 for <netconf@ietfa.amsl.com>; Tue, 17 Jul 2018 14:04:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.089
X-Spam-Level:
X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSMQxoob0bnC for <netconf@ietfa.amsl.com>; Tue, 17 Jul 2018 14:03:55 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84D1129C6B for <netconf@ietf.org>; Tue, 17 Jul 2018 14:03:54 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3E5159C0FC7F7 for <netconf@ietf.org>; Tue, 17 Jul 2018 22:03:49 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 17 Jul 2018 22:03:50 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.110]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0382.000; Wed, 18 Jul 2018 05:03:41 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Kent Watsen <kwatsen@juniper.net>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] Monitor the whole operation state vs Monitor applied configuration from intended
Thread-Index: AdQeEXU9H2OJ7bRLRlu3k3d1DUPFUg==
Date: Tue, 17 Jul 2018 21:03:40 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9AF525EA@nkgeml513-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.124.182.251]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9AF525EAnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/8uZlUdCZVUsLaCxouawmSA4hqpI>
Subject: Re: [Netconf] Monitor the whole operation state vs Monitor applied configuration from intended
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jul 2018 21:04:00 -0000

Hi,
发件人: Kent Watsen [mailto:kwatsen@juniper.net]
发送时间: 2018年7月17日 21:19
收件人: Qin Wu <bill.wu@huawei.com>
抄送: netconf@ietf.org
主题: 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 <bill.wu@huawei.com<mailto:bill.wu@huawei.com>> 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
Netconf@ietf.org<mailto:Netconf@ietf.org>
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=