Subject: [netconf] SN and indirection

From: Kent Watsen <[email-masked]>
Date: Fri, 30 Aug 2019 10:38:15 +0000

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?

FWIW, it seems that SN also lacks a structure conducive to supporting multi-stream originators.  

Kent // any hat

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 30 Aug 2019 12:00:06 +0000

We started implementing parts of  subscribed-notifications. Please don't reopen it. ONAP and 3GPP is considering to use this standard, please do not reopen it.
Balazs

-----Original Message-----
From: netconf <[email-masked]> On Behalf Of Kent Watsen
Sent: 2019. augusztus 30., péntek 12:38
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: [netconf] SN and indirection

Kent // any hat
_______________________________________________
netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 30 Aug 2019 14:24:05 +0200 (CEST)

> What is meant by “revisit”?  SN is in Auth48.  Pull it back or start a

I meant a bis.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Fri, 30 Aug 2019 13:39:39 +0000

>> What is meant by “revisit”?  SN is in Auth48.  Pull it back or start a

Excellent.

Back to the adoption call, do you mean as a pre-condition to defining any configured subscription notif transports and, perhaps, multi-stream originators too?    You wrote "perhaps" above, but in the spirit of pinning a plan down, what does the WG want to do here?

FWIW, there are currently no uses of the static configuration defined in SN, as only dynamic subscriptions are currently supported, so changing the static configuration structure defined in SN now should be relatively easy, that is, easier than doing it later.

My personal opinion is that the indirection introduced in https-notif is likely to be desired by all notif transports for configured subscriptions, but it's unclear to me if the leverage to be had by consolidating the pattern into SN is significantly better than the copy/pasting the pattern into each notif draft, especially when considering that we're not likely to ever have more than a few such notif drafts.  It may be that the only justifiable reason for consolidating the pattern into SN would be to enable some cross notif-transport configuration (i.e., the indirection can span notif transports), but I'm struggling to see how this might manifest, some examples would help.  Separately, patching the SN configuration model to support multi-stream originators is an obvious fix for that problem, but hopefully the design team the chairs proposed in Montreal can devise a clever solution that isn't so obtrusive.

Kent

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 30 Aug 2019 13:40:13 +0000

> From: Martin Bjorklund, August 30, 2019 8:24 AM
> 
> > > (*) An observation: This module introduces a level of indirection
> > > for receivers; something we should have done in the

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 30 Aug 2019 17:03:42 +0200 (CEST)

Kent Watsen <[email-masked]> wrote:
> Back to the adoption call, do you mean as a pre-condition to defining
> any configured subscription notif transports and, perhaps,
> multi-stream originators too?  You wrote "perhaps" above, but in the
> spirit of pinning a plan down, what does the WG want to do here?

I didn't mean as a pre-condition, but if the WG thinks it can be done
I'm all for it.

> FWIW, there are currently no uses of the static configuration defined
> in SN, as only dynamic subscriptions are currently supported, so
> changing the static configuration structure defined in SN now should
> be relatively easy, that is, easier than doing it later.
> 
> My personal opinion is that the indirection introduced in https-notif
> is likely to be desired by all notif transports for configured
> subscriptions

I agree.

> but it's unclear to me if the leverage to be had by
> consolidating the pattern into SN is significantly better than the
> copy/pasting the pattern into each notif draft, especially when
> considering that we're not likely to ever have more than a few such
> notif drafts.

If we don't have a generic indirection, I would like the current
https-notif solution better if it didn't put 'receivers' at the
top-level, but instead augmented it into '/sn:subscribers', and
renamed it to 'https-receivers'.  Further, the 'receiver-ref' should
probably be called 'https-receiver-ref' or something.

> It may be that the only justifiable reason for
> consolidating the pattern into SN would be to enable some cross
> notif-transport configuration (i.e., the indirection can span notif
> transports), but I'm struggling to see how this might manifest, some
> examples would help.  Separately, patching the SN configuration model
> to support multi-stream originators is an obvious fix for that
> problem, but hopefully the design team the chairs proposed in Montreal
> can devise a clever solution that isn't so obtrusive.

I watched the session on youtube, but I must admit that I don't
understand the problem.  Is there a description of the problem
somewhere?  If not, this belongs to a separate thread.

/martin