Subject: [Netconf] comments on draft-kwatsen-netconf-zerotouch-01

From: Martin Bjorklund <[email-masked]>
Date: Wed, 05 Mar 2014 16:08:05 +0000 (GMT)

Hi,

Here are some high-level comments on
draft-kwatsen-netconf-zerotouch-01.

Section 4.2 says:

   While initializing its networking, the device MAY receive some
   additional URIs for where a software image or configuration can be
   downloaded.  This draft does not define how such URIs MAY be
   exchanged, for instance, using DHCP options.

For this solution to be complete and interoperable, shouldn't we
define the DHCP option for configuration / configlets?

----

Also, for the same reason, shouldn't there be some mandatory URI
schemes (e.g. https/http)?

----

Section 4.2 also says:

   For URIs
   discovered while initializing its networking, the device MAY try both
   the raw URI as well as the permutation of it using its fingerprint.

Why is this not a MUST?  If I implement a configuration server, I'd
like to know where to put the configlets.

----

I don't think you should define a data model that is just copy &
pasted from ietf-system and ietf-netconf-server.  Instead, I suggest
that the configlet simply is an XML file with initial configuration
for the device, matching whatever data models the device supports.
This allows vendor-specific config, but also other standard config.
In order to fully support the zerotouch procedure (with call-home),
ietf-netconf-server and ietf-system MUST be supported by the device.
(but I am not sure this is actually needed...)

The XML file should be on "copy-config" format, i.e.:

  <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <system ...>
    </system>
    <netconf ...>
    </netconf>
    <!-- other config here -->
  </config>

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Mar 2014 17:53:12 +0100

> This allows vendor-specific config, but also other standard config.

I agree.

>     <!-- other config here -->

Yes, makes a lot of sense.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Joe Marcus Clarke <[email-masked]>
Date: Wed, 05 Mar 2014 14:27:36 -0500

> define the DHCP option for configuration / configlets?

This makes sense to me.

> schemes (e.g. https/http)?

I can understand this request from a user convenience standpoint, but 
have an MTI URI scheme may make this harder to adopt by vendors.  For 
DHCP, I can see having a standard option makes this much easier for 
users without putting too much burden on vendors, but forcing vendors to 
build out infrastructure for a specific protocol may be onerous.

That said, I would think http[s] would be the most commonly implemented 
protocol...

> like to know where to put the configlets.

Vendors would pick one of the locations, but I don't see why we would 
need the raw URI.  I know bulk configlets is something operators want, 
but in this manner we wouldn't be asserting any physical security, so I 
would think the fingerprint would need to be used.

Joe

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 5 Mar 2014 19:38:58 +0000

>> define the DHCP option for configuration / configlets?

Yes, this text stands out since without the discovery part the solution is
not complete. I would suggest using an Anycast address. DHCP is also okay,
but anycast allows any device (with or without DHCP netconf option) or
even any other method of self-provisioning to find Netconf client.

>That said, I would think http[s] would be the most commonly implemented

Right. The draft and some messages on this list alluded to FTP, HTTP or
some other protocol being possible. I would suggest making at least one of
them (HTTP) should? Must?

>_______________________________________________
>Netconf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Fri, 7 Mar 2014 17:36:01 +0000

> define the DHCP option for configuration / configlets?

Does this have to be defined in this draft, or can it be in a companion
draft?  Also, besides DHCP, is there anything else that needs to be scoped?

Reinaldo, you mentioned using an Anycast address - do you mean for cases
where the device is on the same subnet as a Configuration Server?  - how
would it work on the wire?

> schemes (e.g. https/http)?

OK, will add a MUST for https and http.

> like to know where to put the configlets.

Good point, this is under specified.  I think it needs to be "device
MUST first try the permutation of it using its fingerprint first and
then MUST try the raw URI.

Replying to Joe's comment, the raw URI is desirable for two reasons:

  1) the DHCP-server may provide a device-specific URI and that
     URI doesn't have to be indexed by the device's public key
     (e.g. it might use serial-number)

  2) the admin has a multi-device Configlet, the URI for which
     shouldn't be device-specific.

> (but I am not sure this is actually needed...)

Don't we need a specific data-model for Configlet in order to carve
out how unique identifier(s) are encoded?  The draft has an error,
it doesn't define unique identifiers are encoded - oops!

Regarding the Configlet containing other data-models, this sounds good
but I wonder about "merge" vs "replace"; currently the draft says that
the device merges the Configlet into it's factory default configuration,
but it seems that if a complete configuration were provided, it should
replace what the device has.  One way to resolve this would be to enable
a Configlet to specify how it is to be applied (another reason to have
a purpose-specific data-model)...

Thanks,
Kent

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 7 Mar 2014 18:02:12 +0000

In the case of Anycast configuration server can be anywhere. It is just like regular routing, but you have a special address (_not_ a private address).

For those that want this draft to solve the reverse NAT problem DHCP is probably not an option. Being behind a NAT means having a local DHCP server that is probably another administrative domain. ]And DHCP options are not relayed from one domain to another, there is no standard that dictates what should be done. 

________________________________________
From: Kent Watsen [[email-masked]]
Sent: Friday, March 07, 2014 9:36 AM
To: Reinaldo Penno (repenno); Joe Clarke (jclarke); Martin Bjorklund; [email-masked]
Subject: Re: [Netconf] comments on draft-kwatsen-netconf-zerotouch-01

Thanks,
Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 07 Mar 2014 19:50:47 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> draft?

A separate document is fine with me.  Then this document should
reference the other one.

> out how unique identifier(s) are encoded?

I don't understand what you mean.  Can you elaborate?

> a purpose-specific data-model)...

Well, this *could* be done in the XML file itself, e.g., by using the
nc:operation attribute:

   <nc:config xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
              nc:operation="merge">
     ...
   </nc:config>

But I think we could state that the config is merged, even if the file
contains more than just a subset of system and netconf-server.

/martin