IETF Logo Mail Archive

Re: [netmod] [netconf] WG Last Call: draft-ietf-netmod-factory-default-05

"Joe Clarke (jclarke)" <jclarke@cisco.com> Tue, 19 November 2019 09:20 UTC

Return-Path: <jclarke@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 DDD3512089B; Tue, 19 Nov 2019 01:20:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=EhmRD7ha; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YxzaSHSZ
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 W2JvgC34Lt7b; Tue, 19 Nov 2019 01:20:52 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F8E120897; Tue, 19 Nov 2019 01:20:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10163; q=dns/txt; s=iport; t=1574155230; x=1575364830; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YKWFWDi/1W5GfmQ47jsitP/BWagUa1ezU7tSKv6YCAU=; b=EhmRD7hap3jDF/3n2R7bAJFChym3jC5Ma+9LOeeCV6/r6MfhWNHyiGfF 3eu8PRNwEIutvmXQpktx+/2mEDN4mTshHMZQtyKtRvD1o9CXzgk2tSUFR Y5PTmtRyTQdw1IRdk8V35VBae/3b8XL38FpIZ0lguMSEM/4btKOQ5iCGr E=;
IronPort-PHdr: 9a23:7RlHmRbIhAtQC2QmVPgz3Kj/LSx94ef9IxIV55w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn1NksAKh0olCc+BB1f8KavoZCgzBsdPfFRk5Hq8d0NSHZW2ag==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DPAACPs9Nd/4gNJK1lHAEBAQEBBwEBEQEEBAEBgWwFAQELAYEbL1AFgUQgBAsqhCqDRgOKdYI5k0OEYoEuFIEQA1QJAQEBDAEBLQIBAYRAAheCDSQ2Bw4CAwsBAQQBAQECAQUEbYU3DIVSAgEDEhEdAQE3AQ8CAQgONAICAjAlAQEEDieDAIF6TQMuAaUxAoE4iGB1gTKCfgEBBYUFGIIXCYE2AYwUGIFAP4ERJwwTgkw+hC6DJzKCLJAThUeYUwqCKpVPG5oRqFACBAIEBQIOAQEFgVkDL4FYcBVlAYJBUBEUgjeOYwwXg1CKU3SBKI0uAQE
X-IronPort-AV: E=Sophos;i="5.68,322,1569283200"; d="scan'208,217";a="373615046"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Nov 2019 09:20:28 +0000
Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id xAJ9KST0019918 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Nov 2019 09:20:28 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Nov 2019 03:20:28 -0600
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Nov 2019 03:20:27 -0600
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 19 Nov 2019 03:20:27 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MInvs+Sqas1MHWFuVSmEDnN0ihhX3htVjfSf9/8RGxlb8blt8/gXTIII574imB+JOZVDKzkcdnC+P1Q2kwRMjxkc/ND2Pe57buZdCqgRsN4dUkXopg0qLl5huj8rkFRs9IZWNEST4m/wdEWvoXLhRLVz7oMOTJQ2OLLgWOkG1nFpnBKYtCfPWo6JM4kCHiDS0QZyWqphag5/VhNgnY4PxWdKgiOPQmDdUFHgOwiPckI7PbmsSmnZzHvfgHmffm92ndlobX4tdNCFI+63v97sQIVgUn9l03JjRDJpawEMWdZ685uz+4rB7Kptb9gM6BX2JsUfL+KvN9uOa7zT7h3DEQ==
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=YKWFWDi/1W5GfmQ47jsitP/BWagUa1ezU7tSKv6YCAU=; b=djaROdjU7HHCkieOBBvAc3ba8aLOYCQOs3rIqLpsK7RSD+5lbh0X8mQWH+tT6wbXAN0vmWWgQZbiWALGOv5b5U44Gr7toOx49lQNATLohCkd0EZHsN6BfcnTZzZ+Nv5zn3GFQvdbwXerpUe8OoHKl9tx37XOCe0pP6eYxvaR15NxFs+xxBJ47mxWSW6q1i72Z9zSjaXu3LubUktWMOhLuop2DEpMiIECSfmVHYVxDM82Gp+of9/5o2ilSVBxfX/T2vfBxo90Lk2Og++qZSK+hxZAW28W8Q9iia5EXhpFnbiL7Q3PecKGgu0yjUuFmEWmVN4NMrghsxXimJPnYLlbIg==
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=YKWFWDi/1W5GfmQ47jsitP/BWagUa1ezU7tSKv6YCAU=; b=YxzaSHSZr9GpbZJEJEtNz90TsQuMKuXI3TdxL1jItJtbDQ4+GmOppcyRCKoMZEiusNdAoi8jxCLHG4rbO/bTFijfYiaJlGN96ZRXvNt8NNICIlMQZEDre5a+0tAVP410towqzdN+EHRzEFB35g9Pk6gOXv33V55lX8osEUtOSx4=
Received: from MWHPR11MB1678.namprd11.prod.outlook.com (10.172.55.19) by MWHPR11MB1967.namprd11.prod.outlook.com (10.175.54.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Tue, 19 Nov 2019 09:20:26 +0000
Received: from MWHPR11MB1678.namprd11.prod.outlook.com ([fe80::a888:6f8:f445:697a]) by MWHPR11MB1678.namprd11.prod.outlook.com ([fe80::a888:6f8:f445:697a%3]) with mapi id 15.20.2451.031; Tue, 19 Nov 2019 09:20:26 +0000
From: "Joe Clarke (jclarke)" <jclarke@cisco.com>
To: Qin Wu <bill.wu@huawei.com>
CC: Kent Watsen <kent+ietf@watsen.net>, "netmod@ietf.org" <netmod@ietf.org>, "draft-ietf-netmod-factory-default@ietf.org" <draft-ietf-netmod-factory-default@ietf.org>
Thread-Topic: [netmod] [netconf] WG Last Call: draft-ietf-netmod-factory-default-05
Thread-Index: AdWd0qXxZf7a+zyeQkaNUTFpf5/BMQA5+1iA
Date: Tue, 19 Nov 2019 09:20:26 +0000
Message-ID: <B804410B-9080-41E6-9959-587B6C2295B1@cisco.com>
References: <B8F9A780D330094D99AF023C5877DABAA945C44C@dggeml511-mbx.china.huawei.com>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAA945C44C@dggeml511-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jclarke@cisco.com;
x-originating-ip: [2001:420:c0c4:1003::16]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3ed8671d-5bdc-4cb1-6c85-08d76cd1b6b3
x-ms-traffictypediagnostic: MWHPR11MB1967:
x-microsoft-antispam-prvs: <MWHPR11MB196728152B7DC1CEA1A32C82B84C0@MWHPR11MB1967.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 022649CC2C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(366004)(396003)(346002)(39860400002)(189003)(199004)(36756003)(71190400001)(6916009)(86362001)(71200400001)(478600001)(6512007)(6116002)(54896002)(6246003)(229853002)(99286004)(316002)(6436002)(54906003)(6486002)(81166006)(81156014)(14454004)(7736002)(4326008)(8676002)(8936002)(2906002)(446003)(5660300002)(2616005)(186003)(11346002)(476003)(256004)(14444005)(76116006)(46003)(66476007)(66946007)(76176011)(6506007)(33656002)(91956017)(102836004)(486006)(66446008)(64756008)(25786009)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1967; H:MWHPR11MB1678.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Mfo0IunqKlz7+ZJfNJfWpKE/wK6vNyrbu3gG/TDGdcWTHr+e/5z8JYJ/DXTphiJhlBzLGwcorK47aJsZ/L97yWtRQyni+4PwYv4ezMdrLPm1yG0Smom9u9NtjnxSHfA4o6vgbWL0GYWL9C/IeeQYCEQqazLRbRefqeYlHh8nlblQfoDm68GfFW55e9iZ5kfGdn68M4TJgYV/M+Mr8QORPu/us6Eax3GppJvDYXwriZl2un7FUpl3C9sBV0zeWxmaJgwaxkuQdxztcX7s9EAEazwTl+4a2Gbk/3sGtmdZCY6Fd6ybiSuduoqKA0flyJIH6c/FXGgpF9b/16cjpcO94csAdkQZBDUYXH32R13h34XXrxg+ysWyT5w9cw2HeOY3ARL8KH3Tqi2p+1g3NKHTgwBMAmSIgr6IiTXIrGTHFiit+qNmRkAKwLsUQ6PuvS/i
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_B804410B908041E69959587B6C2295B1ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3ed8671d-5bdc-4cb1-6c85-08d76cd1b6b3
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 09:20:26.4891 (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: Zw11mQsjy4+wSFlQNprDWAfarfKEDGUw6j1SVU3pPcSMT4nUZGihPG1VU9sdP/8M7Tey13S7pTyQlmpmHIOLnw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1967
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/6ZkIRMKPOTVqMsLtAEqrMshU6LI>
Subject: Re: [netmod] [netconf] WG Last Call: draft-ietf-netmod-factory-default-05
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: Tue, 19 Nov 2019 09:20:57 -0000

[Qin]: Yes, resetting processes or restarting node did cover ZTP part, from Martin’s comment, I feel we don’t need to tie resetting process with RFC8572, since RFC8572 actually focuses on SZTP.
Actually we may have a lot of legacy ZTP mechanism we can leverage, I am not sure which reference I should stick to. Make sense?

It does.  You should remove the informative reference.


More importantly, though, how do you see this practically being implemented?  With an ops dir hat, I’m walking through Section 2, and sending a factory-reset RPC to a device.  The device immediately resets <running> to default and <operational> to some similar default state.  The device has become unreachable within the network.  A reboot or other reset is optional to implement, so as an operator I’m not really sure what to expect at this point.

[Qin]:I am not sure we should make restart or reboot as mandatory after factory-reset rpc, I think factory-reset rpc affects kernel level, it will be good not to restart the node, if it touches hardware level, it is be important to reboot or restart the node. Another angle we can have is if factory-reset rpc is executed in the trust environment, it may be not necessary to restart the node or root.

Here’s my use case.  I have a switch that has a config (including a management IP [OOB or IB]).  When I send it the factory-default RPC, I now have a switch in the network I cannot reach.  It continues to run, but with a factory default config (which doesn’t include the management IP).  I now have a problem.  Sure, the switch may not need to reboot.  It might immediately do DHCP and begin a bootstrap workflow.  It may need a reboot to do that.

What I was asking is does it make sense to add some Operational Considerations text to let implementors and operators know about these types of things and encourage them (vendors in particular) to do think about how they will implement factory-default to ensure that these types of processes can be restarted without additional user intervention?

Joe

v2.23.0 | Report a Bug | By Email