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

Martin Bjorklund <mbj@tail-f.com> Tue, 12 June 2018 10:02 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D973130E20 for <netconf@ietfa.amsl.com>; Tue, 12 Jun 2018 03:02:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhjO70-mu_4F for <netconf@ietfa.amsl.com>; Tue, 12 Jun 2018 03:02:47 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCCE130E1A for <netconf@ietf.org>; Tue, 12 Jun 2018 03:02:47 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 297851AE048E; Tue, 12 Jun 2018 12:02:46 +0200 (CEST)
Date: Tue, 12 Jun 2018 12:02:45 +0200 (CEST)
Message-Id: <20180612.120245.2096464206469364241.mbj@tail-f.com>
To: zhoutianran@huawei.com
Cc: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <BBA82579FD347748BEADC4C445EA0F21B55CBFEF@NKGEML515-MBX.china.huawei.com>
References: <BBA82579FD347748BEADC4C445EA0F21B55CAC2B@NKGEML515-MBX.china.huawei.com> <20180611.094824.234543590325320109.mbj@tail-f.com> <BBA82579FD347748BEADC4C445EA0F21B55CBFEF@NKGEML515-MBX.china.huawei.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/lxxsxq6Ss-4u4JzggADQKxLD4sI>
Subject: Re: [Netconf] request for comments on draft-ietf-netconf-udp-pub-channel
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jun 2018 10:02:51 -0000

Hi,

Tianran Zhou <zhoutianran@huawei.com> 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:mbj@tail-f.com]
> > Sent: Monday, June 11, 2018 3:48 PM
> > To: Tianran Zhou <zhoutianran@huawei.com>
> > Cc: netconf@ietf.org
> > 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 <zhoutianran@huawei.com> 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
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf
> > >
>