Subject: [Netconf] zerotouch discussion (was: NETCONF call home and new port assignment)

From: Kent Watsen <[email-masked]>
Date: Tue, 25 Feb 2014 20:26:47 +0000

[subject line changed]

On 2/25/14 12:06 PM, "Reinaldo Penno (repenno)" <[email-masked]> wrote:

>I have some comments on this draft.
>
>Since the draft proposes a ³cold² reverse connection I was expecting some
>discussion on the traversal of middleboxes. Given folks that have been
>deploying NMS implicitly take for granted that connections are always
>inside->out, with the exception of SNMP traps, such a draft should assume
>some pitfalls and suggest ways around them. In the case of SNMP for
>example, the ³solution² is firewalls/NATs that implement SNMP ALG, but
>even then, a first inside->outside connection is expected.

Now I'm confused, by inside->outside you mean NMS->device, right?  - this
would be, for instance, an SP managing Internet routers, yes?   If so,
then I understand that static addressing is the norm, but automatic
deployment (zerotouch) is still useful for initial discovery, at which
point the device would likely have its call-home configuration removed and
configuration enabling the NMS to login added.  In either case, it's fair
to say that it's implicit in the solution that the NMS is reachable using
TCP.  It won't do if the NMS is behind a NAT...

>Some points to consider:
>
>- The NMS IP address downloaded from config server can not be behind a
>firewall unless there is some pinhole or traversal method the device can
>Use

True, it is required the device be able to TCP to the NMS's IP address and
port.

>- If NMS is behind a NAT, the IP:port should be the outside and stable.

Sure.

>- In the worst case maybe configuration server (which theoretically could
>be reached by both parties) could d server as a relay.

I'm not following the need for middle-boxes - at least not in the solution
defined by IETF.  If a particular deployment needs middle boxes, then it
can set them up and have the devices zerotouch to it instead of to the
actual NMS - does that make sense?

>- If a NAT exists between NMS and device, one can not assume registered
>ports will be available.  Therefore config server needs to be able to send
>port information.

This is already the case, ports can be specified in the ZeroTouch
Configlet.

>- Device should be prepared to check with configuration server is external
>port has changed due to state being removed on the NAT.

The solution is for the device to check with the configuration server
*every* time it boots for a default factory configuration.  In order for
the device to receive a new value, the configuration server needs to be
updated first and then the device rebooted again.

Thanks,
Kent

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 25 Feb 2014 20:32:43 +0000

Wouldn¹t that shave some of the value of zero touch?

It would be good to insert a clause recommending device re-checks with
config server in case it can not establish connection to NMS.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 25 Feb 2014 20:41:38 +0000

Yes, but it would require manual configuration on possibly several
middleboxes.

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 Feb 2014 20:43:43 +0000

>config server in case it can not establish connection to NMS.

Ah, you're talking about the case where the device was able to find and
load a Configlet, but it contained faulty values.  You have a point,
clearly the device should have some recourse for this case...

Normally, a device unable to find a Configlet would ultimately do a normal
boot, as it's most likely an admin is waiting to log into it.  In this
case, the device has trigger logic hat should essentially tells it to run
headless, so forever checking for an updated Configlet may be appropriate.

I don't know, "forever" looping doesn't sound right.  And waiting even a
few minutes is unlikely to produce a new Configlet, given that it's an
automated system and the NMS will have no alert for a device failing to
connect, and hence it's unlikely the Configlet will get fixed so quickly.

What do you think?

Thanks,
Kent

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 25 Feb 2014 20:52:54 +0000

>clearly the device should have some recourse for this case...

Or if the connection is not permanent, it might try to connect again after
some time and for some reason it can not.

>headless, so forever checking for an updated Configlet may be appropriate.

Some suggestions (not mutually exclusive):

- Given device has credentials to download a configlet maybe it should be
able to “post” something as well: “I’m device ABC and can not connect to
NMS” (see below about relay).

- Connection to configlet is HTTP (or some other protocol that allows
notifications) and server could send a notification when something changes.

- And the the least common denominator is to perform periodic (or
exponential back off checks) until some ceiling.

>connect, and hence it's unlikely the Configlet will get fixed so quickly.

If configlet server is reachable by both parties, then it could relay
messages from one to the other.

Otherwise, checking until a configured maximum level.

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 Feb 2014 21:10:16 +0000

>some time and for some reason it can not.

Since you said "connect again", it's not ZeroTouch, but it is still
Call-Home, the configuration for which is described in
draft-kwatsen-netconf-server.  As you can see, for high-availablilty, it
enables a list of server IP/port values to be specified.

>able to ³post² something as well: ³I¹m device ABC and can not connect to
>NMS² (see below about relay).

Well, the device has a private key that could be used to sign a message it
POSTs back to the Configuration Server, which could authenticate the
message before writing it - seems possible, but would need to be added to
the draft.

>notifications) and server could send a notification when something

I didn't follow this - who is send what and how?

>exponential back off checks) until some ceiling.

Well, this is what I was getting at before, a ceiling of 5 minutes
probably isn't enough, while any longer may be too much...

>messages from one to the other.

While it's true that the device can connect to it, it's not (currently)
the case that the NMS is.  The draft says that the Configuration Server's
admin-facing interface is unspecified, thus there's no standard for a NMS
to use.

K.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 25 Feb 2014 21:35:47 +0000

On 2/25/14, 1:10 PM, "Kent Watsen" <[email-masked]> wrote:

>Since you said "connect again", it's not ZeroTouch,

The definition of “ZeroTouch” is not clear. This is a term I usually
associate with Bonjour where there is full decentralization (mDNS) and
built-in failure recovery. In this case one could argue this solution is
not ZerouTouch. 

There it seems to me this solution should assume failures/changes and
provide protection from it in the protocol instead of just assuming you
have more of the same.

>but it is still

See discussion above.  Can we provide names instead of addresses?

>I didn't follow this - who is send what and how?

Configlet server is a HTTP server, device is HTTP client. HTTP server send
server-side notification to client when configlet changes.

>probably isn't enough, while any longer may be too much...

Well, in the first 1 minute or so TCP will retry on its own until it gives
up.

After that if client retries every N (2-5) minutes I would not be
concerned with any scalability issues.

---

From: Kent Watsen <[email-masked]>
Date: Tue, 25 Feb 2014 21:50:31 +0000

>The definition of ³ZeroTouch² is not clear. This is a term I usually

Formally, we're talking about "NETCONF Zero Touch".

>provide protection from it in the protocol instead of just assuming you

Suggestions welcomed!

>See discussion above.  Can we provide names instead of addresses?

Yes, of course, any URI is supported.

>server-side notification to client when configlet changes.

Excellent, it's clear now.   But it's questionable value over the device
polling the server.  Besides, how would it work for non-HTTP based
Configuration servers?  (FTP, SCP, etc.)

>concerned with any scalability issues.

Not a scalability issue for me, it's a "what's the right thing" to do
issue.  
Maybe this needs to be configurable?  Do you have a suggestion for text to
add to the draft?

K.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Tue, 25 Feb 2014 22:07:10 +0000

I guess it would not work. It is a choice of which protocol to use. If
HTTP is used you get this capability (possibly even through RESTconf),
other protocols are outside the scope.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 26 Feb 2014 18:48:51 +0000

I am compiling my test suggestions and will send shortly.