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

From: Kent Watsen <[email-masked]>
Date: Fri, 18 May 2018 20:40:23 +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).

<snip/>

>> 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