Re: [Netconf] subscription-id management across applications

["Eric Voit (evoit)" <[e-mail]>]

> Juergen Schoenwaelder, , July 9, 2018 12:43 PM
> 
> On Mon, Jul 09, 2018 at 09:34:17AM -0700, Andy Bierman wrote:
> > On Mon, Jul 9, 2018 at 9:31 AM, Juergen Schoenwaelder <
> > [e-mail]> wrote:
> >
> > > On Mon, Jul 09, 2018 at 09:12:57AM -0700, Andy Bierman wrote:
> > > > 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.
> > >
> > > Why would a server accept a dynamic subscription that clashes with a
> > > configured subscription?
> > >
> > >
> > I don't think it would.
> > The issue is how applications share the range allocated for configured
> > subscriptions.
> 
> 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
 
> /js
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf