Subject: Re: [Netconf] Notification updation RFC 5277

From: Rohit R Ranade <[email-masked]>
Date: Thu, 5 Feb 2015 04:35:13 +0000

Hi,

Sorry for the late reply.
My client has a scenario, where he uses a single session to configure and track notifications.
His modules will init at different times and each module want to subscribe to different events.
Since all modules will use same session, just having create-subscription will not be sufficient.

With Regards,
Rohit

From: Ersue, Mehmet (NSN - DE/Munich) [mailto:[email-masked]]
Sent: 05 January, 2015 00:30
To: Rohit R Ranade; [email-masked]
Subject: RE: Notification updation RFC 5277

Dear Rohit,

can you elaborate in which scenario you need to modify a notification subscription?

Regards,
Mehmet

From: Netconf [mailto:[email-masked]] On Behalf Of ext Rohit R Ranade
Sent: Monday, December 22, 2014 4:36 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Netconf] Notification updation RFC 5277

Hello,

RFC 5277 clearly states that subscriptions cannot be updated. Is there some reason for it ? I have a scenario, where subscriptions can get added and deleted.
Is there some mechanism to update subscription ?

With Regards,
Rohit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Feb 2015 14:32:35 +0100

Hi,

RFC 5277 has its limits...

You can either try to delay subscription until all modules have
finished their initialization or if that is not feasible, you will
have to restart the session whenever the subscription needs to change.

/js

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Thu, 5 Feb 2015 15:44:42 +0000

>RFC 5277 has its limits...

Indeed

>have to restart the session whenever the subscription needs to change.

Some applications set up a secondary subscription and then drop the first
subscription...removing duplicate events received during the transition.
It's nasty business, much cleaner would be an ability to modify the
existing subscription.

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Feb 2015 16:53:30 +0100

> It's nasty business, much cleaner would be an ability to modify the

Not with RFC 5277 - there is no delete-subscription in RFC 5277.

/js

---

From: Kent Watsen <[email-masked]>
Date: Thu, 5 Feb 2015 17:06:29 +0000

>Not with RFC 5277 - there is no delete-subscription in RFC 5277.

Poor man's delete: drop the underlying NETCONF session.  The assumption is
that there is a dedicated NETCONF session for each subscription (no
interleaving).  Using SSH channels, this can be a fairly cheap operation,
reusing the same underlying SSH connection.

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Feb 2015 18:15:10 +0100

> reusing the same underlying SSH connection.

Yes, SSH channels are reasonably cheap. With TLS, well, you better
have session resumption working. I understand that #interleave is
optional and hence having delete-subscription would not generally
work (nor would modify-subscription). Well, lets see where we end
up with the pub/sub discussions underway...

/js

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Feb 2015 09:42:33 -0800

> up with the pub/sub discussions underway...

Oh good, I can dust off my list of NETCONF notification gripes ;-)

1) a single replay buffer for all NETCONF events can be over-run.
    A standard solution would be useful, such as source-filtering
    or rate-limiting event generation, or standardized priority for
    dropping events, or multiple standard streams.

2) The current filter mechanism is just awful for describing a pub/sub model.
    New, simple, less error-prone mechanisms to convey the pub
    capabilities and the sub requirements are needed.  There should be
    a way to validate subscriptions to make sure they are configured correctly.
    This is not possible with a generic subtree or XPath filter.

3) the subscription requirements should be configurable to reduce
setup complexity
    and allow re-configuration on-the-fly. RPC-based mechanisms may need to be
    replaced or enhanced.

> /js

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 5 Feb 2015 13:31:58 -0500

Kent Watsen writes:
>Poor man's delete: drop the underlying NETCONF session.

;^)

>The assumption is

If we could have made that assumption, the notification mechanism
would have been oh-so easy.  Instead we designed for interleaving
notifications and <rpc-reply>s.  I thing it's too late to start
requiring that assumption (unless we want to redesign notifications
(which would be a great idea (except for my previous comments re:
stability and "done"-ness))).

Thanks,
 Phil

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 5 Feb 2015 19:11:25 +0000

