Re: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

Qin Wu <bill.wu@huawei.com> Tue, 07 July 2020 13:40 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFE93A0CBB; Tue, 7 Jul 2020 06:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, 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 gzMIudkLWLUO; Tue, 7 Jul 2020 06:40:51 -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 3B6AA3A0CBA; Tue, 7 Jul 2020 06:40:51 -0700 (PDT)
Received: from lhreml729-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E62B55FDA172C3EF51D4; Tue, 7 Jul 2020 14:40:46 +0100 (IST)
Received: from lhreml729-chm.china.huawei.com (10.201.108.80) by lhreml729-chm.china.huawei.com (10.201.108.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 7 Jul 2020 14:40:46 +0100
Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml729-chm.china.huawei.com (10.201.108.80) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Tue, 7 Jul 2020 14:40:46 +0100
Received: from DGGEML531-MBS.china.huawei.com ([169.254.5.228]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Tue, 7 Jul 2020 21:40:23 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-i2rs-yang-l2-network-topology@ietf.org" <draft-ietf-i2rs-yang-l2-network-topology@ietf.org>, "i2rs-chairs@ietf.org" <i2rs-chairs@ietf.org>, "i2rs@ietf.org" <i2rs@ietf.org>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)
Thread-Index: AdZUWZQ7RY/SR7IYR92kj2hyQyvtDg==
Date: Tue, 07 Jul 2020 13:40:23 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAAD813084@dggeml531-mbs.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.164.150.253]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/X_MW2UEp-wdNhZybaK9tnL5eqkA>
Subject: Re: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2020 13:40:53 -0000

Hi, Ben:
-----邮件原件-----
发件人: Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org] 
发送时间: 2020年7月7日 9:35
收件人: The IESG <iesg@ietf.org>
抄送: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; i2rs-chairs@ietf.org; i2rs@ietf.org
主题: Benjamin Kaduk's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-i2rs-yang-l2-network-topology-14: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Why is the "management-address" for a l2-node an IP address?  Does that exclude any potential use of this data model for non-IP networks?
[Qin]: No, it doesn't. management address is used to setup management channel and provide management interface for the administrator.
Section 3

   o  Links in the "ietf-network-topology" module are augmented as well
      with a set of Layer 2 parameters, allowing to associate a link
      with a name, a set of Layer 2 link attributes, and flags.

Interesting that names for links were not part of the core network-topology module.  Are there any potential issues if other ntework types also specify a link name and there is disagreement between them?
[Qin]: core network-topology module defined in RFC8345 doesn't specify name but specify link-id, link-id should be unique among different network types,
For name defined in L2 topo, we follow the same design style for L3 topo, i.e., specify name for each L2 link which is optional attribute.
Section 4

It reads a little oddly to use the flag-identity as the base type of a typedef before the identity itself is declared, but I am way out of my league here and defer to the YANG experts.
[Qin]: pyang tool doesn't complain about this. If needed, we can change the order.
       description
         "VXLAN Network Identifier or VXLAN Segment ID.
          It allows up to 16 M VXLAN segments to coexist
          within the same administrative domain.

          The use of value '0' is implementation-specific.";

Is this intended as a nod to the use of 0 for the management VLAN?/ (I seem to recall this topic raising to some level of controversy in the discussions around draft-ietf-bfd-vxlan.)
[Qin]: See Martin's reply, thanks Martin.
     /*

      * Features
      */

