IETF Logo Mail Archive

[netconf] configuring multi-channels

Tianran Zhou <zhoutianran@huawei.com> Tue, 17 September 2019 01:41 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 C7A5E120026 for <netconf@ietfa.amsl.com>; Mon, 16 Sep 2019 18:41:27 -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 pVpSqap0x3Jr for <netconf@ietfa.amsl.com>; Mon, 16 Sep 2019 18:41:26 -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 18A6D1200D7 for <netconf@ietf.org>; Mon, 16 Sep 2019 18:41:26 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 68D4B57A59ADEEA8BE95 for <netconf@ietf.org>; Tue, 17 Sep 2019 02:41:24 +0100 (IST)
Received: from lhreml715-chm.china.huawei.com (10.201.108.66) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 17 Sep 2019 02:41:23 +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 02:41:24 +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 02:41:23 +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 09:41:16 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Martin Bjorklund <mbj@tail-f.com>, "kent+ietf@watsen.net" <kent+ietf@watsen.net>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: configuring multi-channels
Thread-Index: AdVs9BeNNLIBQRFAQtOat+1DuA9kNw==
Date: Tue, 17 Sep 2019 01:41:16 +0000
Message-ID: <BBA82579FD347748BEADC4C445EA0F21BEFB6EDA@NKGEML515-MBX.china.huawei.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/SngEEZNNhEGIvA2S-b2_s4-PDHc>
Subject: [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 01:41:28 -0000

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.

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

v2.23.0 | Report a Bug | By Email