Stability is all good, assuming it can be reasonably adapted to requirements.  The other side of the stability coin would be inflexibility. 
The need to adjust subscriptions appears fairly reasonable; we are also seeing this in conjunction with datastore-push.  So, I for one would think it reasonable to look into extensions to accommodate such.     
--- Alex

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Phil Shafer
Sent: Thursday, February 05, 2015 10:32 AM
To: Kent Watsen
Cc: Rohit R Ranade; [email-masked]
Subject: Re: [Netconf] Notification updation RFC 5277

;^)

>interleaving).  Using SSH channels, this can be a fairly cheap 
>operation, reusing the same underlying SSH connection.

If we could have made that assumption, the notification mechanism would have been oh-so easy.  Instead we designed for interleaving notifications and <rpc-reply>s.  I thing it's too late to start requiring that assumption (unless we want to redesign notifications (which would be a great idea (except for my previous comments re:
stability and "done"-ness))).

Thanks,
 Phil

---

From: Rohit R Ranade <[email-masked]>
Date: Fri, 13 Feb 2015 03:01:34 +0000

Hi, Is there any update on this ? Preferably a solution which does not involve tearing down and bringing up a session will be welcome.
The notifications lost during the time period for which the session is down. A separate mechanism to be used to get them back and the subsequent handling will make it very complicated.
Kindly help.

With Regards,
Rohit

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Phil Shafer
Sent: Thursday, February 05, 2015 10:32 AM
To: Kent Watsen
Cc: Rohit R Ranade; [email-masked]
Subject: Re: [Netconf] Notification updation RFC 5277

;^)

Thanks,
 Phil

---

From: Ambika Tripathy <[email-masked]>
Date: Fri, 13 Feb 2015 11:37:01 +0530

Hi, The existing NetConf session with notification definition as per
rfc5277 is very limited to just once subscription for all event in the
system. For different filters in notification, there is a need to create
different session and with unique subscription request. This is not a
efficient solution.
The mechanism should allow multiple unique create-subscription request in a
session and send the event data based on subscription request and the
subscription should  be uniquely identified by one subscription-id for easy
management like RPC, RPC-reply.

The current way of handling notification is very limited to PUB-SUB
mechanism also and not efficient solution. If there will be one extension
to notification mechanism to handle PUB-SUB data, by addressing all
requirements of datastore-push will help a lot.

br,
Ambika Prasad Tripathy

On Fri, Feb 13, 2015 at 8:31 AM, Rohit R Ranade <[email-masked]>
wrote:

