Re: [netconf] configuring multi-channels

Martin Bjorklund <mbj@tail-f.com> Tue, 17 September 2019 09:05 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 3FC96120104 for <netconf@ietfa.amsl.com>; Tue, 17 Sep 2019 02:05:30 -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 yYqvg35LBZyj for <netconf@ietfa.amsl.com>; Tue, 17 Sep 2019 02:05:27 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 72B9E1200FF for <netconf@ietf.org>; Tue, 17 Sep 2019 02:05:27 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 3DDE31AE08F5; Tue, 17 Sep 2019 11:05:25 +0200 (CEST)
Date: Tue, 17 Sep 2019 11:05:00 +0200
Message-Id: <20190917.110500.1456377062440780828.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: <BBA82579FD347748BEADC4C445EA0F21BEFB70CA@NKGEML515-MBX.china.huawei.com>
References: <BBA82579FD347748BEADC4C445EA0F21BEFB709F@NKGEML515-MBX.china.huawei.com> <20190917.102758.2020337184594988909.mbj@tail-f.com> <BBA82579FD347748BEADC4C445EA0F21BEFB70CA@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/4lh-W-N_aOGtnnyTQUI5hlYLZUU>
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 09:05:30 -0000

Tianran Zhou <zhoutianran@huawei.com> wrote:
> 
> 
> > -----Original Message-----
> > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > Sent: Tuesday, September 17, 2019 4:28 PM
> > To: Tianran Zhou <zhoutianran@huawei.com>
> > Cc: kent+ietf@watsen.net; netconf@ietf.org
> > Subject: Re: configuring multi-channels
> > 
> > Tianran Zhou <zhoutianran@huawei.com> wrote:
> > > > -----Original Message-----
> > > > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > > > Sent: Tuesday, September 17, 2019 3:14 PM
> > > > To: Tianran Zhou <zhoutianran@huawei.com>
> > > > Cc: kent+ietf@watsen.net; netconf@ietf.org
> > > > Subject: Re: configuring multi-channels
> > > >
> > > > Tianran Zhou <zhoutianran@huawei.com> wrote:
> > > > > In this document, we defined two types of publication channels:
> > > > >    Master Publication Channel: the session between the Master Publisher
> > > > >    and the Receiver.
> > > > >    Agent Publication Channel: the session between the Agent Publisher
> > > > >    and the Receiver
> > > > >
> > > > > Do you think it's enough or anything you think should be clarified?
> > > >
> > > > These are just names.  But why does these names imply that the
> > > > client has to configure anything?
> > >
> > > Several kinds of transport protocol can be used to carry data between
> > > the publisher and the receiver. UDP based, TCP based.
> > > Transport like https-notif need client-server configuration.
> > > That is to say the configuration is about the transport like in
> > > draft-mahesh-netconf-https-notif-00.
> > 
> > With the POST-based HTTP protocol in draft-mahesh-netconf-https-notif,
> > why
> > can't the agent publisher simply POST to the receiver?  It is probably
> > useful
> > if the *server* can indicate to the client that this will/may happen,
> > but
> > I don't understand why the client needs to configure anything special.
> 
> I agree with you. My understanding to draft-mahesh-netconf-https-notif
> is that the configuration is on the *server* side.
> The configuration need to indicate both client and server
> information. For example:
>    module: ietf-https-notif
>      +--rw receivers
>         +--rw receiver* [name]
>            +--rw name           string
>            +--rw tcp-params
>            |  +--rw remote-address    inet:host
>            |  +--rw remote-port?      inet:port-number
>            |  +--rw local-address?    inet:ip-address
>            |  +--rw local-port?       inet:port-number
>            |  +--rw keepalives!
> 
> Include both remote and local IP.

The local-address and -port are conditional on an if-feature, but I
agree that this is problematic in the case that an publisher agent on
a line card wants to push directly to the receiver.


/martin


> 
> I am sorry, could you point out if there is any that mislead you. :-) 
> 
> Best,
> Tianran
> 
> 
> > /martin
> > 
> > 
> > >
> > > Tianran
> > >
> > > > /martin
> > > >
> > > >
> > > >
> > > > >
> > > > > Thanks,
> > > > > Tianran
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com]
> > > > > > Sent: Tuesday, September 17, 2019 2:36 PM
> > > > > > To: Tianran Zhou <zhoutianran@huawei.com>
> > > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org
> > > > > > Subject: Re: configuring multi-channels
> > > > > >
> > > > > > Tianran Zhou <zhoutianran@huawei.com> wrote:
> > > > > > > Hi Martin,
> > > > > > >
> > > > > > > The channel is concept is from
> > > > > > > https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stre
> > > > > > > am-o rigi nators/ 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-ch
> > > > > > > anne l/ 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
> > > > > > >
> > > > >
> > >
>