Re: [netconf] SN and indirection

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

> From: Martin Bjorklund, August 30, 2019 8:24 AM
> 
> Kent Watsen <[e-mail]> wrote:
> > In the https-notif adoption call, Martin writes:
> >
> > > (*) An observation: This module introduces a level of indirection
> > > for receivers; something we should have done in the
> > > subscribed-notifications model directly.  Perhaps we should revisit
> > > that model and add the indirection there instead.
> >
> > What is meant by “revisit”?  SN is in Auth48.  Pull it back or start a
> > bis now?
> 
> I meant a bis.

Back when the authors were first discussing the intersections of SN and Multi-stream, there were a number of other complexities which were considered.  A related was one the mobility of YANG subtrees between publisher line cards.  This relevant for example if a BRAS moves some sessions from one line card to another.  Or if there is a failover.  So as a receiver, how do you know that the full set of YANG objects promised are being provided across the sum of stream originators?

At that time we thought such state mobility could be done by an augmentations to the state change notification listing the subtrees being handled by different originators within the Publisher. (If we eventually go down this path, we should likewise add which line cards are serving which elements of the subscription as part of the RPC response.  There might be implications to the dynamic-subscription state machine which need to be thought through as well.)

As a result of the complexities, we held off of integrating the question into the current SN.  We just needed to get something done there.   This is defendable as the majority of publishers won't need to worry about the complexities of multi-stream origination.  If someone is interested in tackling these types of complexities as part of a bis, that would be great.

Eric

> /martin
> 
> 
> > FWIW, it seems that SN also lacks a structure conducive to supporting
> > multi-stream originators.
> >
> > Kent // any hat
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf