Re: [Netconf] Issue SN #4: Can Transport vary across different receivers of a single configured subscription?

[Martin Bjorklund <[e-mail]>]

Hi,

Note that the issue is that the current model has:

      +--rw subscription* [identifier]
         ...
         +--rw encoding
         ...
         +--rw receivers
            +--rw receiver* [address port]
               ...
               +--rw protocol

My proposal is have encoding and protocol together:

(A)
      +--rw subscription* [identifier]
         ...
         ...
         +--rw receivers
            +--rw receiver* [address port]
               ...
               +--rw protocol
               +--rw encoding

or:

(B)
      +--rw subscription* [identifier]
         ...
         +--rw encoding
         +--rw protocol
         ...
         +--rw receivers
            +--rw receiver* [address port]
               ...

I think that this is *less* complex and probably more optimal than the
current solution.

"Einar Nilsen-Nygaard (einarnn)" <[e-mail]> wrote:
> Martin,
> 
> As yet, we have no practical use cases where we would have a single
> configured subscription with multiple receivers who wish to receive
> the data in different formats. Thus supporting this seems like an
> unnecessary complexity for platforms, and one which potentially
> impacts optimisations that we already use in some platform
> implementations (e.g. sending the same encoded PDU to multiple
> receivers, relieving the platform of encoding the same data multiple
> ways).

But this optimization doesn't really work, as you note below (*).

> Of course, if a client really wants to have the same data sent to
> multiple receivers but in different formats, they can do this — just
> provision separate subscriptions with the same filter.

Exactly; this is more complex and less optimal since the same filter
might be evaluated twice, unless you add code to optimize for that
(which probably falls in your category of "unnecessary complexity").

(*) So if the operator requires this setup, he will have to configure
two different subscriptions today.  Thus, the platform will encode the
data twice, and your optimization above won't help.

> All-in-all, I don’t see any benefit in making the base model support
> this, only downsides, so do you have any specific use cases in mind
> where this would be a benefit? So far in the use cases we have looked
> at in SP, DC, enterprise and IoT we have not seen any requirement to
> support this, but we have seen the need for multiple receivers
> (e.g. to support HA/redundancy approaches).

The current model supports different *protocols* for the different
receivers.  Do you have a use case supporting that, or would (B) above
fulfil your requirements.


/martin



> As such, I would be
> reluctant to add this to the draft at this stage when the
> functionality can be achieved already if absolutely necessary.
> 
> Cheers,
> 
> Einar
> 
> 
> > On 15 Nov 2017, at 21:53, Eric Voit (evoit) <[e-mail]> wrote:
> > 
> > Adding Einar as he had some strong opinions on this a few years ago
> > when we were setting the model...
> > 
> > 
> >> From: Martin Bjorklund, November 15, 2017 10:43 AM
> >> 
> >> "Eric Voit (evoit)" <[e-mail]> wrote:
> >>> Hi Martin,
> >>> 
> >>>> From: Martin Bjorklund [mailto:[e-mail]]
> >>>> 
> >>>> "Eric Voit (evoit)" <[e-mail]> wrote:
> >>>>> In the WG session tomorrow, I am hoping to get "hum feedback" on:
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> draft-ietf-netconf-subscribed-notifications
> >>>>> 
> >>>>> https://github.com/netconf-wg/rfc5277bis/issues/4
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> The two choices and their issues exposed during the two week
> >>>>> review on
> >>>> "Can Transport vary across different receivers of a single
> >>>> configured subscription?" are:
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> (1) Yes, Transport can vary by receiver
> >>>>> 
> >>>>> *        Fewer subscriptions (scale benefit)
> >>>>> 
> >>>>> *        Can convert transport without requiring an application to learn
> >> a
> >>>> multiple subscription ids
> >>>>> 
> >>>>> *        No duplication of content during transport conversion.
> >>>>> 
> >>>>> *        (Potential confusion in allowing transport to vary, but
> >>>>> *        encoding
> >> not
> >>>> to vary?)
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> (2) No, only one Transport across all subscriptions
> >>>>> 
> >>>>> *        Simpler model
> >>>>> 
> >>>>> *        But applications may need to create and track multiple
> >>>> subscription-ids for the same content.
> >>>>> 
> >>>>> *        Temporary duplication of content streams during transport
> >> change.
> >>>>> 
> >>>>> 
> >>>>> 
> >>>>> The current draft does (1).
> >>>> 
> >>>> Actually, the github issue lists 3 options, but here you just list 2.
> >>> 
> >>> In reviewing tomorrow's slides with Mahesh, he preferred 2 options.
> >>> And as varying the encoding by receiver seems unlikely in
> >>> implementation
> >> 
> >> Why is this unlikely?  Suppose I have two receivers for the same
> >> subscription, one wants NETCONF/XML and the other RESTCONF/JSON.  Is
> >> that unlikely?
> > 
> > Einar's belief was that a publisher implementation would be unlikely
> > to service a single subscription into multiple encodings.  If such a
> > condition existed, it would be far easier to create two subscriptions.
> > This also would have fewer error conditions.
> > 
> >>> , there is little reason to socialize this unlikely variant before
> >>> the whole WG.   Since as your opinion was either both encoding and
> >>> transport or neither encoding and transport vary by receiver, the more
> >>> likely of your primary ask is supported.
> >>> 
> >>> 
> >>>> I think the point is that in the term "Transport", we need to
> >>>> include both protocol and encoding (in the case the protocol
> >>>> supports multiple encodings).
> >>> 
> >>> While most likely the case for NETCONF and RESTCONF, Tianran's
> >>> draft-ietf-netconf-udp-pub-channel shows that there can be encoding
> >>> variation by transports .   It Therefore it seems better to let them
> >>> both vary independently.
> >> 
> >> Not sure I understand what you mean.  To be clear, do you think the
> >> "encoding" leaf should stay where it is, or be moved down to the
> >> receiver,
> >> as a sibling to "protocol"?
> > 
> > Encoding leaf should stay where it is.  Your previous ask was to put
> > encoding and transport and the same level. There is an option proposed
> > in the slides which does that.
> > 
> > Eric
> > 
> >> /martin
> > 
>