Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00

Hi Tianran,

even if you’re adapting UDP for publication of YANG-modelled data (note you’re NOT adapting it for publication or NETCONF/RESTCONF) I suspect you can still build upon work others have done on reliable UDP mechanisms etc.    Even RTP does most of what you want (as it has sequence numbers, timestamps, sender IDs, support for different payload encodings etc.) - through granted it is targeted at a very different application space.

and if you do persist in trying to define your own transport then it might be worth thinking about whether you need a length field, whether reliability and authentication are per-stream (rather than per-packet as currently defined) and so on...

Giles

> On 24 Aug 2017, at 06:45, Tianran Zhou <zhoutianran@huawei.com> wrote:
> 
> Hi Giles,
> 
> I just updated the draft submission, so as to answer your question. Please see:
> https://datatracker.ietf.org/doc/draft-zheng-netconf-udp-pub-channel/
> 
> I tried to make it a complete work with both ps and solution. I also separate the subscription model from this document. As things progressed, now maybe a separate ps is not necessary to be published as a support documents.
> 
> We are not going to define a general purpose transport, but to adapt UDP for publication of NETCONF/RESTCONF. It's highly related to YANG Push work.
> The publication channel behavior will highly depend on the configuration/subscription.
> So I feel NETCONF is the right place to do this extension.
> And I believe the show-hands on the NETCONF meeting showed this work is important and can be done in NETCONF.
> 
> Thanks,
> Tianran
>> -----Original Message-----
>> From: Giles Heron [mailto:giles.heron@gmail.com]
>> Sent: Wednesday, August 23, 2017 9:57 PM
>> To: Tianran Zhou
>> Cc: netconf@ietf.org
>> Subject: Re: [Netconf] WG adoption poll
>> draft-zheng-netconf-udp-pub-channel-00
>> 
>> Hi Tianran,
>> 
>> sure - so maybe it’d be better to split this into 2 drafts (one for the
>> problem statement and one for the solution)?  That way you can progress those
>> separately.
>> 
>> Re UDP vs TCP my point was more that it seems strange to define your own
>> transport in a NETCONF draft.  Adding reliability to UDP is a solved problem
>> (many times over) so you should be able to pick one of the existing solutions.
>> 
>> Giles
>> 
>>> On 23 Aug 2017, at 09:28, Tianran Zhou <zhoutianran@huawei.com> wrote:
>>> 
>>> Hi Giles,
>>> 
>>> Thank you very much for your review and comments.
>>> This version we were going to state the problem, raise possible issues
>> that may need to solve, and attract WG interests. So there are some TBDs
>> in the detailed solution part.
>>> We hope the working group can adopt this work, and we can work on the
>> solution together with the community contributions.
>>> Since last meeting, we keep moving forward, and are working on the new
>> revision internally.
>>> In line, please see my reply.
>>> 
>>> Thanks,
>>> Tianran
>>> 
>>>> -----Original Message-----
>>>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Giles
>>>> Heron
>>>> Sent: Tuesday, August 22, 2017 6:39 PM
>>>> To: netconf@ietf.org
>>>> Subject: Re: [Netconf] WG adoption poll
>>>> draft-zheng-netconf-udp-pub-channel-00
>>>> 
>>>> There seem to be a few issues with this draft:
>>>> 
>>>> 1) it suggests a 32 bit field for device ID and then suggests generating
>>>> it from the MAC address.  48 into 32 doesn’t go.   Perhaps an EUI-64 makes
>>>> more sense?  Or do you even need this given that UDP packets tend to
>>>> have source IP addresses?
>>> 
>>> [ztr] We were to use the device ID to indicate the source of the data.
>> Just as you suggested, the UDP session identifier can be used. So in the
>> new version, we are going to use an message generator id for the device
>> level and plus the src-dst IP as well as port number.
>>> 
>>>> Or are you thinking in terms of NAT?
>>> [ztr] The NAT issue is a good catch, which we did not think about. We
>> assumed the device management port/interface and the collector are in the
>> same private network. Do you have any use case that the NAT will be used
>> when collecting data?
>>> 
>>>> Or of correlating
>>>> notifications from different line-cards on the same system that may
>>>> have different source IP addresses?
>>> [ztr] We suggest all the line cards on the same system use the same source
>> IP address. But the case you mentioned may happen. In this case, I think
>> the collector/subscriber may have the mapping from the source IP to device.
>>> 
>>> 
>>>> 2) the timestamp has 32 bits each of seconds and microseconds and
>>>> says those are as per RFC3339.  From my reading of RFC3339 it encodes
>>>> dates/times as strings.
>>> [ztr] Yes, it is not a suitable reference. We meant to say the encoding
>> will support the expression in RFC3339. But it seems the timestamp on message
>> generation is not so important to be accurate. So we tend to modify to:
>>>    "The Notification-Time, is the time at which the message leaves the
>>>     exporter, expressed in seconds since the UNIX epoch of 1 January
>>>     1970 at 00:00 UTC, encoded as an unsigned 32-bit integer."
>>> 
>>>> 3) building your own reliability mechanism on top of UDP seems like a
>>>> strange choice.  Why not just use TCP if you want reliable delivery?
>>>> Or re-use existing work on adding reliability to UDP if you see
>>>> issues with TCP? (in which case explain how reliability based on UDP
>> is better than TCP).
>>> [ztr] We are not going to provide the full reliability mechanism for UDP.
>> We just want to provide necessary support (sequence number) from the
>> transport. Then the application can decide the reaction to the packet loss/
>> reordering or so.
>>> In addition, I think the reliability may also have different levels. The
>> application may not care about any packet loss, or may need to record the
>> packet loss but not need retransmission, or need retransmission but no
>> ordering requirement from transport,... Simply using TCP seems not a good
>> option.
>>> 
>>>> 4) big chunks of the draft are left TBD (e.g. selecting encodings, adding
>>>> authentication/encryption options).    Again there may be work you can
>> reuse
>>>> there rather than defining your own.
>>> [ztr] Yes, based on the discussion in the community, the coming update
>> will focus on the necessary parts. For example, the subscription model may
>> move to a separate document. And we are not going to create authentication
>> algorithms, but to suggest algorithms and how to truncate to fit in the
>> header field. We will reuse existing work as much as possible.
>>> 
>>>> sections 1 - 3 are generally ok - but don’t really say anything we
>>>> didn’t know already...
>>>> 
>>>> Giles
>>>> 
>>>>> On 22 Aug 2017, at 02:46, Lizhenbin <lizhenbin@huawei.com> wrote:
>>>>> 
>>>>> Yes/Support.
>>>>> 
>>>>> Best Regards,
>>>>> Zhenbin(Robin)
>>>>> 
>>>>> 
>>>>> 
>>>>> -----邮件原件-----
>>>>> 发件人: Netconf [mailto:netconf-bounces@ietf.org] 代表 Kent Watsen
>>>>> 发送时间: 2017年8月22日 6:04
>>>>> 收件人: netconf@ietf.org
>>>>> 主题: [Netconf] WG adoption poll
>>>>> draft-zheng-netconf-udp-pub-channel-00
>>>>> 
>>>>> All,
>>>>> 
>>>>> This is start of a two-week poll on making the following draft a
>>>>> NETCONF
>>>> working group document:
>>>>> 
>>>>> draft-zheng-netconf-udp-pub-channel-00 [1]
>>>>> 
>>>>> Please send email to the list indicating "yes/support" or "no/do not
>>>> support".  If indicating no, please state your reservations with the
>>>> document.  If yes, please also feel free to provide comments you'd
>>>> like to see addressed once the document is a WG document.
>>>>> 
>>>>> 
>>>>> [1]
>>>> https://tools.ietf.org/html/draft-zheng-netconf-udp-pub-channel-00
>>>>> 
>>>>> 
>>>>> Thank you,
>>>>> Kent (and Mahesh)
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Netconf mailing list
>>>>> Netconf@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>> _______________________________________________
>>>>> Netconf mailing list
>>>>> Netconf@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>> 
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> Netconf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netconf
> 