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

[Robert Wilton <[e-mail]>]

On 17/11/2017 18:17, Eric Voit (evoit) wrote:
> In the meeting room discussion during the NETCONF WG, sentiment was to use a common Transport across all receivers of a single configured subscription.   This was proposal (2) below.
>
> I would like to see if there is any objection to this.   If not, we can close this issue in a few weeks.
No objection to proposal 2 (B) below, which keeps it simple for now.

If there is a future requirement to support different transports and/or 
encodings for a subscription, then it looks like there is also a viable 
upgrade path to also support (A) under a feature statement or using an 
augmenting module, perhaps with some appropriate when/must constraints.

I.e. choosing the more simple solution now, doesn't seem to rule out 
extending it to the more complex solution in future, if the need arises.

Thanks,
Rob


>
> Eric
>
>> -----Original Message-----
>> From: Netconf [mailto:[e-mail]] On Behalf Of Eric Voit
>> (evoit)
>> Sent: Thursday, November 16, 2017 3:30 AM
>> To: Martin Bjorklund <[e-mail]>; Einar Nilsen-Nygaard (einarnn)
>> <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: [Netconf] Issue SN #4: Can Transport vary across different
>> receivers of a single configured subscription?
>>
>> Hi Martin,
>>
>> Yes, I originally had both your options in the WG slides.    I removed (A)
>> after discussion with Mahesh for the WG session slides to simplify the in-
>> room discussions, as well as consideration of the points Einar makes below.
>> We can of course have more and deeper resolution discussions here.
>>
>> Thanks,
>> Eric
>>
>>> -----Original Message-----
>>> From: Martin Bjorklund [mailto:[e-mail]]
>>> Sent: Thursday, November 16, 2017 2:54 AM
>>> To: Einar Nilsen-Nygaard (einarnn) <[e-mail]>
>>> Cc: Eric Voit (evoit) <[e-mail]>; [e-mail]
>>> Subject: Re: [Netconf] Issue SN #4: Can Transport vary across
>>> different receivers of a single configured subscription?
>>>
>>> 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
>> _______________________________________________
>> Netconf mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netconf
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf