Subject: [Netconf] Comments on draft-ietf-netconf-subscribed-notifications-05: receiver configuration

From: "Tim Jenkins (timjenki)" <[email-masked]>
Date: Thu, 5 Oct 2017 19:56:56 +0000

Hi,

I have some comments on how receivers are configured for configured subscriptions as proposed in the document.

Because it's possible to have multiple configured subscriptions intentionally being sent to the same receiver, and the receivers are identified (uniquely) by their IP address/hostname, port (and source VRF), and the IP address/hostname and port of identical receivers has to be configured independently for each subscription, we are running into implementation concerns when the subscriber modifies the protocol of one of the receivers. We are assuming here of course that we do not support multiple protocols to the same receiver (even if one is over TCP and the other over UDP and there are only two protocols).

For example, take the starting condition where more than one subscription is configured identically with respect to receiver identification. The single connection is made between the publisher and the receiver, and all three subscriptions are sending update notifications to the receiver. Then, the subscriber modifies the protocol of one of the subscriptions.

Clearly, the subscription must stop using that connection. However, the publisher cannot tear down the connection to the receiver because other subscriptions are using it. And it also cannot create a connection to the receiver of the modified subscription because there already exists a connection (using the wrong protocol). It would appear that the publisher has to wait until no subscriptions are using the current protocol (for whatever reason), and at that time it can tear down the connection and bring up a new one using the new protocol.

This situation could be avoided if instead of making the receiver configuration part of the subscription, there was instead a table of receivers that was referenced by the subscription configuration. Of course, this table's keys could no longer be simply address/hostname and port, since the receivers are not uniquely identified by those values alone because of the use of source VRF in the subscription.

Another reason for using a single receiver table is for the configuration of security profiles, where by security profile I mean a reference to something on the publisher that describes how the connection to the reciever should be made secure. Right now, this can be supported by augmenting the receiver configuration, but just like the protocol, it has to be configured identically for all receivers that are intended to be the same. Hence it would be easier to augment a single receiver table that is referred to by the subscription, and allow the use of the security profile in one place instead of multiple places.

Thanks,

Tim

--
Cisco Systems Canada Co.
2000 Innovation Drive
Kanata, ON, Canada, K2K 3E8
Preferences <http://www.cisco.com/offer/subscribe/?sid=000478326>
Unsubscribe <http://www.cisco.com/offer/unsubscribe/?sid=000478327>
Privacy <http://www.cisco.com/web/siteassets/legal/privacy.html>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 5 Oct 2017 22:45:38 +0000

Hi Tim,

My read on your thinking:

It is possible to have multiple configured subscriptions to the same receiver, *and* the receiver might use the same destination port number for different transport protocols. (This doesn’t seem advisable, but it can be done.)  As a result, we might want the alter the YANG model for a subscription’s receivers list to include a leafref to a separate receivers container.  In this container will be the one transport protocol which should be used by any unique receiver+port combination for configured subscriptions.

We can certainly do this, but it does add another level of complexity.   (And we are fairly complex already.)  If the majority of the WG want this approach, we can do this of course.

Eric

From: Netconf [mailto:[email-masked]] On Behalf Of Tim Jenkins (timjenki)
Sent: Thursday, October 5, 2017 3:57 PM
To: [email-masked]
Subject: [Netconf] Comments on draft-ietf-netconf-subscribed-notifications-05: receiver configuration

Hi,

Thanks,

Tim

---

From: "Tim Jenkins (timjenki)" <[email-masked]>
Date: Thu, 5 Oct 2017 23:00:32 +0000

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thursday, October 5, 2017 at 6:45 PM
To: "Tim Jenkins (timjenki)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Comments on draft-ietf-netconf-subscribed-notifications-05: receiver configuration

Hi Tim,

<Tim> While adding a standalone receiver table makes the model more complicated, I think it makes the implementation less complicated because there's no need to ever deal with the state that you could have multiple protocols configured to the same receiver at the same time. As it is now, that's possible, so the implementations have to figure out how to deal with it, and I expect users' expectations are that once the configuration resolves itself to the point where there is a single protocol for all receivers, all of them become connected. Otherwise, the system will be in a state where the receivers for some subscriptions are connected and some are not.

Eric

Hi,

Thanks,

Tim

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 6 Oct 2017 00:58:15 +0000

From: Netconf [mailto:[email-masked]] On Behalf Of Tim Jenkins (timjenki)
Sent: Thursday, October 05, 2017 4:01 PM
To: Eric Voit (evoit) <[email-masked]>; [email-masked]
Subject: Re: [Netconf] Comments on draft-ietf-netconf-subscribed-notifications-05: receiver configuration

…

<Alex>  This seems a real corner case to me.  Is this really an issue?   I am also concerned about adding more complexity to the model (pretty complex already). The publisher has also the subscription status where it can indicate per-receiver status if there are issues with the way that notifications are sent. </ALEX>

---

From: "Tim Jenkins (timjenki)" <[email-masked]>
Date: Fri, 6 Oct 2017 13:07:56 +0000

From: Alexander Clemm <[email-masked]>
Date: Thursday, October 5, 2017 at 8:58 PM
To: "Tim Jenkins (timjenki)" <[email-masked]>, "Eric Voit (evoit)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Comments on draft-ietf-netconf-subscribed-notifications-05: receiver configuration

…

<Tim> In what sense is it a corner case? That the protocol will be changed when there is a single receiver for multiple subscriptions or that there is a misconfiguration when multiple identical receivers have to be independently configured identically? But it makes no difference. Because it's possble, it will happen and implementations will have to deal with it. And I can guarantee that the implementation complexity to deal with state is greater than the added complexity of adding a single top-level table to the model.</Tim>

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 6 Oct 2017 12:02:21 -0700

Hi -

On 10/5/2017 12:56 PM, Tim Jenkins (timjenki) wrote:
...
> Clearly, the subscription must stop using that connection. However, the 
> publisher cannot tear down the connection to the receiver because other 
> subscriptions are using it. And it also cannot create a connection to 
> the receiver of the modified subscription because there already exists a 
> connection (using the wrong protocol).

No.  It just means that the earlier "of course" is incorrect.
It seems to me that recognizing that connections are distinct objects
(not necessarily part of configuration) and that the choice of a
specific protocol is a property of a connection (for a subscriber it
would logically be a *set* of possible protocols) would allow an
escape from this dilemma.  It also means that *if* one were to make
the connections visible to management, that protocol would be one
of the identifying characteristics of a given connection.

Randy