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

Qin Wu <bill.wu@huawei.com> Tue, 17 July 2018 11:18 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 61065130E11 for <netconf@ietfa.amsl.com>; Tue, 17 Jul 2018 04:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, 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 M9VCZWAnlv4a for <netconf@ietfa.amsl.com>; Tue, 17 Jul 2018 04:18:31 -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 D0AA8130DCD for <netconf@ietf.org>; Tue, 17 Jul 2018 04:18:30 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 40E308530617D for <netconf@ietf.org>; Tue, 17 Jul 2018 12:18:25 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 17 Jul 2018 12:18:26 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.110]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0382.000; Tue, 17 Jul 2018 19:18:21 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: Monitor the whole operation state vs Monitor applied configuration from intended
Thread-Index: AdQdvBAmwWsE3r6dTZ+nr9RUYJDuEw==
Date: Tue, 17 Jul 2018 11:18:21 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9AF501EA@nkgeml513-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.124.182.180]
Content-Type: multipart/related; boundary="_004_B8F9A780D330094D99AF023C5877DABA9AF501EAnkgeml513mbxchi_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/D43ws_JtGts_b0O3fhgyP4zARJI>
Subject: [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 11:18:33 -0000

Hi, All:
When we discussed NMDA base event draft (https://tools.ietf.org/html/draft-wu-netconf-base-notification-nmda-01), 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), 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.
[cid:image001.png@01D41E02.25AA6980]
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