Subject: Re: [Netconf] SN #6 String or Integer for Subscription ID (was RE: draft-ietf-netconf-subscribed-notifications, anything else from the two week look?)

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

Message: 4
Date: Thu, 19 Oct 2017 19:22:42 +0100
From: Robert Wilton <[email-masked]<mailto:[email-masked]>>
To: "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>>, Martin Bjorklund
                <[email-masked]<mailto:[email-masked]>>,  Juergen Schoenwaelder
                <[email-masked]<mailto:[email-masked]>>, Kent Watsen
                <[email-masked]<mailto:[email-masked]>>, Henk Birkholz
                <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"
                <[email-masked]<mailto:[email-masked]>>, Carsten Bormann <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] SN #6 String or Integer for Subscription ID
                (was RE: draft-ietf-netconf-subscribed-notifications, anything else
                from the two week look?)
Message-ID: <[email-masked]<mailto:[email-masked]>>
Content-Type: text/plain; charset=utf-8; format=flowed

I think that my preference is still [D]: Use strings as the key for
configured subscriptions and then numerical ids for the operational
subscriptions (and only put the numeric ids into the messages).

<Tim>
I really do not want to implement something where the contents of the update notification differ based on the type of subscription. At the moment, the processing of a subscription, once it's been set up is essentially identical between configured subscriptions and dynamic subscriptions. It's only the control plane that is different, and I think it's important that we keeop to that as much as possible.

Further, in the above paragraph, what is the numeric ID that gets put into the "messages", assuming messages means update notifications for the configured subscriptions?

I would also be very careful about referring to OpenConfig telemetry as a good example of what to do. Our current experience with it is that much of it is underspecified and very young.

I really do not think the advantages of a string subscription ID outway the disadvantages either. For example, the exact issue of ID partitioning. At least with integers we can say the upper half of the space is reserved for dynamic subscriptions (or the odd values if we want to encourage the use of small integers). But how do you guarantee partitioning based on strings? Enforce that dynamic subscription IDs start with "dyn" or "d" or something?
</Tim>

That is also how the OpenConfig telemetry module that you reference
below works, i.e. strings for configured subscriptions and numerical ids
for dynamic subscriptions:

  grouping telemetry-subscription-name-config {
     description
       "Configuration parameters relating to the configured
        name of the telemetry subscription. The name is a user
        configured string value which uniquely identifies the
        subscription in the configuration database.";

      leaf subscription-name {
        type string;
        description
          "User configured identifier of the telemetry
           subscription. This value is used primarily for
           subscriptions configured locally on the network
           element.";
      }
   }

Thanks,
Rob

On 19/10/2017 18:12, Eric Voit (evoit) wrote:
Trying to summarize for readability.  I have articulated a few more advantages to Integer, please feel free to let me know items I missed for String.

[A]  Integer
*********
(A1) Efficiency of notification message processing: Comparing two numbers is magnitudes faster than comparing two strings (representing the same numbers). Sorting and forwarding of incoming messages on the receiver so that they go to the right requesting application will be faster.

(A2) Size: A subscription id based on characters will be larger than transport based on integer. As we have IoT drafts relating to CBOR, we should look at efficiency.

(A3) Easier to automatically generate IDs for dynamic subscriptions.  Enables easier conventions for sequential issuance of subscription-ids which can then be interpreted by subscriber

(A4) Can augment (or add now in the base model) a leaf containing a string definition of a configured subscription.  This string would be passed as part of the "subscription-started" notification, so there would be no need to query the publisher for a meaning.  Greater verbosity and redundancy in text definitions would then both be allowed.  This text only need be passed once, and can be safely ignored by the receiver implementations.

(A5) Low power IoT receivers.    Many small receivers of the same subscription might consume the same feed with a minimally sized, easier to process header. (Henk can provide sources for the use cases here.)

