Subject: [ieee-ietf-coord] Aid with draft-ietf-i2rs-yang-l2-network-topology-14

From: "Susan Hares" <[email-masked]>
Date: Wed, 8 Jul 2020 13:32:41 -0400

Greetings IEEE and IETF coordination team: 

https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/

is being reviewed by the IESG for publication as an RFC.  It is being
proposed by the I2RS WG.

This draft provides a Yang model for L2 logical topologies that is being
combined with L3 logical network models.  This model is being implemented by
3+ vendors.   In this process, we have the following questions that overlap
between IEEE and IETF.   

1) Regarding system management  MAC Address - 

Where in 802.1Q-2018 do I find the Yang model for the system management port
for a switch? 

By system management, I mean that port that configuration information is
exchanged about.   I do not mean the port that sends LLDP packets. 

http://ieee802.org/1/files/public/YANGs/ieee802-dot1q-bridge.yang

2)  Where can I find the latest status of yang models for the time sensitive
work in 802.1? 

This model considers an L2 port as a termination point which is "in  use"
for traffic, blocking traffic, down (due to hardware) or some other
function.   We wish to determine if time sensitive configurations will
provide another concept for port.  A general explanation would be helpful. 

3) Would liaison give me  reading on what status the following references
should be in

draft-ietf-i2rs-yang-l2-network-topology?  

Ben Kaduk suggests that: 

  a) Normative --> informative   RFC3688 and RFC7951 

  b) Informative--> normative: [IEEE802.1Qcp], RFC7348

I'd appreciate your joint opinion on these matters.   We are trying to
follow the best common practices of both IEEE and IETF in this draft.  

Susan Hares

Co-chair I2RS

Shepherd for draft-ietf-i2rs-yang-l2-network-topology

---

From: Russ Housley <[email-masked]>
Date: Wed, 8 Jul 2020 14:40:29 -0400

This document is on the IESG agenda for tomorrow (2020-07-09), so a prompt response would be most helpful to avoid delay.

Russ

> On Jul 8, 2020, at 1:32 PM, Susan Hares <[email-masked]> wrote:
> 
> https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/ <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/>
>  
> is being reviewed by the IESG for publication as an RFC.  It is being proposed by the I2RS WG.
> This draft provides a Yang model for L2 logical topologies that is being combined with L3 logical network models.  This model is being implemented by 3+ vendors.   In this process, we have the following questions that overlap between IEEE and IETF.   
>  
> 1) Regarding system management  MAC Address – 
>  
> Where in 802.1Q-2018 do I find the Yang model for the system management port for a switch? 
> By system management, I mean that port that configuration information is exchanged about.   I do not mean the port that sends LLDP packets. 
>  
> http://ieee802.org/1/files/public/YANGs/ieee802-dot1q-bridge.yang <http://ieee802.org/1/files/public/YANGs/ieee802-dot1q-bridge.yang>
>  
> 2)  Where can I find the latest status of yang models for the time sensitive work in 802.1? 
>  
> This model considers an L2 port as a termination point which is “in  use” for traffic, blocking traffic, down (due to hardware) or some other function.   We wish to determine if time sensitive configurations will provide another concept for port.  A general explanation would be helpful. 
>  
> 3) Would liaison give me  reading on what status the following references should be in
> I’d appreciate your joint opinion on these matters.   We are trying to follow the best common practices of both IEEE and IETF in this draft.  
>  
> Susan Hares
> Co-chair I2RS
> _______________________________________________
> ieee-ietf-coord mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ieee-ietf-coord <https://www.ietf.org/mailman/listinfo/ieee-ietf-coord>

---

From: Glenn Parsons <[email-masked]>
Date: Thu, 9 Jul 2020 01:56:50 +0000

I will start by expressing my disappointment.

There has been a YANG item on our coordination list for years.  We have been updating IETF on our YANG module work and our issues.  We have been integrating IEEE work into the IETF YANG catalog as drafts and final approved modules.  This IETF L2 YANG module clearly overlaps with IEEE 802.1 and yet as far as I can tell this is the first indication of that to us.  It is not even in your YANG catalog as a draft.  Hours before your final approval, there is an urgent request for comment.    I would instead request that this be deferred by IESG to give 802.1 time to review the module at our plenary next week.

That said, all the IEEE 802.1 YANG modules are  on our website:  http://ieee802.org/1/files/public/YANGs/
And they are also in the YANG catalog github repository.
Published modules: https://github.com/YangModels/yang/tree/master/standard/ieee/published/802.1
802.1 Draft modules per project: https://github.com/YangModels/yang/tree/master/standard/ieee/draft/802.1

Clause 12.4 in 802.1Q-2018 is the bridge management entity clause, I suspect you are asking about the bridges/bridge/address in the YANG module.

IEEE 802.1Qcp-2018 should be normative (it is freely available https://ieeexplore.ieee.org/document/8467507).  The document should be clearer than just looking at the modules, for example Table 48-7 shows Generic bridge management information.

Cheers,
Glenn.

--
Glenn Parsons
Chair, IEEE 802.1 WG
[email-masked]<mailto:[email-masked]>
+1-613-963-8141

From: ieee-ietf-coord <[email-masked]> On Behalf Of Susan Hares
Sent: Wednesday, July 8, 2020 1:33 PM
To: [email-masked]
Cc: [email-masked]
Subject: [ieee-ietf-coord] Aid with draft-ietf-i2rs-yang-l2-network-topology-14

http://ieee802.org/1/files/public/YANGs/ieee802-dot1q-bridge.yang<https://protect2.fireeye.com/v1/url?k=516a7d20-0fcac74e-516a3dbb-866038973a15-2c9158d6b703682e&q=1&e=42b15d09-5d4e-483a-812a-dffdf64a4195&u=http%3A%2F%2Fieee802.org%2F1%2Ffiles%2Fpublic%2FYANGs%2Fieee802-dot1q-bridge.yang>

This model considers an L2 port as a termination point which is "in  use" for traffic, blocking traffic, down (due to hardware) or some other function.   We wish to determine if time sensitive configurations will provide another concept for port.  A general explanation would be helpful.

Ben Kaduk suggests that:

I'd appreciate your joint opinion on these matters.   We are trying to follow the best common practices of both IEEE and IETF in this draft.

Susan Hares
Co-chair I2RS