Subject: Re: [Netconf] SN #6 String or Integer for Subscription ID

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 14 Nov 2017 08:40:50 +0000

After lots of interactions and good discussion, a majority of people have expressed a desire for integer over string for the identification of configured subscriptions.  Based on that I am closing the issue SN#6 with no changes to the yang model.

https://github.com/netconf-wg/rfc5277bis/issues/6

Eric

From: Netconf [mailto:[email-masked]] On Behalf Of Tim Jenkins (timjenki)
Sent: Monday, October 23, 2017 2:49 PM
To: [email-masked]
Subject: Re: [Netconf] SN #6 String or Integer for Subscription ID

All,

This note attempts to take a detailed look at the two main proposals for the use of subscription IDs for the subscribed notifications draft.

The two proposals that I'll examine here are 'single integer ID type' and 'mixed ID type' as I'm referring to them. Proposals where the update notifications are different from configured subscriptions and dynamic subscriptions are not considered, since that is highly undesirable and more complex.

In the 'single integer ID type' proposal, the subscription records in both the configuration and operational tables of subscriptions are indexed by a 32-bit integer value. Since configured subscriptions also appear in the operational table, the index space is common between configured and operational subscriptions. Subscribers create the configured subscription IDs, while the publisher creates the dynamic subscription IDs. Thus, there is an issue of potential conflict; it has been proposed to split the space between subcriber and publisher generated to remove this potential conflict.

In the 'mixed ID type' proposal, configured subscriptions are created with a string ID by the subscriber, and dynamic subscriptions are created with a 32-bit integer ID by the publisher. The publisher also creates a 32-bit integer ID for configured subscriptions, so they effectively have two IDs. These are referred to as the subscriber and publish IDs for the rest of this note. The configured subscriptions table is indexed by the subscriber ID and the publisher ID does not appear in this table because it is not configuration data. The operational subscriptions table is indexed by the publisher ID and the subscriber ID appears in this table, but only for configured subscription entries.

I will attempt to evaluate the two proposals against some issues.

1/ How a receiver identifies which subscription an update notification's contents are associated with.

'single integer ID'               -uses only ID available, but can use the ID in the 'subscription-started' notification as well
'mixed IDs'                            -learns subscriber and publisher IDs from 'subscription-started' notification. This notification has to be modified to carry it, and receivers have to parse it.

2/ How the issue of multiple sources of ID generation is handled.

'single integer ID'               -split the 32-bit integer space for issue between publisher and subscribers; this does not solve issue among multiple subscribers
'mixed IDs'                           -not an issue between publisher and subscribers; but does not solve issue among multiple subscribers

3/ How subscriptions are associated across multiple publishers. That is, how do separate receivers know which subscriptions are considered to be the same when they arrive from different publishers?

'single integer ID'               -subscriber sends to receivers the IDs it used to create the subscriptions; it should have used the same ID for the same subscriptions on separate publishers
'mixed IDs'                           -subscriber sends to receivers the IDs it used to create the subscriptions; it should have used the same ID for the same subscriptions on separate publishers. The receivers must parse the 'subscription-started' notifications from publishers and create and maintain a map of integers IDs to text IDs. This map must be used with update notifications, to determine the actual subscription ID of interest.

4/ How human readable information about the subscriptions is provided.

'single integer ID'               -an unrestricted text field can be added to subscriptions as needed. The addition of an unrestricted text field can be done for both configured and dynamic subscriptions if desired and makes the need for a text ID string unnecessary.
'mixed IDs'                           -the string ID used is limited: configured subscriptions only, and must be able to be a key

Additional Notes:

Integer ID Space Split: For the single integer ID case, this is a very simple solution to the problem. As currently proposed, the upper half of the 32-bit unsigned integer space is set aside for dynamic subscriptions, but other splits are possible. One would be to use signed integers, and use the sign to spit the space. This would allow the use of small integers for both configured and dynamic subscriptions when encoding rules can take advantage of such things.

Conclusion:

The use of a string as a subscription ID is overall more complicated than finding a simple solution for splitting the integer ID space between publisher and subscriber space.

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: Robert Wilton <[email-masked]>
Date: Wed, 15 Nov 2017 08:31:12 +0800

Hi Eric,

Does this mean that the configured-subscriptions and subscriptions tree 
will be combined into a single tree (NMDA style)?

Thanks,
Rob

