Re: [Netconf] activate-configured-subecription - WGLC subscribed-notifications-16

["Eric Voit (evoit)" <[e-mail]>]

> From: Martin Bjorklund, September 19, 2018 2:38 AM
> 
> Hi,
> 
> "Eric Voit (evoit)" <[e-mail]> wrote:
> > Hi Douglas,
> >
> > From: Douglas Hubler, September 18, 2018 5:35 PM
> >
> >
> > On Tue, Sep 18, 2018 at 3:40 PM Martin Bjorklund
> > <[e-mail]<mailto:[e-mail]>> wrote:
> > So it seems you support my point to make this draft use SSE.  Then if
> > you use HTTP/2 you (the client) can simply create one HTTP/2 stream
> > per notification stream.  This just falls out for free with HTTP/2.
> >
> > yes, with caveat that I haven't attempted actual implementation yet.
> >
> > <Eric> Agree that SSE over HTTP2 should work.  However to me using SSE
> > here seems redundant as HTTP2 provides the necessary mechanisms.
> 
> Eric, can you explain how this would work w/o SSE?  Which mechanism in
> HTTP/2 are you referring to?

After an HTTP2 OK, the HTTP2 server has the ability to forward an unbounded number of HTTP2 Data Frames on the HTTP2 stream.  The stream is not considered complete until an END_STREAM is passed.   (Note this is independent of anything regarding HTTP2's PUSH_PROMISE.)

You can see an example flow in Figure 1 of draft-ietf-netconf-restconf-notif.  At IETF 97 we asked for some Feedback on this proposal. 
http://www.voit.org/IETF/Subscriptions-NETCONF-IETF97.ppt (see slide 14).
But I am not sure how much effort the WG should place here.   The work here is several years old, and the market has moved substantially since then.

> > But
> > I won’t get in the way if people really do want to go in this
> > direction.
> >
> > > I don't understand the details surrounding using an RPC to make a
> > > dynamic subscription.  Unless it's optional, then I can start to
> > > understand.
> >
> > The client would POST to the "rpc" establish-subscripion, and in the
> > reply to the POST is a "location" leaf (*) that contains a URI.  The
> > client then GET this URI; this is the SSE event stream.
> >
> > I see.  But if a client reads the YANG as
> >
> >  module my-module {
> >     ...
> >     notification my-event {
> >     }
> > }
> >
> > and client knew base stream URI was:
> >
> >    /restconf/my-streams
> >
> > Couldn't the client then deduce SSE URL as:
> >
> >  GET  /restconf/my-streams/my-module:my-event?...
> 
> No.
> 
> With RFC 8040, the SSE URL is "stable", and if the client has read it onve, it
> doesn't have to read it again (modulo some definition of "stable").  The client
> can pass a filter in the GET request for the SSE stream.
> 
> With the mechanism in this draft, the SSE URL will vary for each request that
> has a different filter (at a minimum), since the filter is passed a parameter to
> "establish-subscription" and the SSE URL is sent back in the reply to "establish-
> subscription".  With the SSE URL, the server may hide some state that
> corresponds to the filter params etc.  (NOTE the word *may* in the previous
> sentence.  A server could as well send back a SSE URL with the filter
> parameters embedded in the
> URL...)
> 
> So in general, a client cannot assume that it can re-use a SSE URL that was
> returned from a call to "establish-subscription".
> 
> > Thereby saving a trip to server?
> >
> > <Eric> Yes, it would be possible to set something up to deduce the
> > URL.  draft-ietf-netconf-restconf-notif doesn’t currently attempt this
> > as being able to deduce the URL doesn’t stop the extra trip to the
> > server.
> >
> > The reason it doesn’t get rid of the extra round trip has to do with
> > HTTP2 streams.  If we are going to use HTTP2, there is still a need to
> > initiate the GET (or POST) in a separate stream other than the one
> > being used for RESTCONF signaling.
> 
> I disagree.  If the client wants to have a separate HTTP/2 stream for the notifs,
> then it should start such a stream.  If the client doesn't want a separate HTTP/2
> stream then that should be ok too.

Per your below, once SSE is applied a stream is blocked.  For that subscription, you still need to support 'modify-subscription' and 'delete-subscription' rpcs.

Beyond that, one thing to keep an eye on is the potential for bundling of event records from different subscriptions into a single transmittable notification message.  (Something like in draft-ietf-netconf-notification-messages.)   Anywhere such bundling occurs, the publisher will have to use a consistent HTTP2 stream across a set of subscriptions in order to preserve event record ordering.  In addition, all event records bundled will have to consistently use the same DSCP.

Note: this is another reason why it is a good idea to use separate HTTP2 streams for RESTCONF subscription RPC interactions, and for the streaming of event records.

> Compare to NETCONF.  HTTP/2 streams are similar to SSH channels.  A
> NETCONF client can open a separate SSH channel for each subscription, or it
> can use a single channel.  Up to the client.

HTTP2 streams have far less overhead, lower setup latency, and more scalability than separate SSH channels.
 
> > Someone could write a specification which gets around this by forcing
> > every RESTCONF transaction on its own HTTP2 stream.  But nobody has
> > proposed such a specification.  Plus there are QoS scenarios where you
> > might want multiple subscriptions on the same HTTP2 stream.
> 
> How would this work?  Once you start SSE on a stream, that stream is
> "blocked", right?

And per above, this is a good reason to separate RESTCONF subscription RPCs from the HTTP2 stream used for events.   (The way it could be done is have modify-subscription and delete-subscriptions come in on a different stream, impacting the HTTP2 stream where establish-subscription started things off.  Again I am not recommending this for multiple reasons.)
 
> > So if
> > someone wanted this, we would still need to refine
> > draft-ietf-netconf-restconf-notif requirements with the ability to
> > modify or delete an existing subscription on a different HTTP2 stream.
> 
> Isn't this how it is supposed to work? 

Yes.  My point was that nobody has proposed refining the spec to forcing of each RESTCONF transaction on different HTTP2 streams.

> The draft is silent on how to delete a
> subscription, and also on how modify-subscription is supposed to work.

Certainly these can come in on a different HTTP2 stream.
 
> The draft is also silent on the lifetime of the result of "establish-subscription".
> With NETCONF, the subscription ends if the session ends, but in RESTCONF
> there are no sessions, so how long does the subscription live after it has been
> created?

There are mechanisms defined.  See 
draft-ietf-netconf-restconf-notif, Section 3.1. 
and
draft-ietf-netconf-subscribed-notifications, sections 1.3 & 5.3.

Eric

> Note that the approach in RFC 8040 is doesn't have this issue.
> 
> 
> /martin
> 
> 
> > This could be done of course, but someone would need to drive the
> > definition.
> >
> > Eric
> >
> >
> > Would it be wrong for a client to make any assumptions?  I realize
> > this ASSUMEs a transport protocol, but could/would there be a
> > one-time, capability check the client could make to test for available
> > transports?
> >
> > I really appreciate your time explaining, I have been following the
> > emails best I could but I think some basic things are still eluding
> > me.
> >