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

[Benjamin Kaduk <[e-mail]>]

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:[e-mail]] 
> Sent: Wednesday, July 8, 2020 11:14 AM
> To: 'Benjamin Kaduk'; 'The IESG'
> Cc: [e-mail]; [e-mail];
> [e-mail]
> 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:[e-mail]] On Behalf Of Benjamin Kaduk via
> Datatracker
> Sent: Monday, July 6, 2020 9:35 PM
> To: The IESG
> Cc: [e-mail]; [e-mail];
> [e-mail]
> 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-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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>