Subject: [Netconf] HTTP2 configured subscriptions, is RESTCONF call home necessary? (was RE: Anyone want just Configured Subscriptions?)

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 10 Jul 2018 23:52:54 +0000

Changing the thread title, as we have moved off the original topic...

> From: Kent Watsen, July 10, 2018 6:36 PM
> 

Adding back in Lou's comment before mine to provide the context needed to understand my answer...

>>> (Lou) or an an error when an unsolicited notification is received by a client that doesn't support it.  (optimizing for what I think suspect will be the common case in the long term...)

> > Effectively this is what draft-ietf-netconf-restconf-notif, section
> > 4.2 defines now.  A successful POST of a "subscription-started"
> > notification must occur before events are sent.  Failure to receiver
> > an OK for the POST means an error to the publisher.
> 
> But if we use RESTCONF Call Home, the receiver is the HTTP-client, can an HTTP
> client process a POST?

Considering Lou's comment, my response points out that a receiver must "OK" a "subscription-started" before the publisher can send events.  In this case the publisher is the HTTP2 client.  Otherwise there is an error.

Since there is no RESTCONF is needed at all for configured subscriptions, the function draft-ietf-netconf-restconf-notif needs to include is the safe establishment of a secure tunnel between Publisher (HTTP2 client) and Receiver (HTTP2 server).  Perhaps Call Home is not necessary at all here, and perhaps it is always safe for the publisher to initiate the encrypted tunnel.  We can debate the pros/cons of each scenario for sure.  Perhaps Call Home simply isn't needed here.  And that would be excellent.  My understanding is that Call Home does provide some protections here, so I left RESTCONF call-home in to spur this debate.

Assuming that someone does want call-home for configured subscription encrypted tunnel establishment, steps C1-C7 of RFC8071 remain the same.  It is just step C8 which changes so that a receiver starts to listening for the POST of notifications to its HTTP server rather than starting RESTCONF.   Likewise Steps S1-S5 and S7 of RFC8071 remain the same.  The only difference would be that step S6 initiates an HTTP2 client connection towards the receiver, and then POSTs a "subscription-started" notification.  These specifics absolutely do need to be in draft-ietf-netconf-restconf-notif.  They are not yet as I was awaiting this discussion first.

> > Some form of RESTCONF Call Home with capability advertisement could
> > also occur before the "subscription-started" POST.  However, this
> > advertisement of client capabilities might not be needed for all
> implementations.
> 
> I don't know how.  RESTCONF Call Home just starts the RESTCONF protocol,
> and there is no capability-exchange in RESTCONF.

I could have worded this better.  What I meant is that outside the current scope of draft-ietf-netconf-restconf-notif, some TBD exchange of receiver capabilities could be defined.  This would let the publisher know that sending a "subscription-started" is supported.   I don't believe this necessary/essential here, as you won't start pushing events until the receiver says "OK".

Eric

> Kent // contributor

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Jul 2018 17:14:15 -0700

On Tue, Jul 10, 2018 at 4:52 PM, Eric Voit (evoit) <
evoit=[email-masked]> wrote:

> >>> (Lou) or an an error when an unsolicited notification is received by a
> client that doesn't support it.  (optimizing for what I think suspect will
> be the common case in the long term...)
>
> Considering Lou's comment, my response points out that a receiver must
> "OK" a "subscription-started" before the publisher can send events.  In
> this case the publisher is the HTTP2 client.  Otherwise there is an error.
>
> Since there is no RESTCONF is needed at all for configured subscriptions,
> the function draft-ietf-netconf-restconf-notif needs to include is the
> safe establishment of a secure tunnel between Publisher (HTTP2 client) and
> Receiver (HTTP2 server).  Perhaps Call Home is not necessary at all here,
> and perhaps it is always safe for the publisher to initiate the encrypted
> tunnel.  We can debate the pros/cons of each scenario for sure.  Perhaps
> Call Home simply isn't needed here.  And that would be excellent.  My
> understanding is that Call Home does provide some protections here, so I
> left RESTCONF call-home in to spur this debate.
>
> Assuming that someone does want call-home for configured subscription
> encrypted tunnel establishment, steps C1-C7 of RFC8071 remain the same.  It
> is just step C8 which changes so that a receiver starts to listening for
> the POST of notifications to its HTTP server rather than starting
> RESTCONF.   Likewise Steps S1-S5 and S7 of RFC8071 remain the same.  The
> only difference would be that step S6 initiates an HTTP2 client connection
> towards the receiver, and then POSTs a "subscription-started"
> notification.  These specifics absolutely do need to be in
> draft-ietf-netconf-restconf-notif.  They are not yet as I was awaiting
> this discussion first.
>
> I could have worded this better.  What I meant is that outside the current
> scope of draft-ietf-netconf-restconf-notif, some TBD exchange of receiver
> capabilities could be defined.  This would let the publisher know that
> sending a "subscription-started" is supported.   I don't believe this
> necessary/essential here, as you won't start pushing events until the
> receiver says "OK".
>
>
It is very expensive to implement both HTTP client and server roles in both
peers.
IMO the existing RESTCONF SSE notifications need to be supported.

I am concerned that not enough reviews of configured notifications
are being done because it is a low priority for many vendors.
It is clearly redundant if CallHome is used, but potentially useful for
binary push and line-card push (UDP or TCP).

It is hard to say if the correct pieces are being defined now to support
fancy binary push standards later.

Eric

Andy

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 11 Jul 2018 00:27:28 +0000

From: Andy Bierman, July 10, 2018 8:14 PM

On Tue, Jul 10, 2018 at 4:52 PM, Eric Voit (evoit) <evoit=[email-masked]<mailto:evoit=[email-masked]>> wrote:
Changing the thread title, as we have moved off the original topic...

It is very expensive to implement both HTTP client and server roles in both peers.
IMO the existing RESTCONF SSE notifications need to be supported.

<Eric> See other thread.  I am looking for someone to champion existing RESTCONF SSE call flow / use case.   I can’t do it justice as I haven’t seen an implementation.

Eric

Eric

Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Jul 2018 07:43:56 +0200

Why is this discussion HTTP/2 specific?

What you are proposing in draft-ietf-netconf-restconf-notif-06.txt is
that you have a RC client using RPCs to push notification data to an
RC server. LMAP is doing something like this to send measurement
results to a collector. The point is that you do not need call home
for this but instead:

- you embed a RC client into the server on the device
- you embed a RC server into the client on the managing system
- you need to provision client config so that the device knows how
  and when to contact the server
- you define RPCs in a YANG model implemented by the RC server on
  the managing system do ship notification content towards the
  RC server on the managing system

This is what LMAP has done. In contrast, a call home solution does
not require additional clients and servers and instead you call home
and let the client start the notification stream, which is sent using
SSE as defined in RFC 8040.

/js

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