Re: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)
Hi! I don’t think that a formal review is needed from the IEEE. Sending an FYI e-mail to ieee-ietf-co...@ietf.org should be enough — letting the team know the current state of the document. Thanks! Alvaro. On July 7, 2020 at 10:20:14 AM, Susan Hares (sha...@ndzh.com) wrote: 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. ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
[i2rs] Secdir telechat review of draft-ietf-i2rs-yang-l2-network-topology-14
Reviewer: Christian Huitema Review result: Ready I have reviewed the changes made in draft 14. The new version of the security section recognizes and addresses the privacy issue flagged in my review of draft 13. ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
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:i2rs-boun...@ietf.org] On Behalf Of Eric Vyncke (evyncke) Sent: Tuesday, July 7, 2020 8:39 AM To: Qin Wu; Susan Hares; 'The IESG' Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org; i2rs-cha...@ietf.org 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 Date: Tuesday, 7 July 2020 at 14:22 To: Eric Vyncke , Susan Hares , 'The IESG' Cc: "draft-ietf-i2rs-yang-l2-network-topol...@ietf.org" , "i2rs@ietf.org" , "i2rs-cha...@ietf.org" 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:evyn...@cisco.com] 发送时间: 2020年7月7日 15:36 收件人: Susan Hares ; 'The IESG' 抄送: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org; i2rs-cha...@ietf.org 主题: 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 Date: Monday, 6 July 2020 at 22:40 To: Eric Vyncke , 'The IESG' Cc: "draft-ietf-i2rs-yang-l2-network-topol...@ietf.org" , "i2rs@ietf.org" , "i2rs-cha...@ietf.org" Subject: RE: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) Eric: 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:i2rs-boun...@ietf.org] On Behalf Of Éric Vyncke via Datatracker Sent: Friday, July 3, 2020 6:21 AM To: The IESG Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org; i2rs-cha...@ietf.org 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
Re: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)
Hi, Ben:
-邮件原件-
发件人: Benjamin Kaduk via Datatracker [mailto:nore...@ietf.org]
发送时间: 2020年7月7日 9:35
收件人: The IESG
抄送: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs-cha...@ietf.org;
i2rs@ietf.org
主题: 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?
[Qin]: No, it doesn't. management address is used to setup management channel
and provide management interface for the administrator.
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?
[Qin]: core network-topology module defined in RFC8345 doesn't specify name but
specify link-id, link-id should be unique among different network types,
For name defined in L2 topo, we follow the same design style for L3 topo, i.e.,
specify name for each L2 link which is optional attribute.
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.
[Qin]: pyang tool doesn't complain about this. If needed, we can change the
order.
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.)
[Qin]: See Martin's reply, thanks Martin.
/*
* Features
*/
nit: there seems to be a spurious blank line here.
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?
[Qin]:Yes, your are correct.
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 :)
[Qin] Correct.
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?
[Qin]: I think port and l2 termination point is equivalent, we could change to
layer 2 termination point description.
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"?
[Qin]: Sure, will do as you suggested.
}
//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.)
[Qin]: Okay, will move single line comment to the end of closing brace.
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?
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 Date: Tuesday, 7 July 2020 at 14:22 To: Eric Vyncke , Susan Hares , 'The IESG' Cc: "draft-ietf-i2rs-yang-l2-network-topol...@ietf.org" , "i2rs@ietf.org" , "i2rs-cha...@ietf.org" 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:evyn...@cisco.com] 发送时间: 2020年7月7日 15:36 收件人: Susan Hares ; 'The IESG' 抄送: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org; i2rs-cha...@ietf.org 主题: 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 Date: Monday, 6 July 2020 at 22:40 To: Eric Vyncke , 'The IESG' Cc: "draft-ietf-i2rs-yang-l2-network-topol...@ietf.org" , "i2rs@ietf.org" , "i2rs-cha...@ietf.org" Subject: RE: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) Eric: 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:i2rs-boun...@ietf.org] On Behalf Of Éric Vyncke via Datatracker Sent: Friday, July 3, 2020 6:21 AM To: The IESG Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org; i2rs-cha...@ietf.org 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
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:evyn...@cisco.com] 发送时间: 2020年7月7日 15:36 收件人: Susan Hares ; 'The IESG' 抄送: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org; i2rs-cha...@ietf.org 主题: 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 Date: Monday, 6 July 2020 at 22:40 To: Eric Vyncke , 'The IESG' Cc: "draft-ietf-i2rs-yang-l2-network-topol...@ietf.org" , "i2rs@ietf.org" , "i2rs-cha...@ietf.org" Subject: RE: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) Eric: 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:i2rs-boun...@ietf.org] On Behalf Of Éric Vyncke via Datatracker Sent: Friday, July 3, 2020 6:21 AM To: The IESG Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org; i2rs-cha...@ietf.org 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
Re: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)
Eric, thank you for your review. Just to add that I had given a (basic) explanation about the erros in the IESG Note of the ballot text. However, I wasn't sure where would that be visible. it pops up in the IESG writeups tab of the draft: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/writeup/ -m Le 2020-07-07 à 9:36, Eric Vyncke (evyncke) a écrit : 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 Date: Monday, 6 July 2020 at 22:40 To: Eric Vyncke , 'The IESG' Cc: "draft-ietf-i2rs-yang-l2-network-topol...@ietf.org" , "i2rs@ietf.org" , "i2rs-cha...@ietf.org" Subject: RE: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) Eric: 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:i2rs-boun...@ietf.org] On Behalf Of Éric Vyncke via Datatracker Sent: Friday, July 3, 2020 6:21 AM To: The IESG Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org; i2rs-cha...@ietf.org 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. -- 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
Re: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)
Ben,
thank you for your review. One comment in-line.
-m
Le 2020-07-07 à 3:35, Benjamin Kaduk via Datatracker a écrit :
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?
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.)
There has indeed been a discussion on that value in context of bfd-vxlan.
The issue is that the base VXLAN specification (rfc7348) doesn't specify
the range and so implementers have been left without clear guidance on
the use of that specific value.
Some implems support 0 and some don't.
Previously, in that document, the range was specified as 1..16777215.
I have suggested to the authors that it might be more appropriate to
make it 0..16777215, with 0 being implem specific.
/*
* Features
*/
nit: there seems to be a spurious blank line here.
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?
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 :)
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?
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"?
}
//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.)
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?
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.
reflected in the operational state
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 Date: Monday, 6 July 2020 at 22:40 To: Eric Vyncke , 'The IESG' Cc: "draft-ietf-i2rs-yang-l2-network-topol...@ietf.org" , "i2rs@ietf.org" , "i2rs-cha...@ietf.org" Subject: RE: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT) Eric: 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:i2rs-boun...@ietf.org] On Behalf Of Éric Vyncke via Datatracker Sent: Friday, July 3, 2020 6:21 AM To: The IESG Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org; i2rs-cha...@ietf.org 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. -- 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 ? I must admit that I am not familiar with the ietf-topology YANG model, so, the following COMMENTs can be plain wrong
