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

[Qin Wu <[e-mail]>]

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.

-Qin
-----邮件原件-----
发件人: Benjamin Kaduk [mailto:[e-mail]] 
发送时间: 2020年7月10日 7:11
收件人: Susan Hares <[e-mail]>
抄送: 'The IESG' <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
主题: 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:[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-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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs
>