Subject: [Netconf] Fwd: RFC 5277-bis

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 3 Apr 2016 13:29:20 -0300

As part of update to RFC 5277, I asked the original authors if they wanted to be involved in its update. Here are their observations on the proposed updates.

> Begin forwarded message:
> 
> From: <[email-masked]>
> Subject: RE: RFC 5277-bis
> Date: April 3, 2016 at 12:34:40 PM GMT-3
> 
> hi
> 
> I started to write some more detailed comments, but have realized it comes down to a fundamental design approach. I was going to send this comment to the mailing list via my work account, but am having some trouble logging in to that (password issues) today and I know you guys are meeting this week, so wanted to be sure I sent something before meetings started.  Hopefully you can share them with the group.
> 
> The original approach to Notifications was to move from subscriptions as configuration owned and managed by the device into sessions that were owned and managed by the client.  It was felt that having this manager/client information on the device made it inherently more complicated based on past experience with SNMP, etc.  Sending Notifications on a session create by the manager (and therefore correct in its details) that also went away when the manager shut it down made more operational sense.
> 
> The proposed update seems to be going back to the model of a subscription as configuration data. I would not object to reporting currently subscriptions as part of a get operation, but have concerns about going back to the model of having it as configuration.
> 
> Let me use a real-world example based on recent customer discussions.  We have a network management solution capable of managing a large number of devices, but have a customer with a huge network, so expect to have to deploy multiple network management systems - not GR, but each one (a GR pair actually) manages different devices.  The use case is if they want to move a device from one to  another in order to simplify service management (both endpoints on the same NMS). 
>   - Current solution:  de-enroll device from NMS A (shut down subscription session); enroll in NMS B (start new subscription session, same parameters)
>   - Proposed solution: de-enroll device from NMS A and send request to remove subscription from config for device; enroll in NMS B; and send request to add subscription to device.
> 
> The first approach is much cleaner. And as the subscription is part of a well-defined standardized RPC mechanism, I don't need to worry about differences in implementation (fingers crossed).
> 
> There are a few other cases where the current solution is cleaner.  For me, it just comes down to the fact that the Notification subscription belongs to the client and not the server(device), so that is who should manage it and its life-cycle.
> 
> Enjoy Buenos Aires
> 
> Sharon

Mahesh Jethanandani
[email-masked]

---

From: "Alberto Gonzalez Prieto (albertgo)" <[email-masked]>
Date: Wed, 6 Apr 2016 01:40:06 +0000

Hello Sharon, Mahesh,

Thanks for your input.
Note that supporting sending notifications on a client-created session is mandatory in the draft. Configuration-based subscriptions are not.
The full specification of the static (configuration-based) subscription is work-in-progress. Once completed is should be as well-defined as the current mechanisms.
In your example of moving a device from one NMS to another, could you elaborate on why you find the current approach cleaner?
In the proposed solution, the change would consist in adding one receiver to the subscription (NMS B) and removing another (NMS A).
Note that there is no need to resend the same parameters again in the proposed solution.

Thanks,

Alberto

From: Netconf <[email-masked]<mailto:[email-masked]>> on behalf of Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>
Date: Sunday, April 3, 2016 at 5:29 PM
To: NETCONF <[email-masked]<mailto:[email-masked]>>
Subject: [Netconf] Fwd: RFC 5277-bis

Begin forwarded message:

From: <[email-masked]<mailto:[email-masked]>>
Subject: RE: RFC 5277-bis
Date: April 3, 2016 at 12:34:40 PM GMT-3

hi

Enjoy Buenos Aires

Sharon

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Apr 2016 20:13:27 -0700

Hi,

I support the new notifications functionality, even if
there might be some corner-cases that cause an extra configuration
step if the operator chooses to configure notifications.
Customers have long complained about NETCONF notifications
because they require the NMS to keep sessions open to all the servers
it manages.

Configured notification parameters can be shared, which may allow
implementations to be more efficient, and allow subscriptions to start
a little faster.

I also like the idea of permitting the notification receiver to be
a different component than the configuration client.  This permits
more flexible system design.  This component does not need
a full NETCONF stack. It may use alternate transports not
supported by NETCONF (e.g. protobuffs, DTLS/UDP).

I don't want to take away existing functionality.  That's why I suggested
that the new RFC extend 5277 instead of obsolete it.