> Hi, Is there any update on this ? Preferably a solution which does not
> involve tearing down and bringing up a session will be welcome.
> The notifications lost during the time period for which the session is
> down. A separate mechanism to be used to get them back and the subsequent
> handling will make it very complicated.
> Kindly help.
>
> With Regards,
> Rohit
>
> Stability is all good, assuming it can be reasonably adapted to
> requirements.  The other side of the stability coin would be inflexibility.
> The need to adjust subscriptions appears fairly reasonable; we are also
> seeing this in conjunction with datastore-push.  So, I for one would think
> it reasonable to look into extensions to accommodate such.
> --- Alex
>
>
> If we could have made that assumption, the notification mechanism would
> have been oh-so easy.  Instead we designed for interleaving notifications
> and <rpc-reply>s.  I thing it's too late to start requiring that assumption
> (unless we want to redesign notifications (which would be a great idea
> (except for my previous comments re:

-- 
Ambika Prasad Tripathy
Cell @+91 9437547730/8553070866
Alt email: [email-masked]
[email-masked]
skype:ambika_nethawk

---

From: Rohit R Ranade <[email-masked]>
Date: Fri, 13 Feb 2015 06:53:56 +0000

Hi,

As per your mail about Datastore-push, I referred to the https://tools.ietf.org/html/draft-netmod-clemm-datastore-push-00 draft of datastore-push.
Kindly provide the requirements of data-store-push that needs to be added( that you currently have in minded) to the extension. I have a scenario, where maybe datastore-push also might be necessary for my client.
Maybe based on your thoughts maybe I can also add to those requirements.

With Regards,
Rohit

From: Ambika Tripathy [mailto:[email-masked]]
Sent: 13 February, 2015 11:37
To: Rohit R Ranade
Cc: Alexander Clemm (alex); Phil Shafer; Kent Watsen; [email-masked]
Subject: Re: [Netconf] Notification updation RFC 5277

Hi, The existing NetConf session with notification definition as per rfc5277 is very limited to just once subscription for all event in the system. For different filters in notification, there is a need to create different session and with unique subscription request. This is not a efficient solution.
The mechanism should allow multiple unique create-subscription request in a session and send the event data based on subscription request and the subscription should  be uniquely identified by one subscription-id for easy management like RPC, RPC-reply.

The current way of handling notification is very limited to PUB-SUB mechanism also and not efficient solution. If there will be one extension to notification mechanism to handle PUB-SUB data, by addressing all requirements of datastore-push will help a lot.

br,
Ambika Prasad Tripathy

On Fri, Feb 13, 2015 at 8:31 AM, Rohit R Ranade <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Is there any update on this ? Preferably a solution which does not involve tearing down and bringing up a session will be welcome.
The notifications lost during the time period for which the session is down. A separate mechanism to be used to get them back and the subsequent handling will make it very complicated.
Kindly help.

With Regards,
Rohit

-----Original Message-----
From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Phil Shafer
Sent: Thursday, February 05, 2015 10:32 AM
To: Kent Watsen
Cc: Rohit R Ranade; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] Notification updation RFC 5277

;^)

Thanks,
 Phil

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

--
Ambika Prasad Tripathy
Cell @+91 9437547730/8553070866
Alt email: [email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>
skype:ambika_nethawk

---

From: Ambika Tripathy <[email-masked]>
Date: Tue, 17 Feb 2015 11:23:50 +0530

Hi Rohit,

Few thoughts
- The datastore push requirements are present in datastore-push draft you
stated above and section 3 gives more clear idea.
- Along with this, few more requirements i think for NetConf notification
can be  handled.
   - multiple create-subscription request in same NetConf ssh session using
different channels. Basically multiplexing the same NetConf ssh session
with multiple ssh channel.
   - there should be a way to differentiate between notification
subscription and data subscription.
   - each subscription channel can be treated independently and any one
subscription termination shouldn't affect session.

br,
Ambika Prasad Tripathy

On Fri, Feb 13, 2015 at 12:23 PM, Rohit R Ranade <[email-masked]>
wrote:

>  Hi,
>
>
>
> As per your mail about Datastore-push, I referred to the
> https://tools.ietf.org/html/draft-netmod-clemm-datastore-push-00 draft of
> datastore-push.
>
> Kindly provide the requirements of data-store-push that needs to be added(
> that you currently have in minded) to the extension. I have a scenario,
> where maybe datastore-push also might be necessary for my client.
>
> *From:* Ambika Tripathy [mailto:[email-masked]]
> *Sent:* 13 February, 2015 11:37
> *To:* Rohit R Ranade
> *Cc:* Alexander Clemm (alex); Phil Shafer; Kent Watsen; [email-masked]
>
> *Subject:* Re: [Netconf] Notification updation RFC 5277
>
>
>
> The mechanism should allow multiple unique create-subscription request in
> a session and send the event data based on subscription request and the

---

From: Rohit R Ranade <[email-masked]>
Date: Tue, 17 Feb 2015 06:20:22 +0000

Hi,

- multiple create-subscription request in same NetConf ssh session using different channels. Basically multiplexing the same NetConf ssh session with multiple ssh channel.
--> This point I did not understand. Do you mean, that there will be multiple SSH sessions with single NETCONFS session ?
I guess your intention is that you want to subset each notification, and want to get those subsets in different SSH channel for load balancing ?

With Regards,
Rohit

From: Ambika Tripathy [mailto:[email-masked]]
Sent: 17 February, 2015 11:24
To: Rohit R Ranade
Cc: Alexander Clemm (alex); Phil Shafer; Kent Watsen; [email-masked]
Subject: Re: [Netconf] Notification updation RFC 5277

Hi Rohit,

Few thoughts
- The datastore push requirements are present in datastore-push draft you stated above and section 3 gives more clear idea.
- Along with this, few more requirements i think for NetConf notification can be  handled.
   - multiple create-subscription request in same NetConf ssh session using different channels. Basically multiplexing the same NetConf ssh session with multiple ssh channel.
   - there should be a way to differentiate between notification subscription and data subscription.
   - each subscription channel can be treated independently and any one subscription termination shouldn't affect session.

br,
Ambika Prasad Tripathy

On Fri, Feb 13, 2015 at 12:23 PM, Rohit R Ranade <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

With Regards,
Rohit

From: Ambika Tripathy [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 13 February, 2015 11:37
To: Rohit R Ranade
Cc: Alexander Clemm (alex); Phil Shafer; Kent Watsen; [email-masked]<mailto:[email-masked]>

br,
Ambika Prasad Tripathy

With Regards,
Rohit

-----Original Message-----
From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Phil Shafer
Sent: Thursday, February 05, 2015 10:32 AM
To: Kent Watsen
Cc: Rohit R Ranade; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] Notification updation RFC 5277

;^)

Thanks,
 Phil

--
Ambika Prasad Tripathy
Cell @+91 9437547730<tel:%2B91%209437547730>/8553070866<tel:8553070866>
Alt email: [email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>
skype:ambika_nethawk

---

From: "Ambika Prasad Tripathy (ambtripa)" <[email-masked]>
Date: Tue, 17 Feb 2015 10:26:05 +0000

Yes Rohit.

Br,
Ambika

From: Netconf [mailto:[email-masked]] On Behalf Of Rohit R Ranade
Sent: Tuesday, February 17, 2015 11:50 AM
To: Ambika Tripathy
Cc: [email-masked]
Subject: Re: [Netconf] Notification updation RFC 5277

Hi,

With Regards,
Rohit

Hi Rohit,

Few thoughts

br,
Ambika Prasad Tripathy

With Regards,
Rohit

br,
Ambika Prasad Tripathy

With Regards,
Rohit

-----Original Message-----
From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Phil Shafer
Sent: Thursday, February 05, 2015 10:32 AM
To: Kent Watsen
Cc: Rohit R Ranade; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] Notification updation RFC 5277

;^)

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 17 Feb 2015 12:43:14 +0100 (CET)

