Re: [netmod] system configuration sync mechanism

"Jan Lindblad (jlindbla)" <jlindbla@cisco.com> Mon, 23 August 2021 10:50 UTC

Return-Path: <jlindbla@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF763A074E for <netmod@ietfa.amsl.com>; Mon, 23 Aug 2021 03:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.595
X-Spam-Level:
X-Spam-Status: No, score=-9.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Ov0eU+lq; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hKwyvQW+
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 SQn3NMqEnWWo for <netmod@ietfa.amsl.com>; Mon, 23 Aug 2021 03:50:10 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9873A074D for <netmod@ietf.org>; Mon, 23 Aug 2021 03:50:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32625; q=dns/txt; s=iport; t=1629715809; x=1630925409; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=G84JOk7fKnQzcjmJTA5LKk69JvHZGqW+fhKmnpbKIQ4=; b=Ov0eU+lquHaSi0Uvo6+jNuROKwnaz8fhTLSlGaAbA8bGKWcxsol8GN+S d7vjMWbW4AQxGWkI319qQYETGbB8vhsmhbqCPEhIoXy7y1u+BxuwpG+hC qJ1+7RFSx0I6CO0Kl/OqKxdGbWyReG/2Z/qWGx2RH1chj3RbZZl4RJytP g=;
IronPort-PHdr: A9a23:QioOKR3SX3cipIeGsmDPTVBlVkEcU/3cLxMQ44UgkbFVNK+k+seqME/e4KBri1nEFcXe5ulfguXb+6bnRSQb4JmHvXxDFf4EVxIMhcgM2QB1BsmDBB7qMfvjcCsgH98EX1hgrDm3NEFPE5P4YFvf6nS58T8VHED5Mgx4buT4E4LflYK5zee3rpbSeA5PwjG6ZOAaEQ==
IronPort-HdrOrdr: A9a23:WhpvEa2RhhpOmIwxQFMYKAqjBetxeYIsimQD101hICG9Lfb4qyn+ppomPEHP5wr5AEtQ5uxpOMG7MBThHO1OkPcs1NaZLUnbUQ6TTL2KgrGSuAEIdxeOk9K1kJ0QD5SWa+eATmSS7/yKmjVQeuxIqLLsnczY5pa9854ud3AWV0gK1XYeNu/vKDwPeOAwP+tBKHPz3LsimxOQPVAsKuirDHgMWObO4/fRkoj9XBIADxk7rCGTkDKB8tfBYlql9yZbdwkK7aYp8GDDnQC8zL6kqeuHxhjV0HKWx4hKmeHm1sBICKW3+40ow3TX+0KVjbZaKvu/VQMO0biSAZER4YHxSiIbToNOArXqDzqISFXWqlPdOX0Vmg7fIBej8AveSIrCNW8H4w4rv/MHTvMfgHBQ4O2UmZg7rV6xpt5ZCwjNkz/64MWNXxZ2llCsqX5niuILiWdDOLFuJIO4PeQkjTBo+bo7bWjHAbocYaRT5QDnlYBrWELfa2qcsnhkwdSqUHh2FhCaQlIassjQ1zRNhnh2w0YR2cRaxx47hdwAYogB4/6BPrVjlblIQMNTZaVhBP0ZSc/yDmDWWxrDPG+bPFyiHqAaPHDGrYLx/dwOla6XUY1NyIF3lIXKUVteu2J3c0XyCdeW1JkO6RzJSHXVZ0Wn9iif3ekwhlTYfsurDcSuciFbryKQmYRXPiSAYYfHBHt/OY6VEVfT
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BwAAAMfCNh/51dJa1aHQEBAQEJARIBBQUBggUIAQsBgSIwUQd3Ugg3MYRHg0gDhFlgiASBFI5jikuBLhSBEQNUCwEBAQ0BASoBDAoEAQGEJUUCF4IiAiU0CQ4BAgQBAQESAQEFAQEBAgEGBIERE4U7ByYNhkMCAQMBARARHQEBLAQHAQ8CAQg4BwMCAgIlCxQRAgQOBRQOgk8BgX5XAy8BDpxEAYE6AoofeoExgQGCBwEBBgQEgUpBRoI5GII0AwaBOgGCfYQOAQGCbYN6JxyBSUSBFSccgWFKNz6CYgEBAgEXgQAtARcugmo2gi6EQxguJgcGAWMEJxwIBgIgAg0sKloGDwlLBimRKjwHgxOIWjiDM4lYkh0KgyqKP5QXBSeDZZIokGuWFYIeiiKTXQ8EUwGEHAIEAgQFAg4BAQaBYTsrgS5wFTsqAYI+PhIZD4R+iSKDcoUUhUpzAjYCBgEKAQEDCYwlLYIYAQE
X-IronPort-AV: E=Sophos;i="5.84,344,1620691200"; d="scan'208,217";a="908136133"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Aug 2021 10:50:07 +0000
Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 17NAo7IM026685 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 23 Aug 2021 10:50:07 GMT
Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 23 Aug 2021 05:50:07 -0500
Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 23 Aug 2021 05:50:07 -0500
Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 23 Aug 2021 05:50:07 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hvk3D+9b1gKKTvb/1hbbNYknKpXiCN25YNoJ3oLnMrCM63wXxF4xUN6t4nratmRPEJ0xNxSgR2Y6BQC5OSqlah1n4S9NErmFhhgUeg6sGe47f9j4bm8MCJpqYKL3hJL6sjsLwP9ZqZuclvdMKBXKOv2UNTA1KcgkIhJC+kJ4vfPc7JOzQCUw47wkVeMCyvD/fO82I7VI8c3JmqIqD6/sNrXziUDHGP8LNPmOj7Tu/6kPrjybsq9BboXmr9d/Q2Dszs868r/UDBctLmz2YN8owmOXC3NuizQ5z2AAE+ZkmkrojzCdCYwkub515F4dXsXFQCc0eWLOyj+Sx+yka4Ielw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G84JOk7fKnQzcjmJTA5LKk69JvHZGqW+fhKmnpbKIQ4=; b=UyH4GOigQWLL4bCpFr1l8meSE+FbhcWRF2y5/wQWxGQYxAP/Jw/i52snBAF5Czxt5PgXVcDu/Os3oXug6lsw3/DZOeNPgUvz2K/YVUbTbsZWzpLMeAGehsfftObtJ+mUdmFNcTnUOrlAVxzpBAfKdYA7eAh/DFgA4wz3ok0D6kkdy9VsGKzvPgWTczjTFdmFiquf+y9CYJro9eiBWMAEMHkOQTfLFfp2EvqMs9rKSSnOFFImQ9NCD5VwMin0IYtP0uX0e9EPB0R/cU9LaDxsVwKfQa6bsi1K35uVgFKSLRdAYFbrlSprMSDM9ocQx2RstZIH/aNQDVTO4NZ028uDkw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G84JOk7fKnQzcjmJTA5LKk69JvHZGqW+fhKmnpbKIQ4=; b=hKwyvQW+6GEtjF6b1Ygt9jdu25HAZ1V162tVHo2tScf3YE9/y0MKNw5D2nb2rRxHNJm4uYy0FXxYdLZsVebbJEZcMwthCbBbsVjymVt/5S2NZmfpiCId50oEiuXPA04meSKSvuXIhSxvBf8gOKrnoflNUi+xxRZOyan9CLqWuBM=
Received: from DM6PR11MB2841.namprd11.prod.outlook.com (2603:10b6:5:c8::32) by DM6PR11MB3754.namprd11.prod.outlook.com (2603:10b6:5:146::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.22; Mon, 23 Aug 2021 10:50:05 +0000
Received: from DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::69e2:1350:480f:ce6e]) by DM6PR11MB2841.namprd11.prod.outlook.com ([fe80::69e2:1350:480f:ce6e%4]) with mapi id 15.20.4436.024; Mon, 23 Aug 2021 10:50:05 +0000
From: "Jan Lindblad (jlindbla)" <jlindbla@cisco.com>
To: Andy Bierman <andy@yumaworks.com>, "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
CC: Kent Watsen <kent+ietf@watsen.net>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] system configuration sync mechanism
Thread-Index: AQHXmAyigKIWDdtTOEOomfb3PG+PTA==
Date: Mon, 23 Aug 2021 10:50:05 +0000
Message-ID: <AF3746F4-F2C4-43FB-BE47-E040D8C385CB@cisco.com>
References: <ad7ec21e0d3d477b91bebdfdeec01303@huawei.com> <0100017b5558ab9d-43cdec2f-59c4-4ff0-97e2-3b90cfca869d-000000@email.amazonses.com> <CABCOCHQkJWtJLaGQGOiK73KOFdQJY4PGy5daZSj4ToZPqPubZQ@mail.gmail.com>
In-Reply-To: <CABCOCHQkJWtJLaGQGOiK73KOFdQJY4PGy5daZSj4ToZPqPubZQ@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.7)
authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f68700f2-9ea7-4189-de16-08d96623c495
x-ms-traffictypediagnostic: DM6PR11MB3754:
x-microsoft-antispam-prvs: <DM6PR11MB375400A9D68813E7122E9767CAC49@DM6PR11MB3754.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Gxpz3gRsZFQOkSEhvzgkIl8eDPX1IgF6s08ta1Va+2A1xQj8jzei76w8cnQDECYCCVJaUoGRAEi1sinNDYhnFlWA0cM/iVytJncOhb1eV73wq4VUltzS1uzP7/Kq+LucEe2CBcRJ8eR3q0poJHSm1qqCM7oUeF6cDRgrCQ7OOIv0m+6v3qChvq5DWRzrLaiR2ujDt4q9rc5eN72kXATtO7dSvJpHjPKndW1UEGOMxo624jmf7RFlcY4RKu5V3iBs2sfDHgPB2OPPZQiLEN64qg3jDC5CRUvm7sxXFIMbo1rPRG20kyV57iAx6dUlpsTKTP5/1ZAi92/4ILyhxnYAZxaQedHsbZZcX55yiJj8DIYeT0LsDGxZ09Jh+laIisFnsSO0OdBo0+Dkdvc8NMcupJu/MVCIZ2KnM05Kvl8a+XqCv9wz07gq81R5Ra1Hd/UIrKFsS5JWNcQZOOhLl3MeciTsXlfY+fSGWNjYXoOKYyW7x1rQfC+Hs/YYPRPcbwcrekzXJZffocSIYSgsYPYwEcaz9cVEKG0gwE2lhowW6IDuvE5MjB1QGXN0ghR5drnpqnCwV7wqdabq+BJvSCuDkkvxZOyIS2M5H/3kIVI8QbCFz0QsYUMVeL6fC0Int4VMqvgk3UhH638grx9Zx976AH2OUWphWO0iI9uUq7tIlTtqz3S7rVVBAiwyCPS95Yjl7obpG5oRL6x67RlnYOhJsEjoEHEudELmt8fOUIlHjfP97zL+J006Nr/1i9QqjsFnMwJgY9XuBJX0H3Tx3y0S1WDxnFjEuYcGboRNV5Kyw1GTufAg9MEsWi8rZt0GRKSWKTia3GcaySj5H/MC3adrYoU0fDYG5inYIBoCF3e55M4=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB2841.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(6512007)(4326008)(33656002)(8936002)(54906003)(2616005)(6486002)(71200400001)(36756003)(110136005)(2906002)(83380400001)(38070700005)(166002)(966005)(86362001)(26005)(122000001)(508600001)(76116006)(38100700002)(91956017)(6506007)(53546011)(5660300002)(66946007)(186003)(66446008)(66476007)(316002)(66556008)(64756008)(8676002)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: vqBUFZGpCy/g3oFdzbiBfOkzCUdTxT33FX05pCgqDFYkk9TkpCX3LD52xhb6egTxNmUH/nDOHRiafcOFbUvmcLfU6kkeYkD23rIDxVcnnASAgak/9kVUnvR+5sTcVx9ticzdJLPwSdsPABc7t3mGrqbSZrVoJb9M+fDrDbWl1dSWJShMEcVkV2zmEs1I6gKr54Qw5Jlieqx32kenZHFYKHjv0NpQzZIv/p+dKNV180avJRD+vjShjKCVT9J3+0N9Kvp6aTBK3xww7vmte2QAh12cRDpTBixPm6Qgo9uVmw46ryMVxjYOrbzSo7OTrJ1aXum4I+RKu/WRX18tqVW4mMWXSmEwhzZ5BM+oVTnINgrWXR5JZrq1GBXn7fsapYcNO94VKh4CPBW6ui9OtmZKrsTJ+ku1POSU02E1CZJQT2VmyOXZC+eJRxDYQQlhMWJ3NFKA38FZTYHbFU96O7nbb3nYysJtQy4Ih+Piuem+BD3DVr7AgqgTtSENDZ5FbZo0Jfrz6vV8oVYFp/O0eyBTYXzcOf7XJ9lm77YpfsZZx3VjcBTwezQD6yV8JV+iSBL/r49qGDSKE3stKaXyyxpYmfxwdYBYuKNYBcFx/R07WCs2fLT22yyPYfKO3D8At0ekJ3jtqIkLFi92R5Ha6COB4Dh2XbHpX0mAdY3uE9hSNMNYwaDJzMkjK730dJhMrO8L9LKW9uRrpRWa5ovUeMrJslBg8bzcXzBQQctHyf9U6WcRBj9cTMZHA1sQ0Yfy+G0wQr4hAtd1SVoRkmWpDQhqDJwLvByzNuxP4c26oaUSdOsxlSjQuz68gHD+jQzdI+nNj0xnAIFf+kBRDR0+1iheR0GHSY5XHOLJPtLJntiSpPiXH3mIZgKnbmLX5P2TRkFWX3vAJtv+x9mhss8DoHBmSNO5AQ7tDE1jfIHm1rb3d1LroTcsrylC3Qg3g8pkQnz9zTUZVpEPXOHivTuz/reQKElUAd8oGFqv1GOXzk6kbd0VjXrEvdPXNmcwk3AcSeQnLIFhf3PiClKVgtf8EKNvPKwKzoVRNVy7TGjp/LLgJ/YNLXt1Bncn0e7BBalWN2lz9gMTpHK/vCYx9uAPV0TbQDzIdBfzG5QAtkX7H8lF+zHzixaVHWMt0arN3CUgVA0am7U93VKOVuv6xKxmJdCIafJwPPhxN9yuJKeydaht08r0MOgWaIo0jE7q1PP1Q84LRd89s4VKf2RP5NZOhYNqTXsXLx2KIsifcxpC/AL9YxfBJ5i/ve2eoVba0emLVRA9GEHHGMNoELqJ/qPoUqu6/0bTIwG4BXuRmji+T8LM9dALpraYF3cfST6NrFqmKGs+nSjiFMjQEH+Cx6GJppIzFg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AF3746F4F2C443FBBE47E040D8C385CBciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB2841.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f68700f2-9ea7-4189-de16-08d96623c495
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2021 10:50:05.7030 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 5nkrhAQzCZKpvf4zYFPKbfyxoyOweK76hWpkXyKR/0QCYewMChJHO6C5It4RhpMhmbAscEPxRsOqb2EglYIaIw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3754
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/x07qf5CKbmwBYJv7-vQWQlEAqUU>
Subject: Re: [netmod] system configuration sync mechanism
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Aug 2021 10:50:16 -0000

