Re: [netconf] configuring multi-channels
Tianran Zhou <zhoutianran@huawei.com> Wed, 18 September 2019 01:47 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 CC74D120131 for <netconf@ietfa.amsl.com>; Tue, 17 Sep 2019 18:47:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Level:
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 kbcb6jTwi9wV for <netconf@ietfa.amsl.com>; Tue, 17 Sep 2019 18:47:57 -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 8900012011E for <netconf@ietf.org>; Tue, 17 Sep 2019 18:47:57 -0700 (PDT)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 979673534C4BFB4EF309 for <netconf@ietf.org>; Wed, 18 Sep 2019 02:47:55 +0100 (IST)
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 18 Sep 2019 02:47:54 +0100
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 18 Sep 2019 02:47:54 +0100
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Wed, 18 Sep 2019 02:47:54 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Wed, 18 Sep 2019 09:47:47 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>
CC: Netconf <netconf@ietf.org>
Thread-Topic: [netconf] configuring multi-channels
Thread-Index: AdVs9BeNNLIBQRFAQtOat+1DuA9kN///1euA//92JkCAAJSVAP//crMggACh+gD//3goMAASRjAA//94jtD//2m1AP/+TBRw//0bfwD/+euegP/z1ZuA/+eiQQD/zhQBEA==
Date: Wed, 18 Sep 2019 01:47:46 +0000
Message-ID: <BBA82579FD347748BEADC4C445EA0F21BEFB8820@NKGEML515-MBX.china.huawei.com>
References: <BBA82579FD347748BEADC4C445EA0F21BEFB7138@NKGEML515-MBX.china.huawei.com> <20190917.121226.1164447711500530993.mbj@tail-f.com> <0100016d3fac842c-22414d8e-ad04-4e56-b2c9-8f25a246affa-000000@email.amazonses.com> <20190917.164803.146080986857670528.mbj@tail-f.com> <CABCOCHQb9AZHnLsEyhB=BBqYf=_25ikv260+JLLGzPTCX-S=Jw@mail.gmail.com>
In-Reply-To: <CABCOCHQb9AZHnLsEyhB=BBqYf=_25ikv260+JLLGzPTCX-S=Jw@mail.gmail.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: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21BEFB8820NKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/NMPj5VCtSfikpBVk6RbGPBJKpSc>
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: Wed, 18 Sep 2019 01:48:00 -0000
Hi Andy and Martin, The proposal in draft-zhou-netconf-multi-stream-originators is to add the read only message-generator-id. So that the receiver can verify the full set of YANG objects promised are being provided across the sum of stream originators. module: ietf-multiple-stream-originators augment /sn:subscriptions/sn:subscription: +--ro message-generator-id* string augment /sn:subscription-started: +--ro message-generator-id* string augment /sn:subscription-modified: +--ro message-generator-id* string augment /sn:establish-subscription/sn:output: +--ro message-generator-id* string augment /sn:modify-subscription/sn:output: +--ro message-generator-id* string So we are not going to configure a channel-id or message-generator-id. I am just thinking how to configure the transport when there are multi originators. If draft-zhou-netconf-multi-stream-originators need to provide some guidelines or it’s deferred to the transport documents like https-notif. Best, Tianran From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, September 17, 2019 11:20 PM To: Martin Bjorklund <mbj@tail-f.com> Cc: Netconf <netconf@ietf.org> Subject: Re: [netconf] configuring multi-channels Hi, On Tue, Sep 17, 2019 at 7:48 AM Martin Bjorklund <mbj@tail-f.com<mailto:mbj@tail-f.com>> wrote: Kent Watsen <kent+ietf@watsen.net<mailto:kent%2Bietf@watsen.net>> wrote: > > Martin, > > As for why there is a need to configure anything on a per-channel > basis, here are some possible reasons: > > - different TCP-level parameters (source IP, possibly a VRF) Perhaps. But setting this per linecard would require the client to know all the line cards and which IP each line card can use. > - different TLS-level parameters (TA cert, client cert) Do you see a use for this? > - different HTTP-level parameters (basic auth) Do you see a use for this? > Does any of this matter? Is the only issue if the receiver can know > which line card sent the message? Or is it needed to enable the > networking connection to be established, which can somehow be > different amongst the line cards? > > If we purposely shun variations, then the need to configure anything > per-channel goes away, which would make things much easier all around. > But then we'd have to ask, what remains in the > multi-stream-originators draft? I don't know, but if we can solve the problem w/o an additional specification, that seems like a good thing! +1 to all of Martin's concerns. The notification already has a subscription-id, maybe a message-generator-id. Is the proposal to add an arbitrary channel-id to the notification header? It seems simpler and possibly useful to the client to retrieve the read-only message-generator-id that is being used for connection (from this new module). This should not be configurable by the client and a new arbitrary number should not be invented for it. /martin Andy _______________________________________________ netconf mailing list netconf@ietf.org<mailto:netconf@ietf.org> https://www.ietf.org/mailman/listinfo/netconf
- [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