Okay, I have incorporated your comments in v-15, https://tools.ietf.org/html/draft-ietf-i2rs-yang-l2-network-topology-15 Thanks!
-Qin -----邮件原件----- 发件人: Eric Vyncke (evyncke) [mailto:[email protected]] 发送时间: 2020年7月9日 18:49 收件人: Qin Wu <[email protected]>; Susan Hares <[email protected]>; 'Eric Vyncke (evyncke)' <[email protected]>; 'The IESG' <[email protected]> 抄送: [email protected]; [email protected]; [email protected] 主题: Re: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) Qin This is OK for me, I would even suggest to use 'kbps' as integer64 Thank you for addressing my concern Wish you the best -éric -----Original Message----- From: Qin Wu <[email protected]> Date: Thursday, 9 July 2020 at 11:17 To: Eric Vyncke <[email protected]>, Susan Hares <[email protected]>, "'Eric Vyncke (evyncke)'" <[email protected]>, 'The IESG' <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: RE: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) Hi, Eric: Regarding the rate, yes, we could have rate changes, what I am looking for a good use case to support lower rate, Change units from Mbps to kbps will reduce the range, change fraction-digits from 2 to 3 or 4 seems more reasonable to me. OLD TEXT: leaf rate { type decimal64 { fraction-digits 2; } units "Mbps"; description "Link rate."; } NEW TEXT: leaf rate { type decimal64 { fraction-digits 4; } units "Mbps"; description "Link rate."; } If we make such change, do you think this is what you are looking for? -Qin -----邮件原件----- 发件人: Eric Vyncke (evyncke) [mailto:[email protected]] 发送时间: 2020年7月9日 16:33 收件人: Qin Wu <[email protected]>; Susan Hares <[email protected]>; 'Eric Vyncke (evyncke)' <[email protected]>; 'The IESG' <[email protected]> 抄送: [email protected]; [email protected]; [email protected] 主题: Re: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) Qin, Honestly, I do not mind too much about "system-mac-address" (and the LLDP was just an example) but per symmetry with other leaves, adding a 'management-mac-address' could be useful. But, again, I do not mind too much. About the link rate... whether it is Sigfox or other data link does not really mater but I keep wondering why not having a minimum lower than 10 kbps is such a problem for the authors/WG... Why not simply augment the number of decimals on this leaf ? It is a decimal64 and by looking at RFC 6020 section 9.3.4 is seems that even using 3 decimals for Mbps (or simply using rate in kbps) will not limit the upper rate. In short, I am still really puzzled why this lower bound on rate is in the model. -éric -----Original Message----- From: iesg <[email protected]> on behalf of Qin Wu <[email protected]> Date: Thursday, 9 July 2020 at 08:40 To: Susan Hares <[email protected]>, "'Eric Vyncke (evyncke)'" <[email protected]>, 'The IESG' <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: RE: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) Hi, Eric： Sorry for late reply, your question on wireless is difficult to me,:-) Regarding Key editorial additions: Sure, we should replace CRC with RCS and fix inconsistency on L2 vs Layer 2. Regarding key technical changes: I think system-mac-address will be used for sending LLDP frames, we don't need another management MAC address, maybe we use different terminology to talk about the same thing. As for speeds for IoT and wireless, I am using figure 1 in draft-ietf-lpwan-schc-over-sigfox as an example, I still believe we should not model the link between Device and Sigfox BS (RG) in the Layer 2 network topology, bear in mind, L2 topo focuses network side topology. see reference https://www.ietf.org/id/draft-ietf-lpwan-schc-over-sigfox-02.txt Do you think the link speed of wired line between Sigfox BS and Sigfox network should be less than 10 kbps? No? Anyway if the wireless can benefit from L2 topology, I hope it could take augmentation approach. -Qin -----邮件原件----- 发件人: Susan Hares [mailto:[email protected]] 发送时间: 2020年7月7日 22:20 收件人: 'Eric Vyncke (evyncke)' <[email protected]>; Qin Wu <[email protected]>; 'The IESG' <[email protected]> 抄送: [email protected]; [email protected]; [email protected] 主题: RE: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) Eric: Another round of comments are below. As to the IEEE review, this goes through the IETF-IEEE liaison. I'm happy to have this yang model reviewed by the IEEE liaison is in 2020. Qin's review occurred late 2019. I'm unclear who the 2020 liaison is from IETF to IEEE. Asking specifically about the Ethernet is useful. Martin/Alvaro/Deborah may know who to ask. FCS is a more generic term. I'm sure that Qin will agree to utilize this term. Qin response may come in 2-3 hours. More comments below to your questions. [Sue2] indicates the next round of answers. Key editorial additions: 1) FCS replacing CRC 2) Inconsistent use of L2 versus Layer 2. Key technical changes: 1) management-mac-address - used for sending LLDP frames. 2) Speeds for IoT and the Wireless - could we get an expert from Internet on IoT directorate, and Any suggestions on 802.11 person? I have managed a team that wrote code for early 802.11 code in L2 switches, but I have not done that since 2010. If you do not have a key person, Qin or Donald Eastlake or other 802.11 people can help me. Thanks for going through the model carefully. Susan Hares -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Eric Vyncke (evyncke) Sent: Tuesday, July 7, 2020 8:39 AM To: Qin Wu; Susan Hares; 'The IESG' Cc: [email protected]; [email protected]; [email protected] Subject: Re: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) Hello Qin Long time not talked ☹ Satisfied to read that IEEE has reviewed the document as this was a major concern of mine. If IEEE reviewers do not mind about using the old 'ethernet' word rather than 'ieee802', then I can only respect your and their choice. About the Ethernet frame length, your suggested text is improved but you may want to also specify for IEEE 802.11 whether the 'frame control' and other fields are also counted. I know, L2 is a pain __ Also (and my bad), please use FCS rather than CRC. About the rate, AFAIK, SigFox is below 1 kbps and LoRa is just a little faster. So, why not covering those rates ? Except if there is another limitation that I am not aware of Sincerely hope it helps -éric -----Original Message----- From: Qin Wu <[email protected]> Date: Tuesday, 7 July 2020 at 14:22 To: Eric Vyncke <[email protected]>, Susan Hares <[email protected]>, 'The IESG' <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: RE: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) Hi, Eric: Thanks Sue for helping clarification. See followup comments inline below. -----邮件原件----- 发件人: Eric Vyncke (evyncke) [mailto:[email protected]] 发送时间: 2020年7月7日 15:36 收件人: Susan Hares <[email protected]>; 'The IESG' <[email protected]> 抄送: [email protected]; [email protected]; [email protected] 主题: Re: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) Hello Sue, Thank you for your reply; no surprise, you take your document shepherd role seriously. About the YANG validations, I was indeed suspecting something about the tool itself rather with the document: thank you for clearing my concerns. Your statement obviously clears my semi DISCUSS. Please find below some more comments prefixed with EV> (mainly about IEEE and indeed my lack of knowledge about the IETF topology model) All the best, -éric -----Original Message----- From: Susan Hares <[email protected]> Date: Monday, 6 July 2020 at 22:40 To: Eric Vyncke <[email protected]>, 'The IESG' <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: RE: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) Eric: <shepherd hat on> Thank you for being concerned about the errors reported by the tools. These errors have been growing with each revision of the yang tools kit without any change to the Yang. Yang doctors have OKed the draft. We have asked the Yang Doctors to address this issue and the ADs. It is hard to fix ghost bugs. The authors will fix anything that is a real bug rather than a ghost bug. Other comments are below. I will answer quickly because Authors are in China. They may correct me - as it is there document. Sue -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Éric Vyncke via Datatracker Sent: Friday, July 3, 2020 6:21 AM To: The IESG Cc: [email protected]; [email protected]; [email protected] Subject: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) Éric Vyncke 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: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below a couple on non-blocking COMMENTs (and I would appreciate a reply to each of my COMMENTs because for some of them I was close to ballot a DISCUSS). I hope that this helps to improve the document, Regards, -éric == DISCUSS == == COMMENTS == Generic: is there a reason why the YANG validation results in 19 errors and 4 warnings? Sue Harres (the shepherd) mentions in her write-up that 9 errors are linked to missing IEEE but what about the 10 remaining errors ? Has there been a review by IEEE of this YANG model? While the shepherd is extensive and detailed, there is no mention of a coordination with IEEE. EV> I still would like to have a confirmation that IEEE has also reviewed this YANG module. [Qin]:All IEEE references has been reviewed by IEEE folks during WGLC and cross posted to the netmod mailing list for IEEE folks to chime in by Sue and Rob help relay the discussion between IETF and IEEE. This is one of links related to IEEE part, can't remember other links. https://mailarchive.ietf.org/arch/msg/i2rs/nVPOs8oBHwk5AFQlwyaVYRvoEnk/ Hope this address your comment. -- Section 3 -- "The Layer 2 (L2) network topology YANG module is designed to be generic and applicable to Layer 2 networks built with different L2 technologies." Is this statement correct? What about LoraWAN, Sigfox, and other LP-WAN technologies? Or technologies that may be using different MTU sizes on each direction? or having more parameters than this (such as being NBMA that should be captured). [Sue: It is generic abstract representation just like the network topology is a generic abstract representation. Abstract models can be augmented with specific details. See TEAS augmentation of the abstract network topology model. As a chair, I delayed this model until it was implemented on a set of topologies. If we can get proposals from running code or people plan running code for yang models, I will glad work on augmentations for any of these topologies. The only caveat is if my AD agrees to this work. EV> Ack. I am trusting you about the YANG augment facility Should "sys-mac-address? " rather be "management-mac-address? " [Sue: My understanding from building switches is that the sys-mac-address may be different than the management-mac-address. The system processor may have a different chip that the management processor. Therefore, based on the plan implementations - I would have to object to a change. EV> Good point. But, then should there be 'management-mac-address' added to the model? I.e., used as a source for LLDP frames ? [Qin]: In most cases I have seen, only management IP address is used as a source for LLDP frames. Do you have other case in mind? [Sue2]: Do you wish us to add a management IP address for LLDP frames? Most switches do support LLDP. I must admit that I am not familiar with the ietf-topology YANG model, so, the following COMMENTs can be plain wrong :-( ... It is unclear to me the difference between 'node' and 'termination-point'. If not defined in the ietf-topology, then please define before first use (I had to read the YANG module to understand). [Sue: This shows a misunderstand of the base topology model. May I politely suggest that I will cover this offline with you or that you discuss this with Alvaro or Martin or Rob Wilton [NM/OPS]? ] EV> I had confessed my ignorance before __ so bear with me __ Why is 'ethernet' used rather than 'ieee802', notably to cover IEEE 802.11 ? [Sue: The IEEE 802.1 is now linking multiple IEEE 802.11 segments using IEEE 802.11 segments. Donald Eastlake was a part of that process in 802.11 specification. In my limited understanding, it is correct to use ieee802 as ieee802.1 is provides the linkage. The use of the term Ethernet was vetted by several discussions regarding the 802.1 models this links to. If the IEEE and the IETF suggest something else (in their harmonization of this model between groups), the authors will change to. We've put in the draft what all parties agreed to (i2rs participants and IETF yang experts with IEEE knowledge) suggested. If you have a concrete alternate proposal the same groups agree to, we will adjust. We've been trying to do the best to stay aligned to the best common practices of both groups. EV> my point was that the current use of 'ethernet' appears outdated and I would have preferred 'ieee802' (covering a lot of technologies including the good old Ethernet). Nothing blocking on my side, but, I would like that authors/WG have a 2nd thought on this name. [Qin]: I understand what you ask is allow ieee802.11 technology series specific parameters can be augmented into L2 topology model. The current model doesn't prevent you from doing that, e..g, choice l2-termination-point-type { description "Indicates termination-point type specific attributes."; case ethernet { leaf mac-address { type yang:mac-address; description "Interface MAC address."; } ... } Case 802.11 { } If we rename Ethernet as 'ieee802', do you think all the parameters under etherent case can be reused by IEEE802.11? While most termination points have a single MAC address, are we sure that no termination point will ever have more than one MAC address ? [Sue: Multiple termination points are possible in the basic topology model. Again, I suggest a review of the basic topology model concepts may be useful. ] 'rate' leaf is in Mbps and with 2 decimals, i.e., the lowest rate is 10 kbps and this is already higher than some layer-2 links. Any reason to ignore lower rate links ? [Sue: Implementation reports gave us the lowest current rate of 10 kbps. If you believe that this lower link boxes will implement yang models, we are glad to adjust this rate. L2 model are difficult because there are so many things out there.] EV> agreed on the diversity of L2... Hence, why limiting the rate to a multiple of 10 kbps? Even if I do not envision IoT devices on low rate link being provisioned by NETCONF/YANG, there could be NMS/OPS/??? systems using this YANG module to model the actual topology for their own purposes. [Qin]: Do we need to model IoT device and wireless link as part of network topology? Suppose wireless link should be modelled, data rate is usually in Mbps, see https://www.intel.com/content/www/us/en/support/articles/000005725/network-and-i-o/wireless-networking.html [Sue2]: IoT devices and wireless links are part of the 802.1 model. As shepherd/chair I had resisted adding these features because we did not have an implementation. I suggest allowing different data rates at least. Adding the IoT and wireless portions of the model without implementations concerned me. However, Wireless links are part of all switches. Many switches are deployed for sensors. Eric - if you could provide us a link to an expert in either of these features, we can add this intelligently. Otherwise, it would be better to allow a short draft to augment this model rather than be incorrect In the modeling [Sue2 ends] -- Section 4 -- "leaf maximum-frame-size" please specify whether Ethernet pre-amble, inter-frame gap, and CRC should be included. The text for Ethernet and for PPP are identical, so, why repeating it ? [Sue: I will let the authors take a first pass on why they left out Ethernet pre-amble, inter-frame gap, and CRC. After they comment, I will provide a comment on the repetition. ] [Qin]: Based on our analysis, maximum-frame-size should include CRC but not include preamble, inter-frame gap, https://en.wikipedia.org/wiki/Ethernet_frame we can clarify this in the text. Based on your comment, how about the following change: leaf maximum-frame-size { type uint32; description "Maximum L2 frame size that can be transported on the data link layer, e.g. Ethernet frame. If L2 frame is an Ethernet frame, the maximum frame size should include CRC and should not include preamble,Start Frame Delimiter and Inter frame gap."; } == NITS == Sometimes 'L2' is used, sometimes 'Layer 2' is used. Not very consistent ;-) I am not an English speaker, but, I believe 'Layer 2 topology' should be written 'layer-2 topology' [Good catch - Sometimes, the obvious aids to clarity get missed after you read a document long enough. ] [Qin]:Thanks Eric. _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
