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

[Andy Bierman <[e-mail]>]

On Thu, Aug 24, 2017 at 4:12 PM, Alexander Clemm <[e-mail]
> wrote:

> Couple of thoughts from my side:
>
> - Clearly, this addresses a valid problem.  Whether we should talk to
> transport area or keep here, not sure.  I am wondering where else it would
> fit charter-wise, and how much that would slow progress down.  Netconf
> already has all the context that is needed.
>

This is clearly a general problem.
NETCONF is not the first protocol WG that wants to push lots of data around.
I think IPFIX spent a lot of time on transport issues, maybe other WGs as
well.
No need to reinvent the wheel, right?

NETCONF is OK for this work as long as early cross-area reviews are done.



> - There are actually two aspects in the draft.  One concerns the UDP
> transport option that we are discussion here.  The other aspect concerns
> the fact that can have multiple message originators, such as multiple line
> cards each with its own stream but managed via one subscription.   This is
> what is currently outlined in section 3.  Maybe this is something that
> should be broken out into a separate draft, as potentially applicable to
> other transports, but that aspect arguably fits much better with netconf.
>
>
I agree YANG Push/NETCONF WG needs to define how a subscription can be
transported.
This includes 1 subscription with multiple receivers or multiple source
addresses.
Things get complicated if there are both on 1 subscription. (That's 1
reason why I prefer
to have only 1 receiver per subscription + a shorthand way to config
duplicate subscriptions).




> --- Alex
>

Andy


>
> -----Original Message-----
> From: Netconf [mailto:[e-mail]] On Behalf Of Giles Heron
> Sent: Thursday, August 24, 2017 4:35 AM
> To: Tianran Zhou <[e-mail]>
> Cc: [e-mail]
> Subject: 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 <[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
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>