Hi,

Sorry for getting late into this already unwieldy thread. Similar discussions have been flaring up regularly for as long as this work group has existed, and we have never been able to put it to final rest. At the heart of the issue is the age old division between "unpredictable" and "lazy" managed systems (NETCONF servers).

Unpredictable systems: systems that modify and extend their running configuration spontaneously (outside standards)
Lazy systems: systems that treat running as sacred scriptures of the gods (operator community and management systems)

There are NETCONF servers out there of both types (and across the spectrum in between), with huge implementation investments and future aspirations. Nothing is going to remove either approach from the market any time soon. My point is that when new protocol extensions are presented, such as the system datastore, their implications need to be evaluated for both categories of systems.

There has been a large number of point questions discussed in this thread, and I don't envy the draft authors to try to make sense of it all. An interim call, as suggested by Jason, may be the best answer, if the draft team can put together a material with decision points to cover.

Jason made several important points that I'd like to underscore imho:

One of the pretty fundamental issues IMO is whether we want good ol' standard <running> to always be valid (including for an offline client or tool to be able to validate instance data retrieved from a server against the YANG models).

I find this an essential concept for running. Much depends on this tenet.

I agree there can be dynamically added system config (e.g. create a new qos policy, and some queue list entries are automatically created inside that policy).

This is the defining trait of "unpredictable" systems, and there are many of those. There are also many "lazy" systems, which would never allow this.

