Subject: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Fri, 03 Jul 2020 03:20:57 -0700

É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.

-- 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).

Should "sys-mac-address? " rather be "management-mac-address? "

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).

Why is 'ethernet' used rather than 'ieee802', notably to cover IEEE 802.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 ?

'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 ?

-- 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 ?

== 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'

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Jul 2020 16:40:08 -0400

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-masked]] On Behalf Of Éric Vyncke via Datatracker
Sent: Friday, July 3, 2020 6:21 AM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

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 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).

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.

-- 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. 

[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. 

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]?  ]

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. 

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.]  

-- 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. ] 

== 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. ] 

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 7 Jul 2020 07:36:20 +0000

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-masked]>
Date: Monday, 6 July 2020 at 22:40
To: Eric Vyncke <[email-masked]>, 'The IESG' <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

    Eric: 

    <shepherd hat on> 

    Sue 

    -----Original Message-----
    From: i2rs [mailto:[email-masked]] On Behalf Of Éric Vyncke via Datatracker
    Sent: Friday, July 3, 2020 6:21 AM
    To: The IESG
    Cc: [email-masked]; [email-masked]; [email-masked]
    Subject: [i2rs] Éric Vyncke's No Objection on draft-ietf-i2rs-yang-l2-network-topology-14: (with COMMENT)

    Regards,

    -éric

    == DISCUSS ==

    == COMMENTS ==

EV> I still would like to have a confirmation that IEEE has also reviewed this YANG module.

    -- Section 3 --

EV> Ack. I am trusting you about the YANG augment facility

EV> Good point. But, then should there be  'management-mac-address' added to the model? I.e., used as a source for LLDP frames ?

EV> I had confessed my ignorance before __ so bear with me __

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.

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.

    -- Section 4 --

    == NITS ==

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 7 Jul 2020 12:36:31 +0200

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