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

Tianran Zhou <zhoutianran@huawei.com> Mon, 15 July 2019 03:26 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 E9770120041 for <netconf@ietfa.amsl.com>; Sun, 14 Jul 2019 20:26:13 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 JlJ2gJ1Ayu0N for <netconf@ietfa.amsl.com>; Sun, 14 Jul 2019 20:26:11 -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 9994E12001B for <netconf@ietf.org>; Sun, 14 Jul 2019 20:26:10 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 08839C1437C842347076 for <netconf@ietf.org>; Mon, 15 Jul 2019 04:26:08 +0100 (IST)
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 15 Jul 2019 04:26:07 +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; Mon, 15 Jul 2019 04:26:07 +0100
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) 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; Mon, 15 Jul 2019 04:26:06 +0100
Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.238]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0439.000; Mon, 15 Jul 2019 11:25:56 +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: AdU2CHMGwBfbWqqXaUyVrraPIkdGOgAFaxMwABlYt4AAHdF6IADOoxAAAB/zdmA=
Date: Mon, 15 Jul 2019 03:25:55 +0000
Message-ID: <BBA82579FD347748BEADC4C445EA0F21BEE9CA83@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> <BBA82579FD347748BEADC4C445EA0F21BEE7EA88@NKGEML515-MBS.china.huawei.com> <0100016bf1e894c8-d55d14db-f7ba-4c4a-9ae8-f37aa8ff81a5-000000@email.amazonses.com>
In-Reply-To: <0100016bf1e894c8-d55d14db-f7ba-4c4a-9ae8-f37aa8ff81a5-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_BBA82579FD347748BEADC4C445EA0F21BEE9CA83NKGEML515MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/472sILrDJcxue587ftwKwvYKsgE>
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: Mon, 15 Jul 2019 03:26:14 -0000

Hi Kent,

Thank you very much for your suggestions. I will update the draft and discuss them during the meeting.
However, I am still not clear about the following discussions.

=== Re: dynamic subscription case ===

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.

Hmmm, my guess is that pretty much all transports supporting configured subscriptions will have the server (i.e., line cards) proactively initiate the connections to the notifications-receivers (and not have the receivers connecting to the servers).   This is more a macro-observation than a draft-mahesh-netconf-https-notif specific thing, though that draft follows this pattern too.

[Tianran2]: I am sorry I not quite clear. Here we are talking about the dynamic subscription. I conclude there are four potential modes.
1. The linecard runs on server mode. The connections are dynamically set up, when the receiver know the subscription decomposition result at run time.
2. The linecard runs on server mode. All the potential connections are set up. The receiver only get data dynamically.
3. The linecard runs on client mode. The connections are dynamically set up, when the linecard know the subscription decomposition result at run time.
4. The linecard runs on client mode. All the potential connections are set up. The linecards send data dynamically.


=== Re: configured subscription case ===

Ah, a "channel" container was added, I didn't see that before.  The draft should've defined YANG module to add a "channel" container.  That said, I don't think what you're hoping to achieve here is legal/valid YANG (please ensure that all examples are validated using e.g., `yanglint`).

[Tianran2]: I did not define a YANG module for this, because this may make the this draft depend on draft-mahesh-netconf-https-notif. But I sent the comment to the mailing list to suggest draft-mahesh-netconf-https-notif to apply this modification.
https://mailarchive.ietf.org/arch/msg/netconf/YmIh2l1xGJUq5gYwvrzcwnRphPg

Or do you think this draft can define a configuration framework, not include the details? So that transport like draft-mahesh-netconf-https-notif can augment.


Thanks,
Tianran



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

=== Re: dynamic subscription case ===


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.

Do not take draft-ietf-netconf-subscribed-notifications as an example to follow when it comes to examples.  The lack of examples in that draft continues to cause confusion.  As RFC 8407 says: "Each specification that defines one or more modules SHOULD contain usage examples, either throughout the document or in an appendix.".

It is understood that, in addition to variations in encoding (e.g., XML, JSON), this document (and SN) have variations in transports (RC, HTTP, etc.).  This additional dimension is easily addressed, just preface your examples with something like "For instance, assuming the use of the transport defined by [draft-foo-bar] and using the XML (or JSON) encoding, the following example illustrates yada yada..."


 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.

Fine, but my point is that your draft needs to explicitly say it and, more importantly, state exactly what is or is not allowed over such less than full connections.



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

Again, the draft needs to state this.



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.

True, but the line-card has an open port that could be detected via a port sweep and thereafter attacked (DoS?).  The Security Considerations section needs to mention this.



 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.

Hmmm, my guess is that pretty much all transports supporting configured subscriptions will have the server (i.e., line cards) proactively initiate the connections to the notifications-receivers (and not have the receivers connecting to the servers).   This is more a macro-observation than a draft-mahesh-netconf-https-notif specific thing, though that draft follows this pattern too.





=== Re: configured subscription case ===


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.

Ah, a "channel" container was added, I didn't see that before.  The draft should've defined YANG module to add a "channel" container.  That said, I don't think what you're hoping to achieve here is legal/valid YANG (please ensure that all examples are validated using e.g., `yanglint`).




Kent // contributor