Re: [netconf] configuring multi-channels
Tianran Zhou <zhoutianran@huawei.com> Tue, 17 September 2019 10:06 UTC
Return-Path: <zhoutianran@huawei.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 AEC6B12080E for <netconf@ietfa.amsl.com>; Tue, 17 Sep 2019 03:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 4p4RI5L8bIYx for <netconf@ietfa.amsl.com>; Tue, 17 Sep 2019 03:06:14 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C17F12080A for <netconf@ietf.org>; Tue, 17 Sep 2019 03:06:14 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 9A8093F79FE53602F33E for <netconf@ietf.org>; Tue, 17 Sep 2019 11:06:12 +0100 (IST)
Received: from lhreml715-chm.china.huawei.com (10.201.108.66) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 17 Sep 2019 11:06:12 +0100
Received: from lhreml715-chm.china.huawei.com (10.201.108.66) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 17 Sep 2019 11:06:12 +0100
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 17 Sep 2019 11:06:11 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0439.000; Tue, 17 Sep 2019 18:06:04 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "kent+ietf@watsen.net" <kent+ietf@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: configuring multi-channels
Thread-Index: AdVs9BeNNLIBQRFAQtOat+1DuA9kN///1euA//92JkCAAJSVAP//crMggACh+gD//3goMAASRjAA//94jtD//2m1AP/+TBRw
Date: Tue, 17 Sep 2019 10:06:03 +0000
Message-ID: <BBA82579FD347748BEADC4C445EA0F21BEFB7138@NKGEML515-MBX.china.huawei.com>
References: <BBA82579FD347748BEADC4C445EA0F21BEFB70CA@NKGEML515-MBX.china.huawei.com> <20190917.110500.1456377062440780828.mbj@tail-f.com> <BBA82579FD347748BEADC4C445EA0F21BEFB7101@NKGEML515-MBX.china.huawei.com> <20190917.115808.1894012459057925338.mbj@tail-f.com>
In-Reply-To: <20190917.115808.1894012459057925338.mbj@tail-f.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.156.116]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/3UnBtA4SglrQ_ow4TRmbf4GLe1s>
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 10:06:17 -0000
> -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, September 17, 2019 5:58 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 5:05 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 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. > > > > Right. Thanks for your clarification. > > So for TCP based transports, we have to preconfigure all the potential > > local-remote pairs, aka the channel information in my words:-), on the > > server. > > No I don't think that's the (correct) solution. Why is it important to > configure this at all? Then, could you give any hint on the correct solution in your mind? What configuration should be avoided in an idea solution? Thanks, Tianran > > /martin > > > > For each subscription, the device can decide which set of publishers to > serve. > > > > Thanks, > > Tianran > > > > > /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-mu > > > > > > > > > > lti- 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-ud > > > > > > > > > > p-pu b-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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
- [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