(A6) Subscription ID in the OpenConfig.yang model is also an integer (uint64)
See line 584 of: https://github.com/openconfig/public/blob/master/release/models/telemetry/openconfig-telemetry.yang
Implementations supporting both model exposures will need to worry less about mapping.

[B] String
********
(B1) Easier to read and understand the sub-domain segmentation of the subscription-id space, as well as the creation of new sub-domains

(B2) If Kent's question on the possibility of encoding frequently sent text fields in CBOR as integer comes back as viable, then the Size advantages of [A] go away

[C] union of integer and string.
*************************
As there are additional processing requirements in the receiver and key issues in the publisher, this would seem to have processing inefficiencies.  Does anyone want to argue for this?

Eric

------------------------------

Subject: Digest Footer

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

------------------------------

End of Netconf Digest, Vol 116, Issue 65
****************************************

---

From: Robert Wilton <[email-masked]>
Date: Thu, 19 Oct 2017 21:05:09 +0100

Hi Tim,

On 19/10/2017 19:33, Tim Jenkins (timjenki) wrote:
> From: Robert Wilton <[email-masked] <mailto:[email-masked]>>
>
> To: "Eric Voit (evoit)" <[email-masked] <mailto:[email-masked]>>, 
> Martin Bjorklund
>
> <[email-masked] <mailto:[email-masked]>>,  Juergen Schoenwaelder
>
> <[email-masked] 
> <mailto:[email-masked]>>, Kent Watsen
>
> <[email-masked] <mailto:[email-masked]>>, Henk Birkholz
>
> <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>"
>
> <[email-masked] <mailto:[email-masked]>>, 
> Carsten Bormann <[email-masked] <mailto:[email-masked]>>
>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
>
> Message-ID: <[email-masked] 
> <mailto:[email-masked]>>
>
> I really do not want to implement something where the contents of the 
> update notification differ based on the type of subscription. At the 
> moment, the processing of a subscription, once it's been set up is 
> essentially identical between configured subscriptions and dynamic 
> subscriptions. It's only the control plane that is different, and I 
> think it's important that we keeop to that as much as possible.
>
I'm proposing that subscription-id stays as a uint32, but that a string 
based "subscription-name" is used as the list key for configured 
subscriptions.   When the system instantiates a configured subscription 
it would assign a numerical subscription id from the same value space as 
dynamic subscriptions (and make that available as an oper leaf, so that 
clients can look up the mapping from configured subscription name to 
assigned numerical subscription id if required).  It is the numerical 
subscription id that would be used in the notification messages.  In 
fact, with this solution the numerical subscription ids would all likely 
be small integers and hence encoded more compactly either in XML/JSON or 
CBOR/GPB

My perception is that the advantages are:
  - This has all the encoding benefits of using a number, more compact 
messages, and having the server assigning ids from a numerical space.
  - It has all the benefits of a string based name being easier/more 
flexible for clients to manage.
  - It avoids the issue of having to partition the subscription-id space 
between configured and dynamic subscriptions, since they are separate.

The disadvantages are:
  - it requires a separate schema tree for configured subscriptions vs 
operational subscriptions (i.e. pretty much as the schema is defined in 
the drafts today ...)
  - clients may need to look up the mapping from configured subscription 
name to numerical id.

> Further, in the above paragraph, what is the numeric ID that gets put 
> into the "messages", assuming messages means update notifications for 
> the configured subscriptions?
>
The system assigned numerical subscription id.  I.e. exactly the same as 
for dynamic subscriptions.

> I would also be very careful about referring to OpenConfig telemetry 
> as a good example of what to do. Our current experience with it is 
> that much of it is underspecified and very young.
>
Hum, OK.  Eric was using that as justification for using numerical ids 
for both configured and dynamic subscriptions, but I was just pointing 
out that this is not what OpenConfig model actually does ...