nit: there seems to be a spurious blank line here.

     grouping l2-node-attributes {
         [...]
         leaf sys-mac-address {
           type yang:mac-address;
           description
             "System MAC address.";
         }

Is there only one "System MAC address" per node?
[Qin]:Yes, your are correct.
         leaf delay {
           type uint32;
           units "microseconds";
           description
             "Link delay in microseconds.";

I guess we don't expect to use this model for deep-space links :)
[Qin] Correct.
       container l2-termination-point-attributes {
         description
           "Containing L2 termination point attributes.";
         leaf description {
           type string;
           description
             "Port description.";

Is a termination point always a "port", or should the description be modified?
[Qin]: I think port and l2 termination point is equivalent, we could change to layer 2 termination point description.
             list qinq {
               [...]
               leaf svlan-id {
                 type dot1q-types:vlanid;
                 description
                   "SVLAN ID.";
               }
               leaf cvlan-id {
                 type dot1q-types:vlanid;
                 description
                   "CVLAN ID.";

Could we perhaps expand "service" and "customer"?
[Qin]: Sure, will do as you suggested.
           }
           //case ethernet

RFC 6020 suggests that YANG comments are "C++-style", which would seem to indicate that the single-line comment could start on the same line as the closing brace.  This, in turn, would save some confusion since the block comments apply to the content after the comment, but these comments apply to the content before the comment.
(Also later on as well.)
[Qin]: Okay, will move single line comment to the end of closing brace.
         leaf tp-state {
           [...]
             enum others {
               value 4;
               description
                 "The termination point is in other state.";
             }

Is there a plan for how substructure of these "others" states might be added in the future?
[Qin]: Others means unknown termination point state.
Section 6

Thank you for updating the privacy considerations in response to the secdir review!

   In the case of a topology that is configured, i.e. whose origin is
   "intended", the undesired configuration could become effective and be

Perhaps toss the word "datastore" in here somewhere to remind the less-clueful reader (i.e., me) that origin is an NMDA concept?  Though if it's sufficiently obvious, no need to do it just for me.
[Qin] Correct, will add.
   reflected in the operational state datastore, leading to disruption
   of services provided via this topology might be disrupted.  For those

nit: deduplicate "disruption"/"disrupted".
[Qin]:Good catch.
   reasons, it is important that the NETCONF access control model is
   vigorously applied to prevent topology misconfiguration by
   unauthorized clients.

Should we condense "NACM" here since we provided the acronym at the start of the paragraph?
[Qin]: Okay.
   o  l2-node-attributes: A malicious client could attempt to sabotage
      the configuration of important node attributes, such as the name
      or the management-address.

I don't feel a need for a text change here (since "such as" suffices), but would a change to the node's MAC address be similarly impactful?
[Qin]: Yes, we could add if you think it needed.
   Some of the readable data nodes in this YANG module may be considered
   sensitive or vulnerable in some network environments.  It is thus
   important to control read access (e.g., via get, get-config, or
   notification) to these data nodes.  In particular, the YANG model for
   layer 2 topology may expose sensitive information, for example the
   MAC addresses of devices.  Unrestricted use of such information can

I think I've been told that in some environments the topology itself (especially VLAN/VXLAN identifiers) can be considered sensitive.  What's written here is consistent with that, and I don't insist on a change to the text, but wondered if that was seen as a common enough thing to be worth mentioning.
[Qin]: I think we could mention VLAN and VXLAN identifiers as sensitive information example.
Section 8.1

RFC 3688 could arguably be demoted to informative, as could RFC 7951.

Section 8.2

If we use types defined in [IEEE802.1Qcp], that seems like a normative reference to me.

Noting the discussion at
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
about even optional features still being normative references, I think RFC 7348 would be better placed as a normative reference.  Note that there is not a process/downref issue in doing so, since it is already listed at https://datatracker.ietf.org/doc/downref/

I could go either way (informative or normative) for RFC 8342; presumably there's a convention to stick to.
[Qin]: Thanks, will see how to fix these references, thanks.
Appendix B

I was going to reference
https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ and suggest IPv6 addresses as example management-addresses, but I have a lingering memory that the IPv4 form is still used to identify nodes even in v6-only environments.  Do the right thing, of course.
[Qin]: Okay, will add IPv6 support in the JSON example.
[Note that I did not do an extensive consistency/sanity check on the example topology or try to reconstruct it from the JSON.]