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

From: "Tim Jenkins (timjenki)" <[email-masked]>
Date: Mon, 23 Oct 2017 18:49:08 +0000

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: Martin Bjorklund <[email-masked]>
Date: Tue, 24 Oct 2017 09:09:55 +0200 (CEST)

"Tim Jenkins (timjenki)" <[email-masked]> wrote:
> 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

You forgot to mention that receivers have to parse this notification
in order to learn the id (this was apparently a drawback in the
'mixed-ids" case below).

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

But you can never guarantee that the id you want to use is available
on all systems, unless you have total control over all apps.  And even
if you do, this requires an additional step where someone has to
allocate ids for subscriber apps and hand them out to all apps.

So a robust subscriber have to deal with the case that different integers
are used on different systems, and you will end up with the same kind
of map as in the mixed id case.

/martin

> '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.
> 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

---

From: Robert Wilton <[email-masked]>
Date: Tue, 24 Oct 2017 10:51:11 +0100

On 24/10/2017 08:09, Martin Bjorklund wrote:
> <snipped>
I get how having a client allocating the unique ID can make life a 
little easier for a client, because they don't need to learn the device 
generated subscription id.  But I don't really understand why this is 
only an issue for configured subscriptions but not dynamic subscriptions.

Another option here, would be to split the subscriber-id space between 
client managed and device managed, and then allow a client to optionally 
provide the subscriber-id (from the client managed space) for both 
configured and dynamic subscriptions.  If the client provides an id then 
it must ensure that they are unique or otherwise the device rejects the 
configured/dynamic subscription request.  If the client doesn't provide 
an id then the device internally allocates one, i.e. as it does today, 
and in the same way for both configured and dynamic subscriptions.

Configured subscriptions are still identified by a unique string, but of 
course if a client is choosing to managing unique subscription-ids, then 
can just reuse that subscription-id for the name as well if they want.

One further tweak that might be required to make this work better would 
be to further split the client managed id space between configured and 
dynamic subscriptions so that the uniqueness of a client provided 
configuration subscription-id could be verified during config validation.

E.g.

     +--rw subscription-config {configured-subscriptions}?
     |  +--rw subscription* [name]
     |     +- rw name                 string
     |     +--rw identifier?          subscription-id  [1 - 1,000,000]
     |     +--rw encoding?            encoding

     +--ro subscriptions
        +--ro subscription* [identifier]
           +--ro identifier                 subscription-id
           +--ro configured-subscription?   string
           +--ro encoding?                  encoding

  +---x establish-subscription
     |  +---w input
     |  |  +---w identifier?          subscription-id [1,000,001 - int32-max]
     |  |  +---w encoding?            encoding
     |  |  +---w (target)
     |  |  |  +--:(stream)

Downsides:
- requires a separate table for configured subscriptions.
- the same issue regarding efficient subscription-id allocation exists, 
but now the subscriber-id space would probably need to be partitioned 
into 3 (client-managed-cfg, client-managed-dynamic, device managed).

Thanks,
Rob

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 24 Oct 2017 14:24:23 +0000

Hi Robert,

From: Robert Wilton, October 24, 2017 5:51 AM

"Tim Jenkins (timjenki)" <[email-masked]><mailto:[email-masked]> wrote:
<snipped>

subscribers

of map as in the mixed id case.
I get how having a client allocating the unique ID can make life a little easier for a client, because they don't need to learn the device generated subscription id.  But I don't really understand why this is only an issue for configured subscriptions but not dynamic subscriptions.

<eric> With a dynamic subscription, the association with the requesting application is known when the first information is sent from publisher to receiver.  I.e., you already know what receiver application has requested the content of this subscription.   With a configured subscription a receiver can more easily determine whether it wants to accept notification messages (and where to forward them within the receiver) if the subscription uses well-known subscription-ids.  (e.g., see Section 3.1.3 of draft-ietf-netconf-restconf-notif).

Another option here, would be to split the subscriber-id space between client managed and device managed, and then allow a client to optionally provide the subscriber-id (from the client managed space) for both configured and dynamic subscriptions.  If the client provides an id then it must ensure that they are unique or otherwise the device rejects the configured/dynamic subscription request.  If the client doesn't provide an id then the device internally allocates one, i.e. as it does today, and in the same way for both configured and dynamic subscriptions.

<eric> I think this is very interesting, and could be held as a future or vendor specific possibility.   Instead of reserving the 1/2 the subscription-id space for configured subscriptions, you could save 1/2 the subscription-id space for externally provided subscription-ids.  And yes, this would allow for future RPC growth where a dynamic subscription could provide a desired subscription-id as an input parameter. Nothing would need to change in the current drafts except that the definition of the reserved subscription-id space.

Configured subscriptions are still identified by a unique string, but of course if a client is choosing to managing unique subscription-ids, then can just reuse that subscription-id for the name as well if they want.

<eric> I still like the idea of a larger text string for a configured subscription which is non-key (allowing it to be large and descriptive).   I didn’t put it into the latest version pending the outcome of this discussion.

One further tweak that might be required to make this work better would be to further split the client managed id space between configured and dynamic subscriptions so that the uniqueness of a client provided configuration subscription-id could be verified during config validation.

<eric> Agree that something like the below would be needed in this scenario.

E.g.

    |     +- rw name                 string

    +--ro subscriptions

          +--ro encoding?                  encoding

    |  +---w input

    |  |  +---w (target)

    |  |  |  +--:(stream)

Downsides:
- requires a separate table for configured subscriptions.
- the same issue regarding efficient subscription-id allocation exists, but now the subscriber-id space would probably need to be partitioned into 3 (client-managed-cfg, client-managed-dynamic, device managed).

<eric> Agree on the downsides.   We can leave this on the table as a possible future by rewording the “reserved subscription-id space” so that it does not preclude this future.

Thanks,
Eric

Thanks,
Rob

/martin

interest.

'mixed IDs' -the string ID used is limited: configured subscriptions

only, and must be able to be a key

Additional Notes:

Conclusion:

Tim

--

Cisco Systems Canada Co.

2000 Innovation Drive

Preferences <http://www.cisco.com/offer/subscribe/?sid=000478326><http://www.cisco.com/offer/subscribe/?sid=000478326>

Unsubscribe <http://www.cisco.com/offer/unsubscribe/?sid=000478327><http://www.cisco.com/offer/unsubscribe/?sid=000478327>

Privacy <http://www.cisco.com/web/siteassets/legal/privacy.html><http://www.cisco.com/web/siteassets/legal/privacy.html>

Netconf mailing list

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

.