Re: [Netconf] request for comments on draft-ietf-netconf-udp-pub-channel

[Tianran Zhou <[e-mail]>]

Hi Martin,

Thanks for your suggestions.
Please see in line.

Best Regards,
Tianran
> -----Original Message-----
> From: Martin Bjorklund [mailto:[e-mail]]
> Sent: Tuesday, June 12, 2018 6:03 PM
> To: Tianran Zhou <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Netconf] request for comments on
> draft-ietf-netconf-udp-pub-channel
> 
> Hi,
> 
> Tianran Zhou <[e-mail]> wrote:
> > Hi Martin,
> >
> > Thank you very much for your review and comments.
> > Please see in line.
> >
> > Best Regards,
> > Tianran
> >
> > > -----Original Message-----
> > > From: Martin Bjorklund [mailto:[e-mail]]
> > > Sent: Monday, June 11, 2018 3:48 PM
> > > To: Tianran Zhou <[e-mail]>
> > > Cc: [e-mail]
> > > Subject: Re: [Netconf] request for comments on
> > > draft-ietf-netconf-udp-pub-channel
> > >
> > > Hi,
> > >
> > > I have read draft-ietf-netconf-udp-pub-channel-02, but struggle with
> > > some basics.
> > >
> > > I don't understand how this new transport is supposed to fit into
> > > the design of draft-ietf-netconf-subscribed-notifications.  For
> > > example, the udp-pub-channel draft seems to expect a request to
> > > "establish-subscription"
> > > over NETCONF to send the notifications over UDP.  But AFAICT this is
> > > not possible with the current design of establish-subscription.
> >
> > [ztr]:
> > Yes, within the design team, we discussed this also. We tried to fit
> > the existing design of
> > draft-ietf-netconf-subscribed-notifications(SN).
> > In the case of "establish-subscription", existing SN design require
> > the notification to use the same channel as the subscription. But the
> > distributed data collection
> > mechanism(draft-zhou-netconf-multi-stream-originators-02) cannot meet
> > this. Because the notification channel and the subscription channel
> > are always separated. So we require:
> >    "the Receiver and the Subscriber
> >    SHOULD be collocated.  So UPC can use the source IP address of the
> >    Subscription Channel as it's destination IP address.  The Receiver
> >    MUST support listening messages at the IANA-assigned PORT-X, but MAY
> >    be configured to listen at a different port."
> 
> I don't think this solves the problem.  I see two alternatives:
> 
> 1)  Extend the definition of establish-subscription in the
>     subscribed-notification draft so that it can handle notifications
>     on a different transport than the existing session.  Work out fate
>     sharing details etc.
> 
> 2)  Do not allow dynamic subscriptions for this notification
>     transport.

[ztr]: I prefer option 1. Because, though separate channels(i.e., the way to do notification changed), the user requirements of dynamic subscription do not change. Let's have a joint discussion with the SN authors in the mailing list.

 
> > It's not the only one issue. For configured subscription, SN requires
> > the "subscription-started" message before sending notifications.
> > However, for UDP, we cannot guarantee the notifications arrive the
> > receiver after the "subscription-started". We cannot guarantee
> > "subscription-started" will not lost neither. So I am wandering if the
> > "subscription-started" message is still necessary.
> 
> I'd rather have a single procedure for sending notfifs, and then document
> in this draft that due to the nature of UDP a receiver cannot depend on these
> state-notifs being received (or any notif).

[ztr]: Do you mean the receiver is always ready for accepting data, no matter what state-notifications are received? The publisher will still send those state-notifications anyway. But the receiver will only consider them for reference.

> > > Is the transport in this draft supposed to work for notifications in
> > > general, or only YANG push notifications?
> > >
> > > Also, it seems many of the references to yang-push really should be
> > > to subscribed-notifications.
> >
> > [ztr]:
> > We want to work for notifications in general. I noticed that
> > subscribed-notifications draft describes event stream. And YANG-Push
> > augments the SN and add datastore.
> > What's your suggestion for the reference if we want to work for both
> > event stream and datastore?
> 
> In most cases simply reference subscribed-notifications.  Push comes for
> free, since push uses subscribed-notifications.

[ztr]: OK, I will update the document.

> > > It would also be useful to align terminology with the other documents.
> > > It
> > > seems a "Master" is really the management protocol server?  And
> > > "Agent" is what subscribed-notifications calls a "publisher"?  Or
> > > maybe the "Master"
> > > is the "publisher"?
> > >
> > > You also use the term "data originator", but I am not quite sure if
> > > that is the same as "Agent"?
> >
> > [ztr]:
> > Yes, that's a good suggestion. Figure 1 is too simple and not clear.
> > We will try to do this in the next version. We have a more detailed
> > framework description with figures in
> > draft-zhou-netconf-multi-stream-originators-02. It would be really
> > appreciated if you can review that document. And you may help use
> > normalize the terms.
> > The master will decompose the subscription and distributed the
> > requests to each agent. Both master and the agent contains a publisher
> > as shown in Figure 3 in
> > draft-zhou-netconf-multi-stream-originators-02. "data originator" in
> > this draft is more like master + agent.
> 
> Ok, will do.  In general, try to stick with existing terms, and don't invent
> new unless the existing ones really can't be used.

[ztr]: Thank you. I will update the document.

> /martin
> 
> 
> >
> > >
> > >
> > > /martin
> > >
> > >
> > > Tianran Zhou <[e-mail]> wrote:
> > > > Hi WG,
> > > >
> > > > We've got some comments on the UDP based Publication Channel for
> > > > Streaming Telemetry. And we are going to update it, specifically
> > > > on the security aspect.
> > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-channe
> > > > l/
> > > >
> > > > Could you please help to review?
> > > > Any comment is appreciated.
> > > >
> > > > Thanks,
> > > > Tianran
> > > >
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/netconf
> > > >
> >