Best Regards,
/jan



TL;DR defining typical "unpredictable" (U) and "lazy" (L) NETCONF server behavior.

+ Factory reset
U: creates a default user, scans the hardware and injects default line card configs in running
L: creates a default user, scans the hardware and injects default line card configs in running

+ Insert new line card
U: creates a default config for inserted line card and interfaces, maybe adds a suitable default speed leaf depending on hardware type
L: no change of running, but reflects insertion in operational and maybe with a notification

+ Configure parameters of interface on inserted line card
U: only changed parameters need to be written as running already has the interface
L: entire interface needs to be created in running with desired parameters

+ Remove that line card
U: removes the config for the ejected line card
L: no change of running, but operational now reflects the interface state as [hardware missing]

+ Reinsert the line card
U: creates a default config for inserted line card, maybe adds a suitable default speed leaf depending on hardware type
L: no change of running, but interface comes back on line as previously configured and operational now reflects the interface state as [up]

+ Reconfigure the interface type of existing interface
U: rejected
L: accepted, but operational state now reflects the interface state as [hardware mismatch]

+ Reconfigure the name of an interface
U: rejected
L: accepted if the name could be valid for this device, but operational state now reflects the interface state as [hardware missing]

+ Install backup
U: If the set of interfaces in the backup is a subset of currently present hardware, it is activated, otherwise rejected
L: accepted. If any hardware is currently missing as configured in the backup, their operational state is shown as [hardware missing]