> I really do not think the advantages of a string subscription ID 
> outway the disadvantages either. For example, the exact issue of ID 
> partitioning. At least with integers we can say the upper half of the 
> space is reserved for dynamic subscriptions (or the odd values if we 
> want to encourage the use of small integers). But how do you guarantee 
> partitioning based on strings? Enforce that dynamic subscription IDs 
> start with "dyn" or "d" or something?
>
If you use a separate string space for the names of configured 
subscriptions then you have no ID partitioning required at all, since 
they are separate value spaces.

Thanks,
Rob

>     Trying to summarize for readability.  I have articulated a few
>     more advantages to Integer, please feel free to let me know items
>     I missed for String.
>
>     [A]  Integer
>
>     *********
>
>     (A1) Efficiency of notification message processing: Comparing two
>     numbers is magnitudes faster than comparing two strings
>     (representing the same numbers). Sorting and forwarding of
>     incoming messages on the receiver so that they go to the right
>     requesting application will be faster.
>
>     (A2) Size: A subscription id based on characters will be larger
>     than transport based on integer. As we have IoT drafts relating to
>     CBOR, we should look at efficiency.
>
>     (A3) Easier to automatically generate IDs for dynamic
>     subscriptions.  Enables easier conventions for sequential issuance
>     of subscription-ids which can then be interpreted by subscriber
>
>     (A4) Can augment (or add now in the base model) a leaf containing
>     a string definition of a configured subscription.  This string
>     would be passed as part of the "subscription-started"
>     notification, so there would be no need to query the publisher for
>     a meaning.  Greater verbosity and redundancy in text definitions
>     would then both be allowed.  This text only need be passed once,
>     and can be safely ignored by the receiver implementations.
>
>     (A5) Low power IoT receivers.    Many small receivers of the same
>     subscription might consume the same feed with a minimally sized,
>     easier to process header. (Henk can provide sources for the use
>     cases here.)
>
>     See line 584 of:
>     https://github.com/openconfig/public/blob/master/release/models/telemetry/openconfig-telemetry.yang
>
>     (B1) Easier to read and understand the sub-domain segmentation of
>     the subscription-id space, as well as the creation of new sub-domains
>
>     (B2) If Kent's question on the possibility of encoding frequently
>     sent text fields in CBOR as integer comes back as viable, then the
>     Size advantages of [A] go away
>
>     As there are additional processing requirements in the receiver
>     and key issues in the publisher, this would seem to have
>     processing inefficiencies.  Does anyone want to argue for this?
>
>     Eric
>
> [email-masked] <mailto:[email-masked]>
>
> [email-masked]

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 19 Oct 2017 22:14:53 +0200

Hi all,

a general comment - not intended to be a proposal - is this:

If,

and I understand the reasoning for putting:

> It avoids the issue of having to partition the subscription-id space between configured and dynamic subscriptions, since they are separate

into the "advantage category",

someone, who is considering to use only numbers to categorize two 
distinct ID spaces via a single value, could use a signed integer. There 
is some precedence for that in the IETF.

Again, this is just intended to be a comment to focus the discussion and 
not meant to be a proposal.

Viele Grüße,

Henk

---

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

From: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]>
Date: Thursday, October 19, 2017 at 4:05 PM
To: "Tim Jenkins (timjenki)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Netconf] SN #6 String or Integer for Subscription ID (was RE: draft-ietf-netconf-subscribed-notifications, anything else from the two week look?)

Hi Tim,

Message: 4

<Tim>
I really do not want to implement something where the contents of the update notification differ based on the type of subscription. At the moment, the processing of a subscription, once it's been set up is essentially identical between configured subscriptions and dynamic subscriptions. It's only the control plane that is different, and I think it's important that we keeop to that as much as possible.
I'm proposing that subscription-id stays as a uint32, but that a string based "subscription-name" is used as the list key for configured subscriptions.   When the system instantiates a configured subscription it would assign a numerical subscription id from the same value space as dynamic subscriptions (and make that available as an oper leaf, so that clients can look up the mapping from configured subscription name to assigned numerical subscription id if required).  It is the numerical subscription id that would be used in the notification messages.  In fact, with this solution the numerical subscription ids would all likely be small integers and hence encoded more compactly either in XML/JSON or CBOR/GPB

