Re: [Netconf] Subscription Use Cases

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

> From: Martin Bjorklund, December 9, 2016 10:30 AM
> 
> Andy Bierman <[e-mail]> wrote:
> > On Fri, Dec 9, 2016 at 5:33 AM, Martin Bjorklund <[e-mail]> wrote:
> >
> > > "Eric Voit (evoit)" <[e-mail]> wrote:
> > > > > From: Martin Bjorklund, December 9, 2016 3:27 AM
> > > > >
> > > > > "Eric Voit (evoit)" <[e-mail]> wrote:
> > > > > > Hi Martin,
> > > > > >
> > > > > > > From: Martin Bjorklund, December 8, 2016 4:08 AM
> > > > > > >
> > > > > > > I think your requirements below are more like driving forces
> > > > > > > for YANG push, right?  Is there any of these that affects
> > > > > > > the solution in RFC 5277?
> > > > > >
> > > > > > The majority of these cases need yang-push.  But yang push is
> > > > > > only possible when the information is yang modeled.
> > > > >
> > > > > Sure, but that's a completely different thing.
> > > > >
> > > > > This discussion is about what needs to be done with RFC 5277.
> > > > > I'll
> > > re-iterate
> > > > > what Andy wrote once more:
> > > > >
> > > > >   What are the must-have, should-have, and nice-to-have features
> > > > > that
> > > are
> > > > >   missing from RFC 5277?
> > > >
> > > > At a high level incremental functionality we have been discussing
> > > > since
> > > IETF 94, 95, 96, 97 includes:
> > > > - configured subscriptions
> > > > - many subscriptions per transport
> > > > - modify and delete subscriptions
> > > > - control plane notifications
> > > > - Restconf & HTTP support
> > > > - Data plan notification including subscription-id
> > > >
> > > > At a medium level, existing documentation detailing these
> > > > requirements
> > > can be seen in places like:
> > > > https://www.ietf.org/proceedings/95/slides/slides-95-netconf-7.pdf
> > >  Slide 5
> > > > https://www.ietf.org/proceedings/96/slides/slides-96-netconf-5.pdf
> > >  Slides 5, 28
> > > > https://www.ietf.org/proceedings/97/slides/slides-
> > > 97-netconf-draft-ietf-netconf-yang-push-01.pdf  Slides 20 & 21
> > >
> > > I think the list above summarizes what's in the slides.
> > >
> > > So, let me re-order this list a bit:
> > >
> > > - configured subscriptions
> > > - many subscriptions per transport
> > >   - Data plan notification including subscription-id
> > >   - modify and delete subscriptions
> > >
> > > I don't view "control plane notifications" as a deficiency of 5277;
> > > it already has a few, and if new functionality requires us to define
> > > more control plane notifications, that's not a problem.
> > >
> > > As for "Restconf & HTTP support", RESTCONF already supports
> > > notifications, and there need to be a RESTCONF-specific solution in
> > > place.  I do agree that if we open 5277, we should make sure we have
> > > a small protocol-dependent part, and a generic, protocol-independent
> > > part.
> > >
> > > So there are really two (major) requirements:
> > >
> > >   1.  configured subscriptions
> > >   2.  many subscriptions per transport session
> > >
> > > Do you agree, or did I miss anything?
> > >
> > > (1) can be done completely backwards compatible; in fact it might
> > > not even require an update to 5277.
> > >
> > > (2) requires an update to the <notification> element, as discussed
> > > earlier.
> > >
> > > Did you want to make support for (2) mandatory to implement?  If so,
> > > we need to make :interleave mandatory, or remove it.
> > >
> > > Maybe it should be noted that when SSH is used, there really is no
> > > need for (2), since it is trivial and cheap to open new SSH channels.
> > > I thus assume that the reason for wanting to do (2) is that sessions
> > > are expensive when SSH is not used.
> > >
> > >
> >
> > Why are configured subscriptions needed if we have Call-home for both
> > NETCONF and RESTCONF?
> 
> The server must be told *when* to call home, right?  I assume that the
> configured subscriptions provides this; i.e., if a notif is generated for a
> configured subscription, and there is no active session, the server will call
> home.  The client can listen for a while and then hang up (I assume).  When a
> new notif is generated the server will call home again.  This does seem a bit
> complex, and I'm not sure it is needed.

Yes, the basic flow above is what we have been aiming to do.  For both configured and dynamic subscriptions, there are deployment types which benefit from reducing the number of active transport sessions.  This is easier to do with some transport types than others.

Call home helps secure devices by ensuring it is the network element which initiates a transport connection.  Call home is not needed for all types of configured subscriptions transport types, just those on NETCONF.  The reason NETCONF needs call home is that the NETCONF server must always be the Publisher, and therefore you need to signal the NETCONF client when there are updates to push should no transport currently exist.

HTTP2 & GRPC based protocols will have configured subscriptions on the publisher have their updates pushed via an HTTP Client.  So call home is not necessary in that environment. 

> But I don't think this solution is well documented in the current set of drafts.

We will get there :-)

Eric
 
> /martin
> 
> 
> > I prefer 1 mandatory-to-implement RPC instead of duplicated optional
> > solutions.
> > The new feature is really "server initiates notifications upon a
> > reboot", not "configured notifications".
> >
> >
> >
> > >
> > >
> > > /martin
> > >
> > >
> >
> > Andy
> >
> >
> > >
> > >
> > > >
> > > > At a detailed level, I2RS's RFC-7923 has functional requirements
> > > > for
> > > yang subscriptions. This is what was requested by the WG to be made
> > > available for event notifications.
> > > > as well as various WG meeting minutes.
> > > >
> > > > And of course the existing WG minutes, the four draft document
> > > appendices, and the Dezign team minutes at:
> > > > https://github.com/netconf-wg/yang-push/wiki/Minutes
> > > > Attempts to keep a running list of to-be-resolved dialogs.  Of
> > > > course
> > > there is a lag between dialogs and embodiment in the drafts.
> > > >
> > > > If anyone wants to propose a revision to the requirements, I
> > > > propose
> > > they do this as deltas from the existing documentation.
> > > >
> > > > Or course we in the WG can and should discuss and tweak any
> > > > specific
> > > requirement on this mailer based on ongoing learnings over time.
> > > >
> > > > Eric
> > > >
> > > > > /martin
> > > >
> > >