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

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 8 Dec 2016 00:42:11 +0000

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:[email-masked]> 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:[email-masked]> wrote:

On Wed, Dec 7, 2016 at 9:38 AM, MehmetErsue <mailto:[email-masked]> 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:[email-masked]> wrote:

Andy Bierman <mailto:[email-masked]> wrote:

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

> > Andy Bierman <mailto:[email-masked]> wrote:

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

> > wrote:

> > > > Andy Bierman <mailto:[email-masked]> 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:[email-masked]

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

--

Cheers,

Mehmet

--

Cheers,

Mehmet

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Dec 2016 10:07:45 +0100 (CET)

Hi,

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

I think Andy summarized the issue nicely earlier in this thread:

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

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?

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

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 8 Dec 2016 14:52:02 +0000

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.

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

Not all the needed info here is yang modeled.

> > (3a) Perimeter & Internal Blocking: When vulnerabilities are detected,
> > ephemeral remediation policies are temporarily installed across a
> > domain of devices.
> >

Not all the needed info here is yang modeled.

Eric

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Dec 2016 09:46:41 -0800

On Thu, Dec 8, 2016 at 6:52 AM, Eric Voit (evoit) <[email-masked]> wrote:

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Dec 2016 09:26:51 +0100 (CET)

"Eric Voit (evoit)" <[email-masked]> wrote:
> 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:

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 9 Dec 2016 12:47:15 +0000

> From: Martin Bjorklund, December 9, 2016 3:27 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?
> >
> This discussion is about what needs to be done with RFC 5277.  I'll re-iterate
> what Andy wrote once more:
> 

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

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Dec 2016 14:33:06 +0100 (CET)

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

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.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Dec 2016 07:19:09 -0800

On Fri, Dec 9, 2016 at 5:33 AM, Martin Bjorklund <[email-masked]> wrote:

> > https://www.ietf.org/proceedings/97/slides/slides-
> 97-netconf-draft-ietf-netconf-yang-push-01.pdf  Slides 20 & 21
>

Why are configured subscriptions needed if we have Call-home for both
NETCONF and RESTCONF?
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".

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.
> > And of course the existing WG minutes, the four draft document
> appendices, and the Dezign team minutes at:
> > 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
> >
>

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Dec 2016 16:29:45 +0100 (CET)

> Why are configured subscriptions needed if we have Call-home for both

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Dec 2016 07:51:26 -0800

On Fri, Dec 9, 2016 at 7:29 AM, Martin Bjorklund <[email-masked]> wrote:

> > > > >   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:
> > > > At a medium level, existing documentation detailing these
> requirements
> > > can be seen in places like:
It would be configured in the call-home configuration.
I think that is 1 of Kent's server modules.

The general re-connect strategy for call-home should control this behavior.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Dec 2016 19:48:03 -0800

> small protocol-dependent part, and a generic, protocol-independent

I agree with this approach.

The feature list above is ready a solution list, not a feature list.
Can we describe new functionality in terms of the problem being solved?
subscription-id is a solution to some undisclosed problem.

must-have:
  - extensible filtering framework that can be shared by multiple protocols
and operations
  - mandatory-to-implement set of RPCs (create, modify, cancel) for
subscription mgmt
  - integration with Call-home and netconf-client-server drafts
  - subscription diagnostics (filter, network, etc.)

should-have:
  - configured subscriptions that connect at boot-time to configured
receivers
  - extensible framework that allows multiple protocol, message encoding,
and transport
    configurations; pick small set of mandatory-to-implement combinations
  - augmentable notification header that can be used by standard protocols
and vendor extensions
    to send control-plane data
  - efficiency mechanisms to support large-scale subscription aggregation
clients
  - binary encoding and message framing for NETCONF and RESTCONF to reduce
NM
    network usage

Andy

---

From: <[email-masked]>
Date: Fri, 9 Dec 2016 23:21:14 -0800

Hi,

Originally, we were working within the confines of RFC 5277 for YANG-Push, but it was clear that were a couple of items that came up as limitations.  As stated, these include configurable subscriptions, the ability to maintain multiple subscriptions, to modify and delete subscriptions.  

I would add that another important requirement concerned the ability to separate subscription control from subscription transport and thus be able to leverage multiple transports. (We can discuss if this should be strictly a YANG-push requirement, not an RFC 5277 requirements – but in that case it would imply departing from the concept of layering YANG-Push on top of event notifications.)  I would also think that the ability to support control notifications is a requirement; I do not see it well supported with existing mechanisms.  

The ability to associated updates with subscriptions was originally a requirement for YANG-Push, not for event notifications.  This is the reason why subscription ID is included in YANG-Push updates (but only there).  The ability to associate event notifications with a particular subscription is a new requirement; if we decide to support (and there are clearly some use cases) this one will have architectural ramifications as noted (since it means event notifications now need to have a way to be associated with specific subscription, presumably leading to a header that includes a subscription ID, and possibly redundant sending of notifications that are subscribed multiple times.)  

--- Alex

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Friday, December 9, 2016 7:48 PM
To: Martin Bjorklund <[email-masked]>
Cc: Netconf <[email-masked]>
Subject: Re: [Netconf] Subscription Use Cases

On Fri, Dec 9, 2016 at 5:33 AM, Martin Bjorklund <[email-masked] <mailto:[email-masked]> > wrote:

"Eric Voit (evoit)" <[email-masked] <mailto:[email-masked]> > wrote:
> > "Eric Voit (evoit)" <[email-masked] <mailto:[email-masked]> > wrote:
> > > Hi Martin,
> > >

 

must-have:

  - extensible filtering framework that can be shared by multiple protocols and operations

  - mandatory-to-implement set of RPCs (create, modify, cancel) for subscription mgmt

should-have:

  - configured subscriptions that connect at boot-time to configured receivers

  - extensible framework that allows multiple protocol, message encoding, and transport

  - augmentable notification header that can be used by standard protocols and vendor extensions

  - efficiency mechanisms to support large-scale subscription aggregation clients

  - binary encoding and message framing for NETCONF and RESTCONF to reduce NM

    network usage

Andy

/martin

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 16 Dec 2016 17:21:45 +0000

> From: Martin Bjorklund, December 9, 2016 10:30 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.
> > > > >
> > > 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.
> > >
> > > 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.
> > >
> > > (1) can be done completely backwards compatible; in fact it might
> > > not even require an update to 5277.
> > >
> 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
 
> > The new feature is really "server initiates notifications upon a
> > reboot", not "configured notifications".
> >
> >
> >
> > >
> > >
> > > /martin
> > >
> > >
> >
> > Andy
> >
> >
> > >
> > >
> > > >