Re: [i2rs] EXTERNAL: RE: Mail regarding draft-ietf-i2rs-yang-l2-network-topology

[Qin Wu]

2. Mgnt-address is an IP address, a layer 3 construct. What is the reason for 
it to be modeled in a layer 2 topology?

[Qin]: This has been discussed already, see 
https://mailarchive.ietf.org/arch/msg/i2rs/F0uiFUvNTuTmWRq_ANpPq3SrLkE/
3. Please also see inline comments below.

Thanks

 Original message 
From: Qin Wu mailto:bill...@huawei.com>>
Date: 9/07/20 19:08 (GMT+12:00)
To: Stephen Cheng 
mailto:stephen.ch...@aviatnet.com>>, 
i2rs@ietf.org, 
draft-ietf-i2rs-yang-l2-network-topol...@ietf.org
Cc: "Dongjie (Jimmy)" mailto:jie.d...@huawei.com>>
Subject: EXTERNAL: RE: Mail regarding draft-ietf-i2rs-yang-l2-network-topology

Hi Stephen:

发件人: Stephen Cheng [mailto:stephen.ch...@aviatnet.com]
发送时间: 2020年7月9日 12:53
收件人: i2rs@ietf.org; 
draft-ietf-i2rs-yang-l2-network-topol...@ietf.org
主题: Mail regarding draft-ietf-i2rs-yang-l2-network-topology

Dear authors,

I have a number of questions regarding this L2 topology YANG.


  1.  Does draft-ietf-i2rs-yang-l2-network-topology support the modelling of a 
termination point that maps to a VLAN sub-interface?
This capability would facilitate the creation of a topology stack for the 
following use cases:

 *   Mapping a ietf-l3-topology TP over a vlan sub-interface
In this case a TP in ietf-l3-topology instance would be supported by a VLAN 
sub-interface TP in the l2-topology
 *   Mapping different VLAN IDs in a L2 ports to different services

   i.  For 
example, on a particular L2 port, VLAN 23 might be an attachment circuit for 
VPLS #78, where as VLAN 99 might be an attachment circuit for L3VPN #999

If draft-ietf-i2rs-yang-l2-network-topology does not have the capability to 
model VLAN sub-interface as a TP, is there a different way for 
draft-ietf-i2rs-yang-l2-network-topology to support the above use cases?

[Qin]: Good question, this could be documented in another new draft.  Also see 
4.4.2 (Underlay Hierarchies and Mappings) of RFC8345 for guideline.

[SC]: the two example use cases are common uses. If the current proposal 
doesn't address them what use cases does it address?

[Qin]: See my clarification following Sue’s.

  1.  The VLAN sub-interface YANG 
