Re: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)
Susan Hares <shares@ndzh.com> Wed, 08 July 2020 15:13 UTC
Return-Path: <shares@ndzh.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 65CCB3A0DC5; Wed, 8 Jul 2020 08:13:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.948
X-Spam-Level:
X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=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 4RmJ2JG4irp8; Wed, 8 Jul 2020 08:13:47 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28FC3A0DB7; Wed, 8 Jul 2020 08:13:45 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.107.91.217;
From: Susan Hares <shares@ndzh.com>
To: 'Benjamin Kaduk' <kaduk@mit.edu>, 'The IESG' <iesg@ietf.org>
Cc: draft-ietf-i2rs-yang-l2-network-topology@ietf.org, i2rs@ietf.org, i2rs-chairs@ietf.org
References: <159408571443.14853.16206496770792413851@ietfa.amsl.com>
In-Reply-To: <159408571443.14853.16206496770792413851@ietfa.amsl.com>
Date: Wed, 08 Jul 2020 11:13:31 -0400
Message-ID: <005601d6553a$5acc2240$106466c0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJJg5MXryKlX+H7Xo36TfBDw73i96gXViqA
Content-Language: en-us
X-Antivirus: AVG (VPS 200708-4, 07/08/2020), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/6yig4_ZOfF_kVu2_4n_qlunTqEA>
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: Wed, 08 Jul 2020 15:13:49 -0000
Benjamin: I'm sorry I missed this email until today. I do not think Qin has answered your questions. Issues we believe are settled ========================== 1) VXLAN - value of zero. We believe Yang Doctors have indicated our method is correct. Rob Wilton is the best judge among IESG for this issue. 2) Network topology models and links - please see RFC 8345 Issues which need investigation with IEEE/IETF liaison and industry use =================================================== 1) System management IP address - We believe that a single system management is the correct basic functionality. Additional system management ports would be an augmentation of a model by a vendor. If this does not match the current hardware technology, the authors can change to indicate a list of multiple system management ports. Advice is needed from switch vendors on the basic. I have sent a request to the yang doctors. Rob Wilton can provide feedback for the IESG if I do not get Yang Doctors response quickly. 2) What "others" states might be added in the future? 802.1 has been adding some other states to ports for ACTIVE-ACTIVE fail-over and for highly deterministic L2 paths for video (~IETF detnet). I need to check when these "other states" have been defined by IEEE 802.1, and when these new "other" states might be deployed in new switch devices. If the new states are in devices, we will need to add them to this model following the 802.1 definitions. As a shepherd, I had not check upon these in the last 2 years. I have concern about putting these states in a model unless we have implementations that will use these states. The normal way to add these states is with an augmentation for the model. Good catch - I should have re-examined the IEEE work and current technology in the last few weeks. 3) Normative and informative choices - Authors will abide by IESG and IEEE recommendations The authors will abide by IESG and IEEE recommendations for the status of RFCs. The following should be discussed by IESG and the IEEE a) Normative --> informative RFC3688 and RFC7951 b) Informative--> normative: [IEEE802.1Qcp], RFC7348 Issues which need editorial changes: (Qin SHOULD change/add] ================ 1) QinQ definitions The svlan-id and cvlan-id can should augment the structures with longer descriptions. These descriptions should point to the IEEE longer descriptions. This change will need to be validated by yang doctors and IETF-IEEE liaison person. 2) change of text in security sections [(a) "intended" to "intended" datastore and b) NETCONF access control model to NACM)] Thanks for catching the nits in the security text. Thank you for your careful and thoughtful review, Susan Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Benjamin Kaduk via Datatracker Sent: Monday, July 6, 2020 9:35 PM To: The IESG Cc: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; i2rs@ietf.org; i2rs-chairs@ietf.org Subject: [i2rs] 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? 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? [Sue: The links were part of the core network topology >From RFC 8345: module: ietf-network-topology augment /nw:networks/nw:network: +--rw link* [link-id] +--rw link-id link-id +--rw source | +--rw source-node? -> ../../../nw:node/node-id | +--rw source-tp? leafref +--rw destination | +--rw dest-node? -> ../../../nw:node/node-id | +--rw dest-tp? leafref +--rw supporting-link* [network-ref link-ref] +--rw network-ref | -> ../../../nw:supporting-network/network-ref +--rw link-ref leafref End of Sue-2] 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. 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.) [Sue2: You are correct this raised controversy. The value of "0" for VXLAN Segment ID = 0 is valid for some implementations, And invalid for other implementations. Our best understanding from Yang doctors and implementations Is that this is the correct way to denote this to yang modules. Implementations will need to handle a value of zero per box.] /* * Features */ nit: there seems to be a spurious blank line here. [Sue 2: Thank you for noting the spurious line. Qin - will catch that in the next revision. 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? [Sue: In my work (around 2008-2010) with developing level 2 system support there was usually one system MAC for input/output of Management issues. If there is more than one, it is usually an augment for A secondary network management processor. Most devices (and Chip sets) indicate this is a different processor. Qin may be able to check with hardware people to determine If it is common to have more than one system MAC. Do you have specific knowledge that changes this fact? If so, please propose it. End of sue:] 0 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 :) [Sue: Yes - it is usually for local earth links. Deep space links would be an augmentation to the model. (smile.) end Sue] 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? [Sue: According to the base model [RFC8345 the supporting termination point is considered a logical port. Whether the physical configuration is a physical port, depends on the mapping for the model. ] 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"? [Sue: We have tried to stay aligned with the 802.1Q Qin Q specifications. We'll add service and customer VLAN ID information, but aligns with the IEEE use. The brevity was to point to the 802.1 QinQ defintions. Thank you for catching the fact the brief information was too brief.] } //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.) [Sue: If you use the recommended style of RFC6020, the tools chain does not handle it well. The RFC processors for xml and nits blow up. The style you have below seems to make the RFC processors and yang tools have less problems. We'll be glad to implement RFC6020 if the Tools and RFC processing would not blow up. Sigh - long standing fight with bugs in tool change. Benoit Claise was correct to place a great deal of emphasis on the tool chain for yang. End-Sue comment] 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? [Ben: Other states are being developed in 802.1 for fast fail-over of ports and deterministic failure over (~IETF detnet group. Good catch. I had only check on the level of deployment 24 months ago. ] 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. [Sue: Good point. I think it should be added.] reflected in the operational state datastore, leading to disruption of services provided via this topology might be disrupted. For those nit: deduplicate "disruption"/"disrupted". [Sue: Godo point. Final text: New/ In the case of a topology that is configured, i.e. whose origin is the "intended" datastore, the undesired configuration could become effective and be reflected in the operational datastore, leading to a disruption of services provided via this topology./ ] 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? [Sue: optional to authors. I'm fine with condensation. ] 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? [Sue: Each Node has many MAC addresses. I assume that you are implying the management port MAC address. I need a bit more clarity on your question to try to address this point. ] 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. [Sue: The VLAN/VXLAN identifiers are considered part of the same sensitive information. However, in my mind the text above covers both ports and VLAN/VXLAN identifiers. If you have additional text, please suggest it. ] Section 8.1 RFC 3688 could arguably be demoted to informative, as could RFC 7951. [Sue: We had followed current Yang specifications. Demoting either RFC3688 and RFC7951 can be done if the Yang Doctors, NM/OPS ADs, and IESG agree. Authors and WG only tried to follow Best common practices.] Section 8.2 If we use types defined in [IEEE802.1Qcp], that seems like a normative reference to me. [Sue: By importing the IEEE 802.1Qcp model, it seemed like a normative reference. However, my best understanding of the IEEE review was that it was not normative. Again, all the authors need is a clear reading of the correct status from IEEE liaison. ] Noting the discussion at https://www.ietf.org/about/groups/iesg/statements/normative-informative-refe rences/ 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/ [Sue: I've added this RFC7348 as one of the things that must be resolved with IESG + IEEE-IETF liaison] I could go either way (informative or normative) for RFC 8342; presumably there's a convention to stick to. [Sue: RFC8342 is considered informative as it sets the design but does not specify a model that must be followed. We'll leave it informative for this point since I think this is the convention. If not, hopefully Rob Wilton will provide a comment about it. ] 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. [Note that I did not do an extensive consistency/sanity check on the example topology or try to reconstruct it from the JSON.] [Sue: I'm confused on the Appendix B. All I see in MAC Addresses and logical identifiers. Could you let me know what I missed? ] _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
- [i2rs] Benjamin Kaduk's No Objection on draft-iet… Benjamin Kaduk via Datatracker
- Re: [i2rs] Benjamin Kaduk's No Objection on draft… Martin Vigoureux
- Re: [i2rs] Benjamin Kaduk's No Objection on draft… Qin Wu
- Re: [i2rs] Benjamin Kaduk's No Objection on draft… Susan Hares
- Re: [i2rs] Benjamin Kaduk's No Objection on draft… Susan Hares
- Re: [i2rs] Benjamin Kaduk's No Objection on draft… Qin Wu
- Re: [i2rs] Benjamin Kaduk's No Objection on draft… Benjamin Kaduk
- Re: [i2rs] Benjamin Kaduk's No Objection on draft… Benjamin Kaduk
- Re: [i2rs] Benjamin Kaduk's No Objection on draft… Qin Wu
- Re: [i2rs] Benjamin Kaduk's No Objection on draft… Qin Wu
- Re: [i2rs] Benjamin Kaduk's No Objection on draft… Benjamin Kaduk