> >> - multiple create-subscription request in same NetConf ssh session
> >> using different channels. Basically multiplexing the same NetConf
> >> ssh session with multiple ssh channel. 
> > --> This point I did not understand. Do you mean, that there will be
> > multiple SSH sessions with single NETCONFS session ? 
> > I guess your intention is that you want to subset each notification,
> > and want to get those subsets in different SSH channel for load
> > balancing ?
>
> Yes Rohit.

Currently, each SSH channel becomes a separate NETCONF session.  So
this proposal would require a new binding for NETCONF over SSH, and a
concept of "channels" in the base NETCONF protocol.  I don't think
this is a good idea.

/martin

---

From: Ambika Tripathy <[email-masked]>
Date: Tue, 17 Feb 2015 17:57:04 +0530

Hi,

Can you please let me know the reason behind it ?

That mean, one netconf session is only limited to only one subscription and
the subscription will end with session close.
For multiple subscription request the same application needs to create
multiple netconf session.

Is not it mean, the NetConf is not utilization the complete capability of
underlying transport i.e. SSH.

br,
Ambika Prasad Tripathy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 17 Feb 2015 13:33:57 +0100

> the subscription will end with session close.

This is what the notification document says.

> multiple netconf session.

This follows from it.

> underlying transport i.e. SSH.

I think RFC 6242 says that an SSH channel maps 1:1 to a NETCONF
session.  RFC 6242 does not explicitely talk about using multiple SSH
channels but it also does not forbit to use multiple SSH channels. So
I guess this is currently up to implementations to sort out.

/js

---

From: Rohit R Ranade <[email-masked]>
Date: Tue, 17 Feb 2015 15:13:49 +0000

Hi,

I feel there are two points that are being discussed now.
a) Ease of use : Allowing a modification of subscription requests.
b) Load-balancing of notifications.

I think that multiplexing of SSH channels will only make it complex for NETCONF to handle multiple channels. It will need to manage
As to which notifications need to be sent on which channels. 
It might handle load-balancing in a way but at the cost of complexity of SSH and NETCONF channel handling.

With Regards,
Rohit

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 17 February, 2015 18:04
To: Ambika Tripathy
Cc: Martin Bjorklund; Rohit R Ranade; [email-masked]
Subject: Re: [Netconf] Notification updation RFC 5277

This follows from it.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 17 Feb 2015 16:34:09 +0100

> It might handle load-balancing in a way but at the cost of complexity of SSH and NETCONF channel handling.

I think you should forget about load balancing here since multiple SSH
channels all run over a single TCP connection. The application needs
to handle multiple channels, NETCONF has no issue since it defines
only what happens inside a session / channel.

/js