<Tim>
If the subscription ID of the configured subscription is in the table of configured subscriptions, it cannot have a system assigned value of any type, if system is the publisher. All values in the configuration table have to come from the configuration commands (the NETCONF "edit-config"), other than defaults which are fixed in value. At least, that's my understanding when I went through this discussion many months ago.

In any case, if it ends up there are two separate fields, one called subscription-id, and the other subscription-name which is not sent in update notification, why not just make the subscription-name a subscsription-description field, and add that as a parameter to "establish-subscription" and "modify-subscription"?

Of course, if the publisher cannot provide the subscription-id for configured subscriptions as mentioned above, then the ID space problem is still right where we are.
</Tim>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 19 Oct 2017 23:39:54 +0100

Hi Tim,

On 19/10/2017 22:26, Tim Jenkins (timjenki) wrote:
>
> *From: *"Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" 
> <[email-masked]>
> *Date: *Thursday, October 19, 2017 at 4:05 PM
> *To: *"Tim Jenkins (timjenki)" <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> *Subject: *Re: [Netconf] SN #6 String or Integer for Subscription ID 
>     To: "Eric Voit (evoit)" <[email-masked]
>     <mailto:[email-masked]>>, Martin Bjorklund
>
>     <mailto:[email-masked]>>,
>     "[email-masked] <mailto:[email-masked]>"
>
>     I really do not want to implement something where the contents of
>     the update notification differ based on the type of subscription.
>     At the moment, the processing of a subscription, once it's been
>     set up is essentially identical between configured subscriptions
>     and dynamic subscriptions. It's only the control plane that is
>     different, and I think it's important that we keeop to that as
>     much as possible.
>
> I'm proposing that subscription-id stays as a uint32, but that a 
> string based "subscription-name" is used as the list key for 
> configured subscriptions.   When the system instantiates a configured 
> subscription it would assign a numerical subscription id from the same 
> value space as dynamic subscriptions (and make that available as an 
> oper leaf, so that clients can look up the mapping from configured 
> subscription name to assigned numerical subscription id if required).  
> It is the numerical subscription id that would be used in the 
> notification messages.  In fact, with this solution the numerical 
> subscription ids would all likely be small integers and hence encoded 
> more compactly either in XML/JSON or CBOR/GPB
>
> <Tim>
>
> If the subscription ID of the configured subscription is in the table 
> of configured subscriptions, it cannot have a system assigned value of 
> any type, if system is the publisher. All values in the configuration 
> table have to come from the configuration commands (the NETCONF 
> "edit-config"), other than defaults which are fixed in value. At 
> least, that's my understanding when I went through this discussion 
> many months ago.
>

There are two subscription tables (lists):

1) Configured subscription list, using a subscription name as a key.  
Each configured subscription would have a child config false leafref 
leaf to the subscription-id of the associated operational subscription.
2) Operational (config false) subscriptions list, using a numerical 
subscription id as a key.  This table contains all the operational 
properties of all subscriptions, i.e. both configured and dynamic.

> In any case, if it ends up there are two separate fields, one called 
> subscription-id, and the other subscription-name which is not sent in 
> update notification, why not just make the subscription-name a 
> subscsription-description field, and add that as a parameter to 
> "establish-subscription" and "modify-subscription"?
>
Because it forces management of the value space of the subscription-id 
to have to be shared between all clients and the publisher.

> Of course, if the publisher cannot provide the subscription-id for 
> configured subscriptions as mentioned above, then the ID space problem 
> is still right where we are.
>
With what I propose it is solved:
1) All configured subscription for a device must use a unique client 
specified name.  If there are multiple subscription clients then they 
must choose names that don't clash.
2) All operational subscriptions (configured and dynamic) are allocated 
a unique publishing device subscription-id.  The device can trivially 
allocate the ids from the sequence of positive integers.

Thanks,
Rob