Re: [Netconf] draft-ietf-netconf-zerotouch-21 feedback

Kent Watsen <> Fri, 18 May 2018 20:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B940112E03C for <>; Fri, 18 May 2018 13:40:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GS_mr5VTCuSE for <>; Fri, 18 May 2018 13:40:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC6F312DFDB for <>; Fri, 18 May 2018 13:40:26 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id w4IKdeKr018084; Fri, 18 May 2018 13:40:25 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=aaIZGIBv+MRvopm46XYBEyph28Pf2yQbgOphvy+9eoY=; b=E9ajfctrmc2jL0VWbJKXvr7lCGMGrYrB0zpwhuTkXsQU96L42gdnPVDbZZ1vkUF7ED0P QbvVTKyD0+kmowLyYBUtGKpfUB+afSZxt7c8huAWXDRirSFqOKaVExYFJRpAv5ULgeuI U+hqvueu3e9pzmJXI3ULozl1vkniKvHSYtmvbRuf8QOW/BdtxFcDv5A/G5V83Xf5SzSy E+ONogx4KFNrrV0D9A8O/MOW83oq7mW63tbpnpXUOGdivyzNzmWArHWpZI/z80IZ5yiR e3vU5atcZvbKIk7vCtGG+MxAT7rTA1oNR5gXdYUh8lUQw5sT7sD2+6l7xcN3k/MJFnDc pQ==
Received: from ( []) by with ESMTP id 2j23u907xk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 18 May 2018 13:40:25 -0700
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.797.5; Fri, 18 May 2018 20:40:23 +0000
Received: from ([fe80::5c50:c79f:dbd0:7a9a]) by ([fe80::5c50:c79f:dbd0:7a9a%13]) with mapi id 15.20.0776.008; Fri, 18 May 2018 20:40:23 +0000
From: Kent Watsen <>
To: Tarko Tikan <>, "" <>
Thread-Topic: [Netconf] draft-ietf-netconf-zerotouch-21 feedback
Thread-Index: AQHTuKJS4H3M9M3UeU67f5nGH6uty6PMrZiAgAm50YCAARlRgIAOINgAgFB6/QA=
Date: Fri, 18 May 2018 20:40:23 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4584; 7:Ar8pAKxXz96gP9vh16kaEo8S8fWg8OfdMoipiRVoLiGlLWgnlo8bNeduxRAjp+gGC0WgXBZ1+2E/lKcV0f71Cs+t7hjhcgVbXogzDwjcrmKpTjPPrvGCBSWuDxzBWJL7JskF5z5JY4Fr8Rwyf2toP/yOeE27N4UvRpUPEEPRduerb39yUNLY5W9gauoIZZDWVxDhBQ4H5MrxuhOuB6008gZJBtNp8hCvvVItDknmx/5yAxmtt2BVeT0oY74F9v+a
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4584;
x-ms-traffictypediagnostic: BYAPR05MB4584:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(60795455431006)(158342451672863);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4584; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4584;
x-forefront-prvs: 0676F530A9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(39860400002)(39380400002)(366004)(199004)(189003)(40224003)(26005)(82746002)(229853002)(186003)(316002)(76176011)(106356001)(478600001)(5250100002)(93886005)(99286004)(105586002)(83716003)(5660300001)(6512007)(86362001)(66066001)(2501003)(2906002)(53936002)(8936002)(68736007)(14454004)(3660700001)(33656002)(3846002)(3280700002)(7736002)(6116002)(6246003)(305945005)(486006)(36756003)(6506007)(110136005)(97736004)(59450400001)(2900100001)(6486002)(102836004)(58126008)(6436002)(11346002)(8676002)(25786009)(81166006)(81156014)(446003)(2616005)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4584;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: qssrMJloeWQfOzkyFqdGqlw4ysa2QU6Sw5xRS8+uOHJ8jRPR7IMQXX7HnKFmQt0aV+RPucjDJ8ld8U41D7NOPSStDxTb0LQ9vhe5A8qfKoVIei3ixWQjDV9ZYuxrkKL638xBYbM3zEPRNu6FXbfEwZtUaKGNNluQhOd1GsWSwoTxKUlKAKVuGUfNJOgpTnaQ
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: a482a7ca-6c3c-4475-10a0-08d5bcff9460
X-MS-Exchange-CrossTenant-Network-Message-Id: a482a7ca-6c3c-4475-10a0-08d5bcff9460
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2018 20:40:23.4174 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4584
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-18_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805180218
Archived-At: <>
Subject: Re: [Netconf] draft-ietf-netconf-zerotouch-21 feedback
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 18 May 2018 20:40:29 -0000

Hi Tarko,

I apologize for not replying earlier; somehow this thread dropped off my radar…

>> This draft does not enable putting an "owner CA trust anchor" on a device
>> from manufacturing.  Section 5.1 describes devices possessing a list of
>> trust anchor certs for *well-known* bootstrap servers and issuers of
>> ownership vouchers.  By well-known, we mean something along the lines
>> of a MASA (manufacturer assured signing authority), not a deployment-
>> specific trust anchor for a specific owner.
> OK, fair enough. I'm not sure how this will work out in L3VPN/private 
> management scenarios where internet access might not be available.

I can think of two options.  First, as described by this draft, private networks can be supported by signing the zero touch information artifact and then enabling it to be accessed by any number of mechanisms (e.g., Section 4 in -21) within the local network.  Next, outside the scope of this draft, and decidedly not *zero* touch, the vendor may provide an option for the devices to be pre-staged to go to a different default bootstrap server (i.e. override items #3 and #4 in Section 5.1 of -21).


>> You started this saying that the device may have multiple ZTP capable
>> interfaces and it's not known which interface might be used during
>> installation.  It's important to note that SZTP-itself doesn't care
>> which interface is used to get the bootstrapping data (it can even
>> be read off a removable storage device).  What matters is what
>> interface(s) the initial config needs to configure, which may not
>> necessarily be the same as the interface used for the SZTP call.
>> My claim is that this is fairly predictable within a deployment,
>> such that canned responses work great.  Can you provide a more
>> concrete example where this doesn't work?
> Agree about the ZTP interface part and in most cases, the interface 
> thats being used for ZTP bootstrapping, is the interface thats needs to 
> be used towards the SP network.
> Concrete example where you cannot predict the interface is device with 
> 1G copper and 1G SFP interface. Either can be used based on customer 
> location:
> - customer colocated at the AN site = use copper
> - customer connected to AN via fiber = use SFP

This is a difficult to do much about because in both cases, I assume, it could be the exact same device.  Perhaps the device itself could sense which interface (copper or SFP) is "up", and then pass that information as an input parameter to the get-bootstrapping-data RPC (tree diagram in Section 7.1 of -21) such that then the bootstrap server can return a correct response accordingly.  Another option, outside the scope of this draft, is that the deployment's NMS/controller had modelled the network beforehand, and knows that the specific serial number was collocated-at or connected-to the AN, and therefore sends the right initial configuration that way.

> tarko

Kent // contributor