Subject: [Netconf] subscription-id management across applications

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Jul 2018 09:12:57 -0700

Hi,

The configured subscriptions use a uint32 subscription-id.
There is text in 5.2 about splitting the range for dynamic and configured
subscriptions:

   To support deployments including both configured and dynamic
   subscriptions, it is recommended to split subscription identifiers
   into static and dynamic halves.  That way it eliminates the
   possibility of collisions if the configured subscriptions attempt to
   set a subscription-id which might have already been dynamically
   allocated.  A best practice is to use lower half the "identifier"
   object's integer space when that "identifier" is assigned by an
   external entity (such as with a configured subscription).  This
   leaves the upper half of subscription identifiers available to be
   dynamically assigned by the publisher.

The draft does not say anything about how multiple independent applications
pick uint32 values that are not likely to collide with other applications.

Since configured subscriptions are expected to be usable by the client
the instant the NETCONF session is active, the app must be fairly sure
the hard-coded subscription-id values are really set correctly, and not
the IDs picked (and overwritten) by another application.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Jul 2018 18:31:44 +0200

>    dynamically assigned by the publisher.

Why would a server accept a dynamic subscription that clashes with
a configured subscription?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Jul 2018 09:34:17 -0700

> a configured subscription?
I don't think it would.
The issue is how applications share the range allocated for configured
subscriptions.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Jul 2018 18:42:36 +0200

> The issue is how applications share the range allocated for configured

This is not how I read the text. Splitting between dynamic and
configured does not solve the problem you think needs to be solved.
The problem, which I think the text hints at, is a situation where a
saved configuration cannot be restored due to dynamic subscriptions
clashing. To avoid this, separating the number spaces for configured
and dynamic subscriptions may be a good idea.

I think applications creating subscriptions should coordinate by
picking random values and being prepared to handle a failure if the
randomly picked value is already taken. Given the number space,
clashes should be rare.

/js

---

From: Robert Wilton <[email-masked]>
Date: Mon, 9 Jul 2018 17:49:25 +0100

On 09/07/2018 17:34, Andy Bierman wrote:
>
>
> On Mon, Jul 9, 2018 at 9:31 AM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
... which is the reason why I was arguing for string based ids for 
configured subscriptions.

Humans seemingly find it easier to give unique names to things instead 
of unique numbers.  And if they want to use the string representation of 
numbers as unique names, well that also works.

Perhaps someone need to standardize the equivalent of DNS for 
subscription ids ;-)

Thanks,
Rob

>     Fax:   +49 421 200 3103         <https://www.jacobs-university.de/
>     <https://www.jacobs-university.de/>>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Jul 2018 10:26:23 -0700

On Mon, Jul 9, 2018 at 9:49 AM, Robert Wilton <[email-masked]> wrote:

> Humans seemingly find it easier to give unique names to things instead of
> unique numbers.  And if they want to use the string representation of

+1

Given the incredibly long node names used in this YANG module, it's not as
if any
attempt to reduce the payload size is being made, so it seems especially odd
that subscription-id size should be a factor.  The string representation of
the
randomly generated 31 bit number is likely to be as long as a not-random
string
selected by the application.

>
> Perhaps someone need to standardize the equivalent of DNS for subscription
> ids ;-)
>
> Thanks,
> Rob
>
>
>
Andy

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 10 Jul 2018 00:39:31 +0000

> Juergen Schoenwaelder, , July 9, 2018 12:43 PM
> 
> > > Why would a server accept a dynamic subscription that clashes with a
> > > configured subscription?
> > >
> > >
> > I don't think it would.
> This is not how I read the text. Splitting between dynamic and configured does
> not solve the problem you think needs to be solved.
> The problem, which I think the text hints at, is a situation where a saved
> configuration cannot be restored due to dynamic subscriptions clashing. To
> avoid this, separating the number spaces for configured and dynamic
> subscriptions may be a good idea.

Yes this was part of the thinking.
 
> I think applications creating subscriptions should coordinate by picking random
> values and being prepared to handle a failure if the randomly picked value is
> already taken. Given the number space, clashes should be rare.

Yes this is a valid way to implement.

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 10 Jul 2018 00:39:31 +0000

From: Andy Bierman,  July 9, 2018 1:26 PM

On Mon, Jul 9, 2018 at 9:49 AM, Robert Wilton <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Jul 9, 2018 at 9:31 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

I don't think it would.
The issue is how applications share the range allocated for configured subscriptions.
... which is the reason why I was arguing for string based ids for configured subscriptions.

Humans seemingly find it easier to give unique names to things instead of unique numbers.  And if they want to use the string representation of numbers as unique names, well that also works.

+1

Given the incredibly long node names used in this YANG module, it's not as if any
attempt to reduce the payload size is being made, so it seems especially odd
that subscription-id size should be a factor.  The string representation of the
randomly generated 31 bit number is likely to be as long as a not-random string
selected by the application.

<Eric>  There are certainly good arguments for different approaches here.   To see a summary of the extensive WG analysis from last year here, check out:
https://github.com/netconf-wg/rfc5277bis/issues/6
Note: I don’t see in the thread request above to re-open this issue.  If that is not the case, please chime in.

Also on Andy’s point about long node names:
(a) From the beginning it has been assumed that in places where payload size is an issue, an efficient (non-text) encoding would be used.
(b) Almost all the event payload will be due to the contents of the encapsulated notifications.

Eric

Perhaps someone need to standardize the equivalent of DNS for subscription ids ;-)

Thanks,
Rob

Andy

/js

Andy

Netconf mailing list

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

https://www.ietf.org/mailman/listinfo/netconf<https://www..ietf.org/mailman/listinfo/netconf>

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 10 Jul 2018 07:06:25 +0000

Hi Rob,

Please see inline.

Tianran

From: Netconf [mailto:[email-masked]] On Behalf Of Robert Wilton
Sent: Tuesday, July 10, 2018 12:49 AM
To: Andy Bierman <[email-masked]>; Juergen Schoenwaelder <[email-masked]>; Netconf <[email-masked]>
Subject: Re: [Netconf] subscription-id management across applications

On Mon, Jul 9, 2018 at 9:31 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

I don't think it would.

[Tianran] But I did not see how string can help solve the ID conflict for different applications. Do you mean string can have a larger ID space?
On the other hand, we can manage several ID blocks, and map the blocks to related applications for configured subscription.

[Tianran] This is a good idea, only a little heavy/complex. ☺

Thanks,
Rob

/js

Andy

Netconf mailing list