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
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 > > > >
- Re: [Netconf] request for comments on draft-ietf-… Martin Bjorklund
- Re: [Netconf] request for comments on draft-ietf-… Tianran Zhou
- Re: [Netconf] request for comments on draft-ietf-… Tianran Zhou
- [Netconf] request for comments on draft-ietf-netc… Tianran Zhou
- Re: [Netconf] request for comments on draft-ietf-… Aijun Wang
- Re: [Netconf] request for comments on draft-ietf-… Tianran Zhou
- Re: [Netconf] request for comments on draft-ietf-… Zhengguangying (Walker)
- Re: [Netconf] request for comments on draft-ietf-… Martin Bjorklund