Subject: [Netconf] lmap restconf proposal (push vs. pull)

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Sep 2014 18:51:14 +0200

Hi,

I am sitting in the LMAP interim meeting and there is an I-D proposing
to use RESTCONF, but it kind of changes the roles of the RESTCONF
client and server.

    draft-oslebo-lmap-control-yang-00.txt

My traditional understanding of RESTCONF is that it more or less
follows NETCONF in the sense that the to be configured device runs a
RESTCONF server and the RESTCONF client pushes config to the RESTCONF
server on the device. The I-D mentioned above uses a pull model where
the device to be configured runs a RESTCONF client getting its
configuration from a RESTCONF server. The RESTCONF server in this case
acts as a configuration server providing the configuration to a number
of clients, each one pulling it via GETs as needed.

The motivation for all this are devices sitting behind NATs and so
this overlaps perhaps also with NETCONF configlets. Anyway, I wanted
to start a thread here in order to hear what RESTCONF experts thing
about this.

/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: Kent Watsen <[email-masked]>
Date: Mon, 15 Sep 2014 18:16:57 +0000

To support devices behind NATs with RESTCONF, we should use the TLS
call-home strategy.  That is, the device initiates a TCP connection to the
northbound system, which in turn starts HTTPS.  Note that the TCP/TLS
connection can be long-lived while the HTTP protocol is start/stopped many
times.

Using call-home this way is preferred for the same reasons why its
preferred for SSH and TLS transports for NETCONF - because it preserves
the directionality of the authentication mechanisms.

I know RESTCONF call-home came up and was shot down in Toronto, but I
think that was done erroneously and the decision re-examined.

Kent

On 9/15/14, 12:51 PM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

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

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 15 Sep 2014 15:05:02 -0400

> think that was done erroneously and the decision re-examined.

+1.

-- Jeff

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 15 Sep 2014 14:46:21 -0700

+1.

and FWIW a feature in current design in Opendaylight.

In our current thinking device uses one of the many NAT traversal 
techniques available to procure a stable public ip:port. Then device 
conveys the IP:port in the RESTconf call home to the controller. 
Controller turns around and connect to server (used to be client) in 
that IP:port.

thanks,

---

From: Kent Watsen <[email-masked]>
Date: Mon, 15 Sep 2014 22:44:16 +0000

Hi Reinaldo,

I think you are describing something a bit different, what I might refer
to as "knocking". E.g. there are two separate TCP connections, one for the
HTTP connection from the NE to the controller (the knock) and another when
the controller connects back to the NE.   Did I capture your use-case
correctly?

The call-home that's been discussed for NETCONF differs in that there is
only one TCP connection, the one from the NE to the controller, *on top of
which* the controller runs whatever protocol is desired *as the client*.
That is, for the same TCP connection, the NE would start out as the TCP
client, but then switch to become the TLS server and then the HTTP server
(as each layer in the protocol stack is initialized).  See
draft-ietf-netconf-call-home for more details.

Admittedly, the current draft is just for NETCONF, but the exact same
strategy used for NETCONF TLS-transport could work for RESTCONF, the only
difference being that the controller would start HTTP rather than NETCONF.

What do you think, would it work for ODL? - is this for the Secure Network
BootStrapping project?

Thanks,
Kent

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 15 Sep 2014 16:04:06 -0700

> the controller connects back to the NE.   Did I capture your use-case

[RP] Yes.

> draft-ietf-netconf-call-home for more details.

[RP] Yes, I understand your proposal and we thought about using 
Websockets for that purpose. But we want to provide a call home using 
core HTTP 1.1 techniques such that almost every device out there that 
uses a Java/Python HTTP library (sensors, small appliances, etc) can 
make use of it right off the bat.  There are trade-offs amongst all 
possible solutions and would like to keep the discussion going.

---

From: Arne Oslebo <[email-masked]>
Date: Thu, 18 Sep 2014 14:27:53 +0200

> the directionality of the authentication mechanisms.
In LMAP the managed devices can be behind multiple NATs and firewalls so
there is a group consensus that HTTP with two-way SSL authentication
should be used and the devices should pull information from the
controller in a JSON format. The alternative to RESTCONF is to define a
LMAP specific REST API.

The LMAP information model maps very nicely to a YANG module and so far
it looks like RESTCONF has all the features that are needed. So the
question is whether this is an acceptable use of RESTCONF or if it is
better to do the work of defining a LMAP specific REST API that will
need to include many of the features already found in RESTCONF?

Arne