A variant that falls between U and L might be a system that considers the insertion of a line card an "act of configuration". Hardware manipulation could be considered a kind of (so far proprietary) protocol with defined configuration semantics. The behavior of such a system might be exactly like a "lazy" system except in the "Configure parameters of interface on inserted line card" use case, where it behaves like an "unpredictable" system when there is no prior config for the card.

Thanks for reading the TLDR.
/jan


On 18 Aug 2021, at 01:34, Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>> wrote:

Hi,

I guess I do not agree with the premise of the draft, which is that the client
needs to take over control of the system-controlled configuration.  I will
wait for a draft update and see if that helps understand it better.


Andy

On Tue, Aug 17, 2021 at 11:21 AM Kent Watsen <kent+ietf@watsen.net<mailto:kent%2Bietf@watsen.net>> wrote:

>IMO this draft overlaps the factory-default datastore.
>Unfortunately, RFC 8808 does not document NMDA, Appendix A3 details
>https://datatracker.ietf.org/doc/html/rfc8342#appendix-A.3
>It does not say if <factory-default> datastore feeds into <running> or into <intended>.
>It is not clear how <system> would interact with other datastores.
[Qin]: As described in Appendix-A.3, two ways to interact with other datastore are discussed, one is interact implicitly, the other is to use
RPC to trigger application of the datastore's data, in factory default setting case, <factory-reset> rpc will reset the contents of all relevant datastores to factory default state.
The extreme case of factory default state is no configuration at all for each datastore.

