Re: [Netconf] Subscription Use Cases

[Martin Bjorklund <[e-mail]>]

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.

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


/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
> > >
> >