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:sha...@ndzh.com]
> Sent: Wednesday, July 8, 2020 11:14 AM
> To: 'Benjamin Kaduk'; 'The IESG'
> Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org;
> i2rs-cha...@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
Re: [i2rs] Benjamin Kaduk's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)
Hi Qin,
On Tue, Jul 07, 2020 at 01:40:23PM +, Qin Wu wrote:
> 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.
Ah, I think I see.
So it would only be a problem if the device didn't speak IP on its
management channel, which can be different from what L2 data-plane
technology it switches. And if the device doesn't speak IP on that
channel, it's probably not going to have much use for this YANG module...
> 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.
Okay, so if everything is using the link-id as the primary key then there's
no real issues with having name collisions.
> 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.
I saw the same ordering in draft-ietf-pim-igmp-mld-snooping-yang (also on
this week's telecha), so I expect that this is fine to leave as-is.
>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.
It's probably good to have the descriptions be consistent if there's not an
actual difference to emphasize.
> list qinq {
>[...]
>leaf svlan-id {
> type dot1q-types:vlanid;
> description
>"SVLAN ID.";
>}
>leaf cvlan-id
Re: [i2rs] Magnus Westerlund's Discuss on draft-ietf-i2rs-yang-l2-network-topology-14: (with DISCUSS)
Hi, Sue, I raised a discuss on this just to ensure that IESG would discuss the issue today. I raised it based on the Glenn Parsons request on the IEEE-IETF mailing list and that there where apparently some confusion. So I don't really know which failures did occur in this case. I think it would be good to analyze it. I would suspect a combination of issues. Likely including that turn over among AD makes people loose history and process. >From my personal perspective, I as AD would appreciate a WG chairs that reach out to the AD when they thing there might be need for coordination with external bodies. I understand that for this document they might not be as clear. Cheers Magnus Westerlund > -Original Message- > From: Susan Hares > Sent: den 9 juli 2020 16:28 > To: Magnus Westerlund ; 'The IESG' > > Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs-cha...@ietf.org; > i2rs@ietf.org > Subject: RE: Magnus Westerlund's Discuss on draft-ietf-i2rs-yang-l2-network- > topology-14: (with DISCUSS) > > Magnus: > > Thank you for raising this process discuss. > > The authors and I strong desire the I2RS model to be a NM management > model that imports the appropriate things from IEEE. > > I have two points you should add to your process discuss: > > 1) Where did the coordination instructions change for the WG chair? > > In the midst of the discussion within the IESG would you please consider how > to provide better instructions for the lowly chair and authors on this > topic. In > the past, the IESG sent information to IEEE-IETF.(I was scribe during > the > first meeting of the IETF-IESG over the TRILL issue). I was the TRILL > chair for > the last years of the TRILL WGs life. I have participated in the IEEE > 802.1 and > IETF during the TRILL issue when we were trying to resolve a common > management for TRILL between IEEE and IETF. During that time, it was > important that a few focused voices discussed issues regarding TRILL. It > would help me to understand when this transitioned to chairs being able to > send requests to the IEEE-IETF coordination list. > > We also asked for numerous reviews by Yang Doctors who were > knowledgeable regarding IETF. I delayed publication request several times > until it appeared all issues were resolved. This "sudden" surprise is > indeed > amazing since the L2 is 5 years old. It is older than the 8021Qcp-2018 > official > models. > > > 2) Why are I2RS topology models are not seen as Network Management by > the IEEE. > > These are virtual topology models used by open source platforms for > management. (E.g. Open Daylight). > > Sue > > -Original Message- > From: Magnus Westerlund via Datatracker [mailto:nore...@ietf.org] > Sent: Thursday, July 9, 2020 7:44 AM > To: The IESG > Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs-cha...@ietf.org; > i2rs@ietf.org > Subject: Magnus Westerlund's Discuss on draft-ietf-i2rs-yang-l2-network- > topology-14: (with DISCUSS) > > Magnus Westerlund has entered the following ballot position for > draft-ietf-i2rs-yang-l2-network-topology-14: Discuss > > 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/ > > > > -- > DISCUSS: > -- > > This is a process discuss. > > There apparently have been a failure to coordinate this with IEEE per > discussion on the IETF-IEEE mailing list. > > Glenn Parsons requested that this was deferred to give IEEE time to review > it > at their plenary next week. I think this time should be given before > approving > this document. > > > > > smime.p7s Description: S/MIME cryptographic signature ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
Re: [i2rs] Robert Wilton's Discuss on draft-ietf-i2rs-yang-l2-network-topology-14: (with DISCUSS and COMMENT)
Rob:
Thank you for raising the process discussion regarding IEEE-IETF
coordination. Qin, his co-authors, and I desire to have a model which uses
the best common practices of the IEEE and IETF.
Qin and his co-authors will work through all the specific description
changes below and the auto-neg description in his responses. We were
pointed to draft-ietf-netmod-sub-intf-vlan-model and worked to adjust to
this model. Specific suggestions for changes would be helpful at this
point.
I have the following two higher level questions as the shepherd/co-chair:
1) This document was repeated reviewed by the Yang doctors prior to
submission.
We were pointed to draft-ietf-netmod-sub-intf-vlan-model and worked to
adjust to this model.
What happened in the process of Yang model review that caused you to have so
many comments at the last moment? Where did we miss the clues that there
were problems in the email from the Yang doctors?
2) Policy questions regarding IEEE and IETF focus on QinQ versus VLAN
I have one question for you and the rest of the IESG. The IEEE terminology
for QinQ versus VLAN does not always match the industry use. IETF has
always maintained running code for operational networks is the most
important factor. IEEE has maintained consistency of their own terminology
was most important. These differences cause the switches two have both
terminologies. How should we support both?
Susan Hares
-Original Message-
From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Robert Wilton via
Datatracker
Sent: Thursday, July 9, 2020 8:13 AM
To: The IESG
Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs@ietf.org;
i2rs-cha...@ietf.org
Subject: [i2rs] Robert Wilton's Discuss on
draft-ietf-i2rs-yang-l2-network-topology-14: (with DISCUSS and COMMENT)
Robert Wilton has entered the following ballot position for
draft-ietf-i2rs-yang-l2-network-topology-14: Discuss
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/
--
DISCUSS:
--
I support Magnus's discuss regarding IEEE 802.1Q WG review.
I also feel that the YANG model could benefit from another editorial pass:
- In many places the descriptions are very terse, and references are
missing.
- The way that auto-neg is defined doesn't really match the 802.3
specification, probably splitting it into two separate leaves (one for
whether auto-neg is on/off, and separate one for the duplex setting would
be better).
- The use of terminology for VLAN vs QinQ might not be acceptable to IEEE.
Finding names that are more closely aligned with the terms in 802.1Q may be
helpful (although if I understand it correctly, 802.1Q bridges don't
directly expose double VLAN tags). Possibly some of the
terminology/description from draft-ietf-netmod-sub-intf-vlan-model (which
has been reviewed by IEEE 802.1Q
WG) may be helpful here.
--
COMMENT:
--
Mostly minor/editorial comments (###) on the YANG model, but I do think
that it would be helpful for these to be discussed and addressed as
appropriate:
4. Layer 2 Topology YANG Module
import ietf-inet-types {
prefix inet;
reference
"Section 4 of RFC 6991";
}
import ietf-yang-types {
prefix yang;
reference
"Section 3 of RFC 6991";
}
###
These references should probably both just be: "RFC 6991: Common YANG Data
Types"
revision 2020-06-29 {
description
"Initial revision";
reference
"RFC : A YANG Data Model for Layer 2 Network
Topologies";
}
###
I would reorder these sections to be (which will solve the forward reference
issue mentioned by Ben):
feature-stmt
identity-stmt
typedef-stmt
I'm surprised that pyang didn't flag this.
/*
* Typedefs
*/
typedef vni {
type uint32 {
range "0..16777215";
}
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.";
reference
"RFC 7348: Virtual eXtensible Local Area Network (VXLAN):
A Framework for Overlaying Virtualized Layer 2
Networks over Layer 3 Networks";
Re: [i2rs] Magnus Westerlund's Discuss on draft-ietf-i2rs-yang-l2-network-topology-14: (with DISCUSS)
Magnus: Thank you for raising this process discuss. The authors and I strong desire the I2RS model to be a NM management model that imports the appropriate things from IEEE. I have two points you should add to your process discuss: 1) Where did the coordination instructions change for the WG chair? In the midst of the discussion within the IESG would you please consider how to provide better instructions for the lowly chair and authors on this topic. In the past, the IESG sent information to IEEE-IETF.(I was scribe during the first meeting of the IETF-IESG over the TRILL issue). I was the TRILL chair for the last years of the TRILL WGs life. I have participated in the IEEE 802.1 and IETF during the TRILL issue when we were trying to resolve a common management for TRILL between IEEE and IETF. During that time, it was important that a few focused voices discussed issues regarding TRILL. It would help me to understand when this transitioned to chairs being able to send requests to the IEEE-IETF coordination list. We also asked for numerous reviews by Yang Doctors who were knowledgeable regarding IETF. I delayed publication request several times until it appeared all issues were resolved. This "sudden" surprise is indeed amazing since the L2 is 5 years old. It is older than the 8021Qcp-2018 official models. 2) Why are I2RS topology models are not seen as Network Management by the IEEE. These are virtual topology models used by open source platforms for management. (E.g. Open Daylight). Sue -Original Message- From: Magnus Westerlund via Datatracker [mailto:nore...@ietf.org] Sent: Thursday, July 9, 2020 7:44 AM To: The IESG Cc: draft-ietf-i2rs-yang-l2-network-topol...@ietf.org; i2rs-cha...@ietf.org; i2rs@ietf.org Subject: Magnus Westerlund's Discuss on draft-ietf-i2rs-yang-l2-network-topology-14: (with DISCUSS) Magnus Westerlund has entered the following ballot position for draft-ietf-i2rs-yang-l2-network-topology-14: Discuss 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/ -- DISCUSS: -- This is a process discuss. There apparently have been a failure to coordinate this with IEEE per discussion on the IETF-IEEE mailing list. Glenn Parsons requested that this was deferred to give IEEE time to review it at their plenary next week. I think this time should be given before approving this document. ___ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
[i2rs] Robert Wilton's Discuss on draft-ietf-i2rs-yang-l2-network-topology-14: (with DISCUSS and COMMENT)
Robert Wilton has entered the following ballot position for
draft-ietf-i2rs-yang-l2-network-topology-14: Discuss
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/
--
DISCUSS:
--
I support Magnus's discuss regarding IEEE 802.1Q WG review.
I also feel that the YANG model could benefit from another editorial pass:
- In many places the descriptions are very terse, and references are missing.
- The way that auto-neg is defined doesn't really match the 802.3
specification, probably splitting it into two separate leaves (one for whether
auto-neg is on/off, and separate one for the duplex setting would be better).
- The use of terminology for VLAN vs QinQ might not be acceptable to IEEE.
Finding names that are more closely aligned with the terms in 802.1Q may be
helpful (although if I understand it correctly, 802.1Q bridges don't directly
expose double VLAN tags). Possibly some of the terminology/description from
draft-ietf-netmod-sub-intf-vlan-model (which has been reviewed by IEEE 802.1Q
WG) may be helpful here.
--
COMMENT:
--
Mostly minor/editorial comments (###) on the YANG model, but I do think that
it would be helpful for these to be discussed and addressed as appropriate:
4. Layer 2 Topology YANG Module
import ietf-inet-types {
prefix inet;
reference
"Section 4 of RFC 6991";
}
import ietf-yang-types {
prefix yang;
reference
"Section 3 of RFC 6991";
}
###
These references should probably both just be: "RFC 6991: Common YANG Data
Types"
revision 2020-06-29 {
description
"Initial revision";
reference
"RFC : A YANG Data Model for Layer 2 Network
Topologies";
}
###
I would reorder these sections to be (which will solve the forward reference
issue mentioned by Ben):
feature-stmt
identity-stmt
typedef-stmt
I'm surprised that pyang didn't flag this.
/*
* Typedefs
*/
typedef vni {
type uint32 {
range "0..16777215";
}
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.";
reference
"RFC 7348: Virtual eXtensible Local Area Network (VXLAN):
A Framework for Overlaying Virtualized Layer 2
Networks over Layer 3 Networks";
}
typedef l2-flag-type {
type identityref {
base flag-identity;
}
description
"Base type for L2 flags. One example of L2 flag
type is trill which represents trill topology
type.";
}
###
This isn't really a base type. Given where this flag is used, would this be
better as an "network-flag-type", with a description more similar to the ones
below?
typedef node-flag-type {
type identityref {
base flag-identity;
}
description
"Node flag attributes. The physical node can be
one example of node flag attribute.";
}
typedef link-flag-type {
type identityref {
base flag-identity;
}
description
"Link flag attributes. One example of link flag
attribute is the pseudowire.";
}
###
Should there be identities defined for l2-flag, node-flag and link-flag that
derive from flag-identity? That would them make these three typedefs reference
different things rather than all referencing the same base flags.
typedef l2-network-event-type {
type enumeration {
enum add {
value 0;
description
"A Layer 2 node or link or termination-point
has been added.";
}
enum remove {
value 1;
description
"A Layer 2 node or link or termination-point
has been removed.";
}
enum update {
value 2;
description
"A Layer 2 node or link or termination-point
has been updated.";
}
}
description
"Layer 2 network event type for notifications.";
}
###
Since these are events, I would suggest renaming
[i2rs] Magnus Westerlund's Discuss on draft-ietf-i2rs-yang-l2-network-topology-14: (with DISCUSS)
Magnus Westerlund has entered the following ballot position for draft-ietf-i2rs-yang-l2-network-topology-14: Discuss 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/ -- DISCUSS: -- This is a process discuss. There apparently have been a failure to coordinate this with IEEE per discussion on the IETF-IEEE mailing list. Glenn Parsons requested that this was deferred to give IEEE time to review it at their plenary next week. I think this time should be given before approving this document. ___ 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)
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
Date: Thursday, 9 July 2020 at 11:17
To: Eric Vyncke , Susan Hares , "'Eric
Vyncke (evyncke)'" , '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:
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:evyn...@cisco.com]
发送时间: 2020年7月9日 16:33
收件人: Qin Wu ; Susan Hares ; 'Eric
Vyncke (evyncke)' ; '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)
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 on behalf of Qin Wu
Date: Thursday, 9 July 2020 at 08:40
To: Susan Hares , "'Eric Vyncke (evyncke)'"
, '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：
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:sha...@ndzh.com]
发送时间: 2020年7月7日 22:20
收件人: 'Eric Vyncke (evyncke)' ; Qin
Wu ; '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)
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
Re: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)
Sue, Thank you for having requested IEEE feedback and for forwarding the info to all the recipients. You suggestion to delay the IESG review of this draft until deep IEEE review end of July sounds sensible to me. Up to the responsible AD, Martin, to decide of course. Finally, if there is a short document describing " the virtual models of I2RS for IETF NM", then I will welcome its reference (I admit my ignorance there). Regards -éric -Original Message- From: Susan Hares Date: Thursday, 9 July 2020 at 10:44 To: Eric Vyncke , 'Qin Wu' , "'Eric Vyncke (evyncke)'" , '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 and Martin: I have received email back from Glenn Parsons regarding the sys-mac-address - who is in charge of the IEEE Yang modules for TSN PAR (time sensitive network). The email started with a rant regarding the lack of coordination over this model occurring at the last minute, and a request to delay final review of this model until the july 20th IEEE 802.1 meeting. Since the first WG publication of draft-ietf-i2rs-yang-l2-network-topology-00.txt in 2015 predates the IEEE 802.1 Yang models for the bridge, it seems any coordination for the last 5 years regarding this model has gone to /dev/null. In order to keep harmonious working between IEEE 802.1 and IETF for this I2RS model, it may be necessary for this review and delay to occur. Qin, his co-authors, and I have repeatedly tried to make sure this coordination has occurred. We have received "acks" from internal IETF sources that were supposedly knowledgeable. I recommend that you and Martin communicate with Glenn Parsons in order to foster a good review. Since the virtual models of I2RS for IETF NM are not well understood in the IESG, you may need my help or members of the I2RS WG to help explain the basic concept of the I2RS Virtual models. By the way, Glenn did not provide any new data on the sys-mac-address concept. Sue -Original Message- From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com] Sent: Thursday, July 9, 2020 4:33 AM To: Qin Wu; Susan Hares; 'Eric Vyncke (evyncke)'; '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) 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 on behalf of Qin Wu Date: Thursday, 9 July 2020 at 08:40 To: Susan Hares , "'Eric Vyncke (evyncke)'" , '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： 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:sha...@ndzh.com] 发送时间: 2020年7月7日 22:20 收件人: 'Eric Vyncke (evyncke)' ; Qin Wu ; 'The
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:evyn...@cisco.com]
发送时间: 2020年7月9日 16:33
收件人: Qin Wu ; Susan Hares ; 'Eric Vyncke
(evyncke)' ; '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)
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 on behalf of Qin Wu
Date: Thursday, 9 July 2020 at 08:40
To: Susan Hares , "'Eric Vyncke (evyncke)'"
, '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：
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:sha...@ndzh.com]
发送时间: 2020年7月7日 22:20
收件人: 'Eric Vyncke (evyncke)' ; Qin Wu
; '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)
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:
Re: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)
Eric and Martin: I have received email back from Glenn Parsons regarding the sys-mac-address - who is in charge of the IEEE Yang modules for TSN PAR (time sensitive network). The email started with a rant regarding the lack of coordination over this model occurring at the last minute, and a request to delay final review of this model until the july 20th IEEE 802.1 meeting. Since the first WG publication of draft-ietf-i2rs-yang-l2-network-topology-00.txt in 2015 predates the IEEE 802.1 Yang models for the bridge, it seems any coordination for the last 5 years regarding this model has gone to /dev/null. In order to keep harmonious working between IEEE 802.1 and IETF for this I2RS model, it may be necessary for this review and delay to occur. Qin, his co-authors, and I have repeatedly tried to make sure this coordination has occurred. We have received "acks" from internal IETF sources that were supposedly knowledgeable. I recommend that you and Martin communicate with Glenn Parsons in order to foster a good review. Since the virtual models of I2RS for IETF NM are not well understood in the IESG, you may need my help or members of the I2RS WG to help explain the basic concept of the I2RS Virtual models. By the way, Glenn did not provide any new data on the sys-mac-address concept. Sue -Original Message- From: Eric Vyncke (evyncke) [mailto:evyn...@cisco.com] Sent: Thursday, July 9, 2020 4:33 AM To: Qin Wu; Susan Hares; 'Eric Vyncke (evyncke)'; '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) 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 on behalf of Qin Wu Date: Thursday, 9 July 2020 at 08:40 To: Susan Hares , "'Eric Vyncke (evyncke)'" , '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： 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:sha...@ndzh.com] 发送时间: 2020年7月7日 22:20 收件人: 'Eric Vyncke (evyncke)' ; Qin Wu ; '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) 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)
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 on behalf of Qin Wu Date: Thursday, 9 July 2020 at 08:40 To: Susan Hares , "'Eric Vyncke (evyncke)'" , '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： 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:sha...@ndzh.com] 发送时间: 2020年7月7日 22:20 收件人: 'Eric Vyncke (evyncke)' ; Qin Wu ; '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) 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
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:sha...@ndzh.com] 发送时间: 2020年7月7日 22:20 收件人: 'Eric Vyncke (evyncke)' ; Qin Wu ; '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) 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:
