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

[Andy Bierman <[e-mail]>]

On Thu, Aug 24, 2017 at 4:35 AM, Giles Heron <[e-mail]> wrote:

> 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...
>
>
I don't understand why we bother to organize the IETF into areas of
expertise, if we are just going to
ignore that and produce ad-hoc point solutions in any WG.  IMO the NETCONF
WG does not have
the transport area expertise to to a great job on this work.  Clearly the
transport area has the experts
to understand all pre-existing solutions and all pre-existing issues (like
congestion).

How is the IESG going to ensure that there are sufficient transport area
experts involved
in the entire development cycle for this standard?



Giles
>

Andy


>
> > On 24 Aug 2017, at 06:45, Tianran Zhou <[e-mail]> 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:[e-mail]]
> >> Sent: Wednesday, August 23, 2017 9:57 PM
> >> To: Tianran Zhou
> >> Cc: [e-mail]
> >> 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 <[e-mail]> 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:[e-mail]] On Behalf Of Giles
> >>>> Heron
> >>>> Sent: Tuesday, August 22, 2017 6:39 PM
> >>>> To: [e-mail]
> >>>> 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 <[e-mail]> wrote:
> >>>>>
> >>>>> Yes/Support.
> >>>>>
> >>>>> Best Regards,
> >>>>> Zhenbin(Robin)
> >>>>>
> >>>>>
> >>>>>
> >>>>> -----邮件原件-----
> >>>>> 发件人: Netconf [mailto:[e-mail]] 代表 Kent Watsen
> >>>>> 发送时间: 2017年8月22日 6:04
> >>>>> 收件人: [e-mail]
> >>>>> 主题: [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
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/netconf
> >>>>> _______________________________________________
> >>>>> Netconf mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/netconf
> >>>>
> >>>> _______________________________________________
> >>>> Netconf mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/netconf
> >
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>