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

[Kent Watsen <[e-mail]>]

[subject line changed]


On 2/25/14 12:06 PM, "Reinaldo Penno (repenno)" <[e-mail]> 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