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

[Kent Watsen <[e-mail]>]

Hi Tarko,


> I was pointed towards this draft during a discussion around operational 
> problems in current ZTP world. This is my feedback from mid-sized SP who 
> would like to use this draft as soon it is implemented.

Thanks for the feedback.


> 1) Not many SPs buy their higher-end devices (used for enterprise 
> services, L3VPNs etc.) in big quantities. Due to smaller quantities, 
> they are not available customized from the manufacturer. Hence the
> need for proper ZTP.

Sounds familiar.


> 1.1) Many times the devices are bought via distributors without direct 
> interaction between manufacturer and SP.

Understood.  The draft doesn't standardize an ownership-tracking solution.
It is left to the manufacturers to devise a strategy that works well with
how their devices are sold and used.


> I might be mistaken but currently it looks like secure bootstrap is not 
> possible without properly precustomized devices. If hw-model, os-name 
> etc. are not sent in get-bootstrapping-data in untrusted mode it becomes 
> impossible to generate correct configuration for the device.

I'm curious what you mean by the first sentence.  Looking to the 2nd
sentence for clues, be aware that those three input parameters are
optional and only needed in select cases.  When get-bootstrapping-data is 
sent to an untrusted bootstrap server, the primary input is the device's
authentication credentials (e.g., TLS-level client certificate) with
which the bootstrap server can use to return signed data.  Please take 
a look at Appendix A (Promoting a Connection from Untrusted to Trusted).


> 2) Currently used ZTP interface information should be sent in 
> get-bootstrapping-data. Minimally ifName and vlan ID (for the scenarios 
> where ZTP DHCP client sends out DHCP discovery on all 4k vlan IDs).
>
> This is required for devices that might have multiple ZTP capable 
> interfaces (router with DSL and SFP interface for example) and it's not 
> known which interface might be used during installation. Without this 
> information it again becomes impossible to generate correct 
> configuration for the device.

I see.  One or more additional input parameters would be needed to 
address this.  Do you think a single parameter "interface" (the name
of the ZTP interface used) would suffice, or perhaps a generic "opaque"
parameter for a vendor-specific text format would be more flexible?
Currently, if needed, vendors could define a vendor-specific parameters
but, of course, that could affect interoperability - as not all bootstrap
servers will handle the additional input the same way.


> 3) zerotouch/enabled? MUST be restored to "true" when device is 
> reset to factory config using a push-button or CLI command. There 
> have been negative examples where even factory default customization
> is wiped clean during the push-button factory reset.

True, and it is the intention of the draft to enable devices to be
"reset" in the field, thereby returning them to their initial states,
as described in Section 5.   Perhaps the draft isn't saying this 
clearly enough?  Please let us know which section you were looking
at when thinking this.


> Thanks to the authors for the work, it's good to see work being done in 
> this, still operationally problematic, area.

Cheers,
Kent

> -- 
> tarko