Re: [netconf] configuring multi-channels
Martin Bjorklund <mbj@tail-f.com> Tue, 17 September 2019 06:36 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 88CA7120098 for <netconf@ietfa.amsl.com>; Mon, 16 Sep 2019 23:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 gHloe_snP4Se for <netconf@ietfa.amsl.com>; Mon, 16 Sep 2019 23:36:00 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7909C12008C for <netconf@ietf.org>; Mon, 16 Sep 2019 23:36:00 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id D09171AE0115; Tue, 17 Sep 2019 08:35:57 +0200 (CEST)
Date: Tue, 17 Sep 2019 08:35:33 +0200
Message-Id: <20190917.083533.892234744068366075.mbj@tail-f.com>
To: zhoutianran@huawei.com
Cc: kent+ietf@watsen.net, netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <BBA82579FD347748BEADC4C445EA0F21BEFB6EDA@NKGEML515-MBX.china.huawei.com>
References: <BBA82579FD347748BEADC4C445EA0F21BEFB6EDA@NKGEML515-MBX.china.huawei.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / 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/bUbWV9XKx6RIDouzFykL2P_m2S0>
Subject: Re: [netconf] configuring multi-channels
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG 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, 17 Sep 2019 06:36:03 -0000
Tianran Zhou <zhoutianran@huawei.com> wrote: > Hi Martin, > > The channel is concept is from > https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stream-originators/ > There are multiple publication channels per device/subscription. In that document, the word "channel" is present three times + one (broken) XML example. The concept of a channel needs to be explained in detail so that we can have a meaningful discussion. /martin > It should be better if the client is not aware of the > channels. These can be achieved by using the UDP based publication > channel as in: > https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-channel/ > The publishers can use the same IP as the subscription channel, and > use dynamic ports. So no per channel configurations need. > > For https-notif, we can consider to pre-configure all the > possible/potential publication channels. > But the usage of which > channels is decided by the device dynamically during the run time. > > Regards, > Tianran > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Tuesday, September 17, 2019 3:27 AM > > To: kent+ietf@watsen.net > > Cc: Tianran Zhou <zhoutianran@huawei.com>; netconf@ietf.org > > Subject: Re: [netconf] Adoption Call for > > draft-mahesh-netconf-https-notif-00 > > > > Kent Watsen <kent+ietf@watsen.net> wrote: > > > > > > Hi Tianran, > > > > > > > > > > Considering the multiple stream originator case, I would suggest this > > https-notif to add a channel level configuration. > > > > i.e. > > > > > > > > +--receivers > > > > +--receiver > > > > +--channels > > > > +--channel > > > > +--here put the http client server configurations > > > > > > > > This is compatible with the single originator case with only one channel > > configuration. > > > > > > We can look at this. Maybe use a choice statement between the two options... > > > > I don't think this is a good idea. But then I don't really understand the > > 'channel' concept. I don't understand why the client needs to be aware of > > these channels, but this should probably be discussed in a separate thread. > > > > > > /martin > > > > > > > > > > Kent // co-author > > > > > > > > > > > > > > If you do not like this, I think existing https-notif model also works. > > > > i.e. each receiver configuration stands for one channel. > > > > But this is not clear IMO. > > > > > > > > Best, > > > > Tianran >
- [netconf] configuring multi-channels Tianran Zhou
- Re: [netconf] configuring multi-channels Martin Bjorklund
- Re: [netconf] configuring multi-channels Tianran Zhou
- Re: [netconf] configuring multi-channels Martin Bjorklund
- Re: [netconf] configuring multi-channels Tianran Zhou
- Re: [netconf] configuring multi-channels Martin Bjorklund
- Re: [netconf] configuring multi-channels Tianran Zhou
- Re: [netconf] configuring multi-channels Martin Bjorklund
- Re: [netconf] configuring multi-channels Tianran Zhou
- Re: [netconf] configuring multi-channels Martin Bjorklund
- Re: [netconf] configuring multi-channels Tianran Zhou
- Re: [netconf] configuring multi-channels Martin Bjorklund
- Re: [netconf] configuring multi-channels Kent Watsen
- Re: [netconf] configuring multi-channels Martin Bjorklund
- Re: [netconf] configuring multi-channels Andy Bierman
- Re: [netconf] configuring multi-channels Tianran Zhou