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>rg>; 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
> >