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

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