Andy

On Tue, Apr 5, 2016 at 6:40 PM, Alberto Gonzalez Prieto (albertgo) <
[email-masked]> wrote:

> Hello Sharon, Mahesh,
>
> Thanks for your input.
> Note that supporting sending notifications on a client-created session is
> mandatory in the draft. Configuration-based subscriptions are not.
> The full specification of the static (configuration-based) subscription is
> work-in-progress. Once completed is should be as well-defined as the
> current mechanisms.
> In your example of moving a device from one NMS to another, could you
> elaborate on why you find the current approach cleaner?
> In the proposed solution, the change would consist in adding one receiver
> to the subscription (NMS B) and removing another (NMS A).
> From: Netconf <[email-masked]> on behalf of Mahesh Jethanandani
> <[email-masked]>
> To: NETCONF <[email-masked]>
> As part of update to RFC 5277, I asked the original authors if they wanted
> to be involved in its update. Here are their observations on the proposed
> updates.
>
> Begin forwarded message:
>
> *From: *<[email-masked]>
> *Subject: **RE: RFC 5277-bis*
> *Date: *April 3, 2016 at 12:34:40 PM GMT-3
>
> hi
>
> I started to write some more detailed comments, but have realized it comes
> down to a fundamental design approach. I was going to send this comment to
> the mailing list via my work account, but am having some trouble logging in
> to that (password issues) today and I know you guys are meeting this week,
> so wanted to be sure I sent something before meetings started.  Hopefully
> you can share them with the group.
>
> The original approach to Notifications was to move from subscriptions as
> configuration owned and managed by the device into sessions that were owned
> and managed by the client.  It was felt that having this manager/client
> information on the device made it inherently more complicated based on past
> experience with SNMP, etc.  Sending Notifications on a session create by
> the manager (and therefore correct in its details) that also went away when
> the manager shut it down made more operational sense.
>
> The proposed update seems to be going back to the model of a subscription
> as configuration data. I would not object to reporting currently
> subscriptions as part of a get operation, but have concerns about going
> back to the model of having it as configuration.
>
> Let me use a real-world example based on recent customer discussions.  We
> have a network management solution capable of managing a large number of
> devices, but have a customer with a huge network, so expect to have to
> deploy multiple network management systems - not GR, but each one (a GR
> pair actually) manages different devices.  The use case is if they want to
> move a device from one to  another in order to simplify service management
> (both endpoints on the same NMS).
>   - Current solution:  de-enroll device from NMS A (shut down subscription
> session); enroll in NMS B (start new subscription session, same parameters)
>   - Proposed solution: de-enroll device from NMS A and send request to
> remove subscription from config for device; enroll in NMS B; and send
> request to add subscription to device.
>
> The first approach is much cleaner. And as the subscription is part of a
> well-defined standardized RPC mechanism, I don't need to worry about
> differences in implementation (fingers crossed).
>
> There are a few other cases where the current solution is cleaner.  For
> me, it just comes down to the fact that the Notification subscription
> belongs to the client and not the server(device), so that is who should
> manage it and its life-cycle.
>
> Enjoy Buenos Aires
>
> Sharon
>
>
> Mahesh Jethanandani
> [email-masked]
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>
>

---

From: "Chisholm, Sharon" <[email-masked]>
Date: Thu, 7 Apr 2016 17:43:07 -0400

Hi

If the plan is to have both and let a solution choose, that could work. Note that in my space we implemented heartbeats on push interfaces in the past so we could always be sure they were working.  We need the constant connection (real or simulated), even if it is more overhead. One solution may not fit all. I get that.

And if there is both, I don’t need to argue my use cases are not corner cases ;-)

Cheers,

Sharon

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Wednesday, April 06, 2016 11:13 PM
To: Alberto Gonzalez Prieto (albertgo)
Cc: NETCONF
Subject: Re: [Netconf] Fwd: RFC 5277-bis

Hi,

Andy

On Tue, Apr 5, 2016 at 6:40 PM, Alberto Gonzalez Prieto (albertgo) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Sharon, Mahesh,

Thanks for your input.

Thanks,

Alberto

Begin forwarded message:

hi

Enjoy Buenos Aires

Sharon

Mahesh Jethanandani

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