Re: [Netconf] Subscription Use Cases

[Andy Bierman <[e-mail]>]

On Thu, Dec 8, 2016 at 6:52 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.  And in some of these cases,
> not all the information is yang modeled on a platform.  (As much as I wish
> it were.)  I have indicated a few places where this is the case in-line.
>
> Beyond the original cases I sent, there are other use cases where there
> are notifications will not be YANG modeled.
>
> (Category 4) Control Plane Notifications
>
> (4a) First-sign-of-life on new CPE.   In this case you need to figure out
> what to do when a new CPE appears on an access link.  For example, a policy
> determination needs to be made on what security treatment it needs.  This
> notification could be done via NETCONF.  And the request could come from
> the same controller subscribing to traditional NETCONF notifications.
>
> In the end, more and more stuff will be yang modeled on the device.  That
> is one reason I like your alarm-yang-module.  Approaches like the alarm
> will allow more robust yang-push mechanisms to be used over event
> notifications.  But we won't be there for a while.
>
>


What is the control plane protocol?
Seems to me you are confusing implementation details with control plane
notifications.
In this context, only a notification that is defined to be consumed by the
notification delivery system and never needs to be seen by the subscriber
would qualify.

The "5277 layer" provides the subscription control.
It also interfaces to the transport layer.
IMO we need to support a small number (2) of standard transports
  1) NETCONF <notification> elements
  2) RESTCONF SSE data stream

Lots of optional components make the solution worse.
It's like the JSON vs. XML issue in RESTCONF.
It's nice for the server developer to pick 1 of N options, but that means
the client developer has to implement all options to work with all servers.

I agree with Martin that create-subscription and establish-subscription
are not both needed.  Pick 1.

IMO there is no need for configured subscriptions because Call-home can be
used instead.

Configurable filters (in the current drafts) are not very reusable so I
don't see much
value in the ability to specify 1 filter (either inline or pre-configured).

IMO there is significant customer interest in YANG Push but not for
anything else in this document set.  The WG needs to focus on the
requirements for YANG Push and only change the lower layers if they are
really broken.


Andy



> > (Category 1) Streaming Telemetry
> > >
> > > High volume set of objects pushed on a predictable schedule.
> > >
> > > (1a) Telemetry: Fast replication of YANG operational/config data
> > > off-box for traffic or configuration analysis
> > >
> > > (1b) Multi operations reporting: Send a targeted subset
> > > operational/config data to an Operations group not directly managing
> > > device
> > >
> > > (Category 2) Distributed Eventing
> > >
> > > No need to repeatedly poll to see if targeted subsets of Network
> > > Element config have changed. The latest is pushed as it happens.
> > >
> > > (2a) Integrity Verification: Push discovered changes in keys, config,
> > > software hash as they happen.  Application validates that change is
> > > authorized.
>
> Not all the needed info here is yang modeled.
>
> > > (2b) Eliminate Polling: NMS/controllers pushed config changes as they
> > > occur in Network Elements (enabling real-time state synchronization).
> > >
> > > (2c) IWAN: Changes in Operational Data drive network rebalancing for
> > > optimized enterprise facilities usage
> > >
> > > (2d) Domain Policer: provide a single policed data rate across
> > > multiple data centers or branch offices
> > >
> > > (2e) DDoS Protection: send suspect spikes of traffic across a set
> > > devices to a scrubber
>
> Not all the needed info here is yang modeled.
>
> > >
> > > (Category 3) Network as the Subscriber
> > >
> > > Distributed CPE, VMs, routers can subscribe to a fast changing
> > > centralized configuration repository
> > >
> > > (3a) Perimeter & Internal Blocking: When vulnerabilities are detected,
> > > ephemeral remediation policies are temporarily installed across a
> > > domain of devices.
> > >
> > > (3b) Tunnel Endpoint Synch: Filtered subsets of centrally managed
> > > tunnel Ethernet endpoints can be downloaded and coordinated across
> > > edge devices to minimize effort in maintaining dynamic mesh
>
> Not all the needed info here is yang modeled.
>
> Eric
>
> > > (3c) Policy mirroring: Enables trusted or partially-trusted edge
> > > devices to mirror the state of a central configuration repository
> >
> >
> > /martin
>