Re: [netconf] New Version Notification for draft-zhou-netconf-multi-stream-originators-06.txt

Tianran Zhou <zhoutianran@huawei.com> Wed, 10 July 2019 09:19 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 C76F91200FD for <netconf@ietfa.amsl.com>; Wed, 10 Jul 2019 02:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 7_AuK6v6glWs for <netconf@ietfa.amsl.com>; Wed, 10 Jul 2019 02:19: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 80C3A1200A3 for <netconf@ietf.org>; Wed, 10 Jul 2019 02:19:56 -0700 (PDT)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1C107E11975F8008FFF3 for <netconf@ietf.org>; Wed, 10 Jul 2019 10:19:54 +0100 (IST)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 10 Jul 2019 10:19:53 +0100
Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.134]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Wed, 10 Jul 2019 17:19:45 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Kent Watsen <kent@watsen.net>
CC: Qin Wu <bill.wu@huawei.com>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] New Version Notification for draft-zhou-netconf-multi-stream-originators-06.txt
Thread-Index: AdU2CHMGwBfbWqqXaUyVrraPIkdGOgAFaxMwABlYt4AAHdF6IA==
Date: Wed, 10 Jul 2019 09:19:44 +0000
Message-ID: <BBA82579FD347748BEADC4C445EA0F21BEE7EA88@NKGEML515-MBS.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABAA49CDA59@nkgeml513-mbx.china.huawei.com> <BBA82579FD347748BEADC4C445EA0F21BEE7C407@NKGEML515-MBS.china.huawei.com> <0100016bd9b20da3-e9c9fc64-f9e3-4e19-8b01-88504803093d-000000@email.amazonses.com>
In-Reply-To: <0100016bd9b20da3-e9c9fc64-f9e3-4e19-8b01-88504803093d-000000@email.amazonses.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_BBA82579FD347748BEADC4C445EA0F21BEE7EA88NKGEML515MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/p9Ppk4S9Ck3nMGp5deLFWuxO6-s>
Subject: Re: [netconf] New Version Notification for draft-zhou-netconf-multi-stream-originators-06.txt
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, 10 Jul 2019 09:20:00 -0000

Hi Kent,
Thanks for your comments. Please see inline.

Tianran

From: Kent Watsen [mailto:kent@watsen.net]
Sent: Wednesday, July 10, 2019 10:24 AM
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: Qin Wu <bill.wu@huawei.com>om>; netconf@ietf.org
Subject: Re: [netconf] New Version Notification for draft-zhou-netconf-multi-stream-originators-06.txt

Hi Tianran,

1. In dynamic subscription case, how does Publisher agent behind Publisher
master know where a particular receiver is when pushing subscribed data to
the receiver in a separate channel?
I think Appendix A.1 gives one example to show how this works in RESTCONF case.
Firstly, the reply to the dynamic subscription will return the resource access URIs.
Then, the receiver can use the URIs to GET the data.
This is similar to draft-ietf-netconf-restconf-notif-15.

I was also unsure (the draft needs to be more clear with regards to expected behavior).  That said, I have a fews concerns:

[Tianran]: I am not sure if I am doing the right thing on the examples. Maybe you can give some more suggestions.
This draft intent to provide a transport independent solution. Actual transport design, say RESTCONF, NETCONF, HTTPS, may have several options and need some more considerations. I am not sure if we should consider them all in this draft. So the question is what kind of example is helpful? I did not see a similar example in the draft-ietf-netconf-subscribed-notifications.

The following questions are respect to one potential RESTCONF transport solution I am considering. I give only my considerations.
1) will the client (a.k.a. the receiver) establish a full RESTCONF protocol connection to each line-card?  What YANG-library response might the line-cards return?
[Tianran]: I do not think it’s necessary to establish a full RESTCONF connection to each line-card. May be the http connection with server push capability is OK.

2) are we sure the client connections will always be routable to the line cards?
[Tianran]: I assume the address is routable.

3) are there any security issues with line-cards having open ports?
[Tianran]: The master returns the URIs containing the line-card port to the receiver within an security channel.

Given the above, and the potential symmetry to the configured case, did you consider letting the server establish the connection to the client?  From an operator's perspective, perhaps both options need to be supported?
[Tianran]: Good question. It’s impossible to include all the transports in this draft. This example seek to be compatible with draft-ietf-netconf-restconf-notif.
On the other hand, maybe we can consider only to use the https client as in draft-mahesh-netconf-https-notif as the only tcp transport for all the scenario.

2. How multi-stream originator works for configured subscription case?
In appendix A.2, I use the similar example as in draft-mahesh-netconf-https-notif-00 to illustrate.
In brief, the originators run on client mode, and connect to the receiver actively.

This example appears to be an exact copy/paste from draft-mahesh-netconf-https-notif, at least.  I didn't notice any differences and, that being the case, am unsure (again) what the expected behavior was intended to be.  Could you add a sequence diagram illustrating internal interactions?

[Tianran]Again, I want to be compatible with existing transport proposals as in draft-mahesh-netconf-https-notif.  So I suggested to include a list of channels in the receiver configuration. On one hand, it can support the multiple message originators scenario. On the other hand, one channel configuration can be compatible with the one message originator scenario.

Only this modification :)
       <receiver>
         <name>foo</name>
         <channel>
           <tcp-params>


I can add a sequence diagram to show how it works for this transport/example.

Kent // contributor