On 14/11/2017 16:40, Eric Voit (evoit) wrote:
>
> After lots of interactions and good discussion, a majority of people 
> have expressed a desire for integer over string for the identification 
> of configured subscriptions.  Based on that I am closing the issue 
> SN#6 with no changes to the yang model.
>
> *From:*Netconf [mailto:[email-masked]] *On Behalf Of *Tim 
> Jenkins (timjenki)
> *Sent:* Monday, October 23, 2017 2:49 PM
> *To:* [email-masked]
> *Subject:* Re: [Netconf] SN #6 String or Integer for Subscription ID
>
> All,
>
> This note attempts to take a detailed look at the two main proposals 
> for the use of subscription IDs for the subscribed notifications draft.
>
> The two proposals that I'll examine here are 'single integer ID type' 
> and 'mixed ID type' as I'm referring to them. Proposals where the 
> update notifications are different from configured subscriptions and 
> dynamic subscriptions are not considered, since that is highly 
> undesirable and more complex.
>
> In the 'single integer ID type' proposal, the subscription records in 
> both the configuration and operational tables of subscriptions are 
> indexed by a 32-bit integer value. Since configured subscriptions also 
> appear in the operational table, the index space is common between 
> configured and operational subscriptions. Subscribers create the 
> configured subscription IDs, while the publisher creates the dynamic 
> subscription IDs. Thus, there is an issue of potential conflict; it 
> has been proposed to split the space between subcriber and publisher 
> generated to remove this potential conflict.
>
> In the 'mixed ID type' proposal, configured subscriptions are created 
> with a string ID by the subscriber, and dynamic subscriptions are 
> created with a 32-bit integer ID by the publisher. The publisher also 
> creates a 32-bit integer ID for configured subscriptions, so they 
> effectively have two IDs. These are referred to as the subscriber and 
> publish IDs for the rest of this note. The configured subscriptions 
> table is indexed by the subscriber ID and the publisher ID does not 
> appear in this table because it is not configuration data. The 
> operational subscriptions table is indexed by the publisher ID and the 
> subscriber ID appears in this table, but only for configured 
> subscription entries.
>
> 1/ How a receiver identifies which subscription an update 
> notification's contents are associated with.
>
> 'single integer ID'               -uses only ID available, but can use 
> the ID in the 'subscription-started' notification as well
>
> 'mixed IDs'                            -learns subscriber and 
> publisher IDs from 'subscription-started' notification. This 
> notification has to be modified to carry it, and receivers have to 
> parse it.
>
> 'single integer ID'               -split the 32-bit integer space for 
> issue between publisher and subscribers; this does not solve issue 
> among multiple subscribers
>
> 'mixed IDs'                           -not an issue between publisher 
> and subscribers; but does not solve issue among multiple subscribers
>
> 3/ How subscriptions are associated across multiple publishers. That 
> is, how do separate receivers know which subscriptions are considered 
> to be the same when they arrive from different publishers?
>
> 'single integer ID'               -subscriber sends to receivers the 
> IDs it used to create the subscriptions; it should have used the same 
> ID for the same subscriptions on separate publishers
>
> 'mixed IDs'                           -subscriber sends to receivers 
> the IDs it used to create the subscriptions; it should have used the 
> same ID for the same subscriptions on separate publishers. The 
> receivers must parse the 'subscription-started' notifications from 
> publishers and create and maintain a map of integers IDs to text IDs. 
> This map must be used with update notifications, to determine the 
> actual subscription ID of interest.
>
> 'single integer ID'               -an unrestricted text field can be 
> added to subscriptions as needed. The addition of an unrestricted text 
> field can be done for both configured and dynamic subscriptions if 
> desired and makes the need for a text ID string unnecessary.
>
> 'mixed IDs'                           -the string ID used is limited: 
> configured subscriptions only, and must be able to be a key
>
> Additional Notes:
>
> Integer ID Space Split: For the single integer ID case, this is a very 
> simple solution to the problem. As currently proposed, the upper half 
> of the 32-bit unsigned integer space is set aside for dynamic 
> subscriptions, but other splits are possible. One would be to use 
> signed integers, and use the sign to spit the space. This would allow 
> the use of small integers for both configured and dynamic 
> subscriptions when encoding rules can take advantage of such things.
>
> Conclusion:
>
> The use of a string as a subscription ID is overall more complicated 
> than finding a simple solution for splitting the integer ID space 
> between publisher and subscriber space.
>
> Tim
>
> -- 
>
> Cisco Systems Canada Co.
>
> 2000 Innovation Drive
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 16 Nov 2017 01:46:27 +0000

Yes.   We are committing to publish NMDA style trees when YANG push is deemed ready for WGLC.  People can then do an apples-to-apples comparison between the two representations.

Eric

From: Robert Wilton, November 14, 2017 7:31 PM

i Eric,

Does this mean that the configured-subscriptions and subscriptions tree will be combined into a single tree (NMDA style)?

Thanks,
Rob

Eric

From: Netconf [mailto:[email-masked]] On Behalf Of Tim Jenkins (timjenki)
Sent: Monday, October 23, 2017 2:49 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] SN #6 String or Integer for Subscription ID

All,

Additional Notes:

Conclusion:

Tim

Netconf mailing list

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