Re: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Tue, 14 July 2020 04:10 UTC
Return-Path: <kaduk@mit.edu>
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 91BDD3A0C98; Mon, 13 Jul 2020 21:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=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 3Y3NUN_a1GV8; Mon, 13 Jul 2020 21:10:11 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 1F55F3A0C97; Mon, 13 Jul 2020 21:10:09 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06E49r6G015149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Jul 2020 00:09:57 -0400
Date: Mon, 13 Jul 2020 21:09:53 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Qin Wu <bill.wu@huawei.com>
Cc: Susan Hares <shares@ndzh.com>, "draft-ietf-i2rs-yang-l2-network-topology@ietf.org" <draft-ietf-i2rs-yang-l2-network-topology@ietf.org>, "i2rs@ietf.org" <i2rs@ietf.org>, 'The IESG' <iesg@ietf.org>, "i2rs-chairs@ietf.org" <i2rs-chairs@ietf.org>
Message-ID: <20200714040953.GE16335@kduck.mit.edu>
References: <B8F9A780D330094D99AF023C5877DABAAD827B0D@dggeml511-mbs.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAAD827B0D@dggeml511-mbs.china.huawei.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/-mxbHBblCLFVPibBh499MJTtqZU>
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, 14 Jul 2020 04:10:14 -0000
Hi Qin, On Sun, Jul 12, 2020 at 07:56:59AM +0000, Qin Wu wrote: > Ben: > See the previous email I sent to you on termination point state extensibility. Thanks. I think we are ready for IEEE review in v-15. I see it, thanks -- it's definitely sufficient to address my comment (possibly more-than-sufficient). I don't know of anything else that needs to be done before IEEE review. -Ben > -Qin > -----邮件原件----- > 发件人: Benjamin Kaduk [mailto:kaduk@mit.edu] > 发送时间: 2020年7月10日 7:11 > 收件人: Susan Hares <shares@ndzh.com> > 抄送: 'The IESG' <iesg@ietf.org>; draft-ietf-i2rs-yang-l2-network-topology@ietf.org; i2rs@ietf.org; i2rs-chairs@ietf.org > 主题: Re: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) > > Hi Sue, Qin, > > Thanks for following up on these points, especially the "new" developments in the IEEE side. I think all my questions/comments have been addressed -- if there is a need to add more states for the termination point the model could be revised in the future to include them. > > Thanks, > > Ben > > On Wed, Jul 08, 2020 at 01:25:16PM -0400, Susan Hares wrote: > > Ben: > > > > Following up on my earlier mail regarding the investigation comments: > > > > 1) System management MAC port - > > > > The 802.1Q-2018 is the latest full specification > > > > https://1.ieee802.org/yang-modules/ > > http://ieee802.org/1/files/public/YANGs/ieee802-dot1q-bridge.yang - > > provides the yang modules > > > > in this module there is a container Bridge with the bridge configuration. > > In this container there is a MAC address, but I do not find a clear > > specification of system-mac or the management mac. I will ask the > > IEEE-IETF liaison group to provide me with the appropriate > > specification to validate the current and future handling of system macs. > > > > It may be an vendor specific augmentation to the IEEE model. If so, > > these additions would still be needed by the L2 topology model which > > is looking to have an interoperable L2 view of the network. > > > > 2) "other state" in the termination point > > > > The states of the termination port of "in use", "blocking", "down", > > and "others" concepts 802.1Q Yang models to a simplistic view of the port. > > > > The concepts of "other" as a mentioned below come from anticipation in > > 2016 of work for time sensitive network (TSN) task group. The TSN > > work could cause the port as a logical termination point to have > > something besides "in use", "block frames", and "down". Therefore, we added a state "other" to > > allow the model to indicate one of the other concepts. > > > > The TSN specifications that lead us to this conclusion are the following: > > P802F (yang module for Ether Types), 802.1Qcw (yang data models for > > schedule traffic, frame preemption, and per-stream > > filtering/policing), 802.1Qdj (configuration enhancements for TSN), > > 802.1ABcu (LLDP Yang Data model), and 802.1CBcv (Frame Replication and > > Elimination) model > > > > In the future after the Yang models of the IEEE for TSN are specified > > and approved, a revision of this I2RS model could specify a simplification of > > the TSN functioning into 1 or more specific states. > > > > > > Summary: > > Item 1 - management-address for process that is > > > > leaf-list management-address { > > type inet:ip-address; > > description > > "System management address."; > > } > > leaf sys-mac-address { > > type yang:mac-address; > > description > > "System MAC address."; > > } > > > > I'm still trying to correlate this with the Bridge model in 802.1Q or > > > > > > Item 2 - completed research and "other" is placeholder for Time > > sensitive network (TSN) work in 802.1. > > This correlates to detnet work. > > > > Cheerily, Sue > > > > -----Original Message----- > > From: Susan Hares [mailto:shares@ndzh.com] > > Sent: Wednesday, July 8, 2020 11:14 AM > > To: 'Benjamin Kaduk'; 'The IESG' > > Cc: draft-ietf-i2rs-yang-l2-network-topology@ietf.org; i2rs@ietf.org; > > i2rs-chairs@ietf.org > > Subject: RE: [i2rs] Benjamin Kaduk's No Objection on > > draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) > > > > 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-topol > > ogy/ > > > > > > > > ---------------------------------------------------------------------- > > 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-informativ > > e-re > > ferences/ > > 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