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

[Martin Bjorklund <[e-mail]>]

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.


> 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).

> > 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.

> > 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.


/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-channel/
> > >
> > > Could you please help to review?
> > > Any comment is appreciated.
> > >
> > > Thanks,
> > > Tianran
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netconf
> > >
>