(https://tools.ietf.org/pdf/draft-ietf-netmod-sub-intf-vlan-model-06.pdf) being 
developed has some overlap with draft-ietf-i2rs-yang-l2-network-topology. It 
would be good if there would be better alignment between the two:

 *   Use similar definition/fields where possible; even better use shared 
grouping definition

   i.  For 
example outer-tag and inner-tag

 *   VLAN sub-interface YANG 
(https://tools.ietf.org/pdf/draft-ietf-netmod-sub-intf-vlan-model-06.pdf) 
flexible encapsulation supports symmetric and asymmetric rewrites, which does 
not appear to be supported by draft-ietf-i2rs-yang-l2-network-topology.
[Qin]: Both drafts import ieee802-dot1q-types, this is how we align 
with each other. The big difference between the model proposed by both drafts 
is one is device model, the other is network model.
[SC]: Could you  please help me undertand why this network model omit the 
modeling of tag pushing tag popping and tag replacement, which are modeled in 
vlan sub-interface YANG? This is a curious omission, as to fully undertand the 
flow of traffic across a network we would need to undertand how the tags are 
transformed at each interface.
[Qin]: L2 topo model in most case is discovered instead of being configured by 
the client. Don’t mix network topology model with device level model. Network 
topology model is used to model topology information across large amount of 
device within the network while  device level model such as sub interface model 
is used to configure one specific device.

  1.  Consider the scenario where a domain controller implementing 
draft-ietf-i2rs-yang-l2-network-topology is also implementing schema mounted 
ietf-interface to model the interface stacks of the managed devices:
-  Is there a mechanism in draft-ietf-i2rs-yang-l2-network-topology to 
associate a L2 TP with the corresponding interface entry in the schema mounted 
ietf-interface?
  [Qin]: This is the base model, if you want to support this complicate 
case, I think base model extension is needed.
[SC]: ok

  1.  For a LAG link, would the LAG TP be expected to be also represented by 
/nw:networks/nw:network/nw:node:termination-point/tp-id/supporting-termination-point
 to its membership TPs?
It would be useful to clarify for uniform implementation across different 
vendors.
   [Qin] Lag and member-link-tp under l2-termination-point-type choice 
can be used to support the case you mentioned below. See the definition of Lag 
and member-link for more details.

Re: [i2rs] EXTERNAL: RE: Mail regarding draft-ietf-i2rs-yang-l2-network-topology

[Qin Wu]

Thanks Sue, see additional comments inline.
发件人: Susan Hares [mailto:sha...@ndzh.com]
发送时间: 2020年7月14日 23:23
收件人: 'Stephen Cheng' ; Qin Wu ; 
i2rs@ietf.org; draft-ietf-i2rs-yang-l2-network-topol...@ietf.org
抄送: Dongjie (Jimmy) 
主题: RE: [i2rs] EXTERNAL: RE: Mail regarding 
draft-ietf-i2rs-yang-l2-network-topology

Stephen:

I’m sure Qin will also provide you answers to your questions regarding your 
questions about specific implementation details on the L2 models.

However, as the shepherd and co-chair of I2RS – let me provide a bit of 
high-level background.  The use cases were data that provide the ideas that the 
WG gathered on what the WC could do.

The I2RS movement forward was stymied by the length of time it took to move the 
NETCONF/NETMOD working groups toward the  NMDA architecture (2018/2019).  Many 
of the Topology models were implemented by open daylight as of 2014 and most of 
the I2RS models were adopted by 2015.  This slowness in the basic topology 
caused the WG to be put in hiatus by AD in 2015 (Alia Atlas) and our 
instructions were to finish our current models without additional 
functionality.IETF has a mantra of running code.

The L3 models because the base for TEAS work, L2SM, and L3SM concepts.   The 
SLRG issues at layer 3 were concepts that have been picked up by the TEAS at 
layer 3.   RFC8776 defines SLRG data types in preparation for 
draft-ietf-teas-yang-te-topo-22.txt  which has been approved for publication.   
Please see the te-link-info-attributes container in 
draft-teas-yang-te-topo-22.txt for the SLRG objects.

The layer 2 work awaited implementation models and work from IEEE 802.1 for 
802.1Q updates.  As the Yang models which currently are available which seem to 
relate are:  ieee-dot1q-bridge-yang.txt, ieee802-dotq-tpmr.yang.txt, and 
ieee-dot1x.yang.txt.   These models release in 2018 seems to have implementers 
going.
(Recall IETF looks for implementation of models to verify the NM/OPS). 
Implementations were completed for the L2 topology model in 2018-2019.

The L2 topology model is a virtual data model for NM/OPS aligned with IETF 
focus on NM/OPS using Yang models.  (See Open Daylight for implementations 
using topology models).   IETF topology models differ from IEEE models in that 
we seek interoperability based on common use.  As such, we may be modeling 
things (such as the sys-management-mac) which are common industry practices 
beyond the IEEE models.  My question to IEEE-IETF interface committee asked 
about common practices for the system management interface which were not 
standardizes (as far as I could tell) in the IEEE 802.1 Yang models.

A great deal of Yang work was completed for the IEEE 802.1Q work.  It seems 
appropriate that the virtual topology work for IETF NM/OPS would be aligned 
with the IEEE 802.1Q part for TSN  (time sensitive networking).
It may be appropriate for I2RS to pick up the L2 topology work again.

One other document that may be of interest to you is the
 
draft-ietf-netmod-sub-intf-vlan-model-07
 that create a sub-interface.

If you know of additional IEEE yang models that we should have considered, 
please send email to the I2rs WG.

I have answered your specific question below.  Qin will add more details.

Sue

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Stephen Cheng
Sent: Tuesday, July 14, 2020 12:06 AM
To: Qin Wu; i2rs@ietf.org; 
draft-ietf-i2rs-yang-l2-network-topol...@ietf.org
Cc: Dongjie (Jimmy)
Subject: Re: [i2rs] EXTERNAL: RE: Mail regarding 
draft-ietf-i2rs-yang-l2-network-topology

Further to last email, I am going through the use cases defined in 
https://tools.ietf.org/pdf/draft-ietf-i2rs-usecase-reqs-summary-03.pdf, to 
determine the topology use cases related to Layer 2 topology. This document is 
referred to in your draft in section 1 “Further use cases where the data model 
can be applied are described in [I2RS-UR].”

If you  think these are useful documents, I can work to send this document 
through the IETF publication process.  These were interim documents to help the 
WG.

Topo-REQ-03 (IC): Topology Manager should be able to collect and keep current 
topology information for multiple layers of the network: Transport, Ethernet 
and IP/MPLS, as well as information for multiple Layer 3 IGP areas and multiple 
Autonomous Systems (ASes). This information must contain cross-layer unerlying 
Shared Risk Link Groups (SRLG) within transport or Ethernet layers. (from 
section 3.2)
[SC] Is SRLG supported in draft-ietf-i2rs-yang-l2-network-topology?

Yes – The intent of the L2 network model is to align with appropriate IEEE 
models, draft-teas-yang-te-topo-22.txt, and 
draft-ietf-netmod-sub-intf-vlan-model-07.
  Qin, his co-authors and I would like to receive any 

Re: [i2rs] EXTERNAL: RE: Mail regarding draft-ietf-i2rs-yang-l2-network-topology

[Susan Hares]

Stephen: 

 

I’m sure Qin will also provide you answers to your questions regarding your 
questions about specific implementation details on the L2 models.  

 

However, as the shepherd and co-chair of I2RS – let me provide a bit of 
high-level background.  The use cases were data that provide the ideas that the 
WG gathered on what the WC could do.

 

The I2RS movement forward was stymied by the length of time it took to move the 
NETCONF/NETMOD working groups toward the  NMDA architecture (2018/2019).  Many 
of the Topology models were implemented by open daylight as of 2014 and most of 
the I2RS models were adopted by 2015.  This slowness in the basic topology 
caused the WG to be put in hiatus by AD in 2015 (Alia Atlas) and our 
instructions were to finish our current models without additional 
functionality.IETF has a mantra of running code. 

 

The L3 models because the base for TEAS work, L2SM, and L3SM concepts.   The 
SLRG issues at layer 3 were concepts that have been picked up by the TEAS at 
layer 3.   RFC8776 defines SLRG data types in preparation for 
draft-ietf-teas-yang-te-topo-22.txt  which has been approved for publication.   
Please see the te-link-info-attributes container in 
draft-teas-yang-te-topo-22.txt for the SLRG objects. 

 

The layer 2 work awaited implementation models and work from IEEE 802.1 for 
802.1Q updates.  As the Yang models which currently are available which seem to 
relate are:  ieee-dot1q-bridge-yang.txt, ieee802-dotq-tpmr.yang.txt, and 
ieee-dot1x.yang.txt.   These models release in 2018 seems to have implementers 
going.  

(Recall IETF looks for implementation of models to verify the NM/OPS). 
Implementations were completed for the L2 topology model in 2018-2019.   

 

The L2 topology model is a virtual data model for NM/OPS aligned with IETF 
focus on NM/OPS using Yang models.  (See Open Daylight for implementations 
using topology models).   IETF topology models differ from IEEE models in that 
we seek interoperability based on common use.  As such, we may be modeling 
things (such as the sys-management-mac) which are common industry practices 
beyond the IEEE models.  My question to IEEE-IETF interface committee asked 
about common practices for the system management interface which were not 
standardizes (as far as I could tell) in the IEEE 802.1 Yang models. 

 

A great deal of Yang work was completed for the IEEE 802.1Q work.  It seems 
appropriate that the virtual topology work for IETF NM/OPS would be aligned 
with the IEEE 802.1Q part for TSN  (time sensitive networking).  

It may be appropriate for I2RS to pick up the L2 topology work again.  

 

One other document that may be of interest to you is the 

 draft-ietf-netmod-sub-intf-vlan-model-07 

  that create a sub-interface. 

 

If you know of additional IEEE yang models that we should have considered, 
please send email to the I2rs WG. 

 

I have answered your specific question below.  Qin will add more details. 

 

Sue 

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Stephen Cheng
Sent: Tuesday, July 14, 2020 12:06 AM
To: Qin Wu; i2rs@ietf.org; draft-ietf-i2rs-yang-l2-network-topol...@ietf.org
Cc: Dongjie (Jimmy)
Subject: Re: [i2rs] EXTERNAL: RE: Mail regarding 
draft-ietf-i2rs-yang-l2-network-topology

 

Further to last email, I am going through the use cases defined in 
https://tools.ietf.org/pdf/draft-ietf-i2rs-usecase-reqs-summary-03.pdf, to 
determine the topology use cases related to Layer 2 topology. This document is 
referred to in your draft in section 1 “Further use cases where the data model 
can be applied are described in [I2RS-UR].”

 

If you  think these are useful documents, I can work to send this document 
through the IETF publication process.  These were interim documents to help the 
WG. 

 

Topo-REQ-03 (IC): Topology Manager should be able to collect and keep current 
topology information for multiple layers of the network: Transport, Ethernet 
and IP/MPLS, as well as information for multiple Layer 3 IGP areas and multiple 
Autonomous Systems (ASes). This information must contain cross-layer unerlying 
Shared Risk Link Groups (SRLG) within transport or Ethernet layers. (from 
section 3.2)

[SC] Is SRLG supported in draft-ietf-i2rs-yang-l2-network-topology?

 

Yes – The intent of the L2 network model is to align with appropriate IEEE 
models, draft-teas-yang-te-topo-22.txt, and 
draft-ietf-netmod-sub-intf-vlan-model-07 

 .  Qin, his co-authors and I would like to receive any comments regarding the 
alignment.  We have decided to release the L2 topology document based on the 
current state of implementations.  If you feel we should include additional 
work for SLRG, it could be put in an augmentation model.  

 

VT-TDM-REQ6 (IC): The topology model should allow association between