[Netconf] Subscription Use Cases (was RE: Still subject to agree on NETCONF ML)

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

Here are some more cases.  Happy to talk more or demo if people are interested.



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

(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



(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

(3c) Policy mirroring: Enables trusted or partially-trusted edge devices to mirror the state of a central configuration repository

Eric



From: Netconf, December 7, 2016 5:42 PM



Hi,





The real question is what use-cases do we agree need to be supported which

are not currently supported that well. Here are 3, where the 5277 solution

may not scale well enough in implementation



   - notification collector: If subscriptions are provided as a service then multiple subscriptions

     per session may provide some opportunities for optimization on the collector and the server.

     e.g., send a notification just once, tagged with all the subscription-ids that are supposed to

    get this notification



  - telemetry: need high-performance and efficient use of the network; consider binary encoding

    and non-secure transports; relying on YANG Push so that draft has to clearly identify lower

    layer requirements



 - datastore replication: need reliable delivery and high performance; YANG Push is also

   the solution for this use-case



IMO we will not make progress on solution details without a better understanding of the use-cases.





Andy





On Wed, Dec 7, 2016 at 11:20 AM, MehmetErsue <mailto:[e-mail]> wrote:

Hi Andy, All,

can anybody draft a list of must-have, should-have, and nice-to-have requirements for discussion on the ML?

I think writing a draft for this would be an over-kill but I'm flexible.

Mehmet





On Wed, Dec 7, 2016 at 6:54 PM Andy Bierman <mailto:[e-mail]> wrote:

On Wed, Dec 7, 2016 at 9:38 AM, MehmetErsue <mailto:[e-mail]> wrote:

All,



> > The <nofitication> element is changing so old clients cannot

> > get the new version that contains a subscription-id and other

> > fields.

>

> I haven't seen any proposal for doing this on the ML.

Any discussion result from the notification team meetings is still subject to agree on NETCONF ML.

Such issues should be raised on the ML, the earlier the better.



I think Martin has raised valid concerns that we do not yet agree on the requirements.

The details of a solution do not matter if people do not agree on the problem first.



What are the must-have, should-have, and nice-to-have features that are missing from RFC 5277?



E.g., if we agree that is is a terrible burden on the client that 1 session be used for each subscription,

then multiple subscriptions per session is an important feature.  How to do that is the next step,

not this step.







Mehmet







Andy





On Mon, Dec 5, 2016 at 10:35 PM Martin Bjorklund <mailto:[e-mail]> wrote:

Andy Bierman <mailto:[e-mail]> wrote:

> On Mon, Dec 5, 2016 at 12:48 PM, Martin Bjorklund <mailto:[e-mail]> wrote:

>

> > Andy Bierman <mailto:[e-mail]> wrote:

> > > On Mon, Dec 5, 2016 at 12:37 PM, Martin Bjorklund <mailto:[e-mail]>

> > wrote:

> > >

> > > > Andy Bierman <mailto:[e-mail]> wrote:

> > > > > Hi,

> > > > >

> > > > > I prefer the current solution approach, which is to use

> > > > > 'establish-subscription'.

> > > >

> > > > Can you elaborate on why you prefer two operations instead of one,

> > > > when they do the same thing?

> > > >

> > >

> > > because they don't do the same thing.

> > > The new solution has configured filters, subscription-id, suspend and

> > > cancel operations

> >

> > These are trivial extensions to the current solution.

> >

> > If they are truly different the names should not be so similar.

> >

> > > and should not need streams.

> >

> > What do you mean "should not need streams"?

> >

> >

>

> The streams concept is half-baked and not useful.



I strongly disagree.  The stream concept including replay is very

powerful.



If you think it should be deprecated and replaced with something else,

I think that requires some careful discussion first.  (such as a

description of its problems, and a description of a new solution).



> We have 1 stream, NETCONF, which MUST contain everything



No it doesn't.  This was dicussed recently.  The text says:



   This stream contains all NETCONF XML event notifications supported by

   the NETCONF server.



Note it says "all NETCONF XML event notifications", not "all

[XML] event notifications".



> and

> MUST be encoded in XML.



Well, NETCONF is encoded in XML so this should not come as a

surprise...



> Every other stream is purely ad-hoc and

> proprietary



Not really.  All streams supported can be discovered by any client

(with proper access rights).



> with no chance at interoperability.



This is a false statement.  We have defined several different streams

that third party clients use w/o any problems.  If a stream doesn't

interoperate b/c of its name, some implementation is buggy.



> > > The old solution can be deprecated and replaced.

> >

> > Sure, if it is broken.  But I don't think it is broken in any way.

> >

> >

> >

> The <nofitication> element is changing so old clients cannot

> get the new version that contains a subscription-id and other

> fields.



I haven't seen any proposal for doing this on the ML.



> IMO it is simpler and clearer if the new solution is separate.



Maybe.  Anyway, my post was really in reply to Eric's statement that

these new features could not be built on top of what we have and still

be backwards compatible.



One way of making streams even more useful is to make them

configurable, e.g. instead of creating configurable filters, an idea

is to create a new stream together with a filter, and replay

definition.  Being able to do this dynamically would actually be quite

useful.





/martin



_______________________________________________

Netconf mailing list

mailto:[e-mail]

https://www.ietf.org/mailman/listinfo/netconf

--

Cheers,

Mehmet

--

Cheers,

Mehmet