Re: [Netconf] Subscription Use Cases

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

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.

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