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

["Einar Nilsen-Nygaard (einarnn)" <[e-mail]>]

(B) Would be fine for me.

Cheers,

Einar


> On 16 Nov 2017, at 07:53, Martin Bjorklund <[e-mail]> wrote:
> 
> 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
>>> 
>>