Right.  Also, the word “flow” doesn’t seem quite right…at least in my mind, it suggests an ongoing relationship, whereas <factory-default> is really for one-time initializations.

From https://datatracker.ietf.org/doc/html/rfc8808#section-3:

   Management operations:  The contents of the datastore is set by the
      server in an implementation-dependent manner.  The contents cannot
      be changed by management operations via the Network Configuration
      Protocol (NETCONF), RESTCONF, the CLI, etc., unless specialized,
      dedicated operations are provided.  The datastore can be read
      using the standard NETCONF/RESTCONF protocol operations.  The
      "factory-reset" operation copies the factory default contents to
      <running> and, if present, <startup> and/or <candidate>.  The
      contents of these datastores is then propagated automatically to
      any other read-only datastores, e.g., <intended> and
      <operational>.



>It is not clear why it is even needed since <factory-default> contains only system settings.
[Qin]: I agree <factory-default> could have system setting. But unspecified for some reasons.
Based on earlier discussion on factory default, what content is included in <factory-default> and how to format this content, e.g., YANG instance file format
Have been ruled out of the scope. See the diff in v-07
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-factory-default-07.txt


Regardless, <factory-default> cannot be used for immutable “system" defined objects, since it’s contents initialize client-editable datastores.


K.


_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod