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

[Giles Heron <[e-mail]>]

Hi Alex,

> On 25 Aug 2017, at 01:08, Alexander Clemm <[e-mail]> wrote:
> 
> Hi Andy
>  
> <ALEX>, inline
>  
> --- Alex
>  
> From: Andy Bierman [mailto:[e-mail] <mailto:[e-mail]>] 
> Sent: Thursday, August 24, 2017 4:46 PM
> To: Alexander Clemm <[e-mail] <mailto:[e-mail]>>
> Cc: Giles Heron <[e-mail] <mailto:[e-mail]>>; Tianran Zhou <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Subject: Re: [Netconf] WG adoption poll draft-zheng-netconf-udp-pub-channel-00
>  
>  
>  
> On Thu, Aug 24, 2017 at 4:12 PM, Alexander Clemm <[e-mail] <mailto:[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.
>  
> <ALEX> Sounds reasonable to me </ALEX>

likewise.   Hopefully the transport folk can point the authors in the right direction.  As Andy says - we want to avoid reinventing the wheel.
> - 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> Actually, this here is a different case – not concerning receivers – we will have multiple senders per subscription… </ALEX>
> 

right - “multiple source addresses” as Andy stated?

Giles

>  
> --- Alex
>  
> Andy
>  
> 
> -----Original Message-----
> From: Netconf [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Giles Heron
> Sent: Thursday, August 24, 2017 4:35 AM
> To: Tianran Zhou <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[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] <mailto:[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/ <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] <mailto:[e-mail]>]
> >> Sent: Wednesday, August 23, 2017 9:57 PM
> >> To: Tianran Zhou
> >> Cc: [e-mail] <mailto:[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] <mailto:[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] <mailto:[e-mail]>] On Behalf Of Giles
> >>>> Heron
> >>>> Sent: Tuesday, August 22, 2017 6:39 PM
> >>>> To: [e-mail] <mailto:[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] <mailto:[e-mail]>> wrote:
> >>>>>
> >>>>> Yes/Support.
> >>>>>
> >>>>> Best Regards,
> >>>>> Zhenbin(Robin)
> >>>>>
> >>>>>
> >>>>>
> >>>>> -----邮件原件-----
> >>>>> 发件人: Netconf [mailto:[e-mail] <mailto:[e-mail]>] 代表 Kent Watsen
> >>>>> 发送时间: 2017年8月22日 6:04
> >>>>> 收件人: [e-mail] <mailto:[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 <https://tools.ietf.org/html/draft-zheng-netconf-udp-pub-channel-00>
> >>>>>
> >>>>>
> >>>>> Thank you,
> >>>>> Kent (and Mahesh)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Netconf mailing list
> >>>>> [e-mail] <mailto:[e-mail]>
> >>>>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> >>>>> _______________________________________________
> >>>>> Netconf mailing list
> >>>>> [e-mail] <mailto:[e-mail]>
> >>>>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> >>>>
> >>>> _______________________________________________
> >>>> Netconf mailing list
> >>>> [e-mail] <mailto:[e-mail]>
> >>>> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> >
> 
> _______________________________________________
> Netconf mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> _______________________________________________
> Netconf mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>