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

[Stephen Cheng]

Please see below.

From: Susan Hares 
Sent: 2020年7月15日 3:23 AM
To: Stephen Cheng ; '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

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.
[SC3] I am well aware of this, and have been involved in implementations of 
draft-teas-yang-te-topo even though it is not yet a Proposed Standard. My 
question was whether we should have SLRG support in a layer 2 topology. Let me 
explain the context of the question: I am heavily involved in the work around 
draft-ietf-ccamp-mw-topology (Microwave L1 topology) at the moment, and one of 
the questions we have is whether SRLG should be supported. If SRLG is supported 
in L1 topology but not able to be propagated up to L2 topology, it wouldn’t 
serve much of a purpose.

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.
[SC3] Is there any IETF work on network view of bridging?

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.
[SC3] I don’t have much problem with sys-management-max. However I would argue 
that mgnt-address being a non L2 construct should be made to be a 
vendor-specific augmentation, rather than being defined in 
draft-ietf-i2rs-yang-l2-network-topology. Furthermore, if a domain controller 
implements a stack of topology, there is already ways to represent Management 
IP address: a node in ietf-l3-topology can be supported by a node in 
ietf-l2-topology.

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<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-sub-intf-vlan-model-07>
 that create a sub-interface.
[SC3] I am familiar with this YANG, and have been involved in a software 
implementation thereof. This is one of the reasons why I would like to see much 
better alignment between the 
draft-ietf-netmod-sub-intf-vlan-model-07<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-sub-intf-vlan-model-07>
 and draft-ietf-i2rs-yang-l2-network-topology. I believe in particular a L2 
topology YANG needs to support a sub-interface as a TP, such that it can 
support TPs on a higher layer topology.

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 A

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<https://datatracker.ietf.org/doc/html/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<mailto:i2rs@ietf.org>; 
draft-ietf-i2rs-yang-l2-network-topol...@ietf.org<mailto: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<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-sub-intf-vlan-model-07>.
  Qin, his co-authors and I w

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 
<https://datatracker.ietf.org/doc/html/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 
<https://datatracker.ietf.org/doc/html/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 associa

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

[Stephen Cheng]

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

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?


VT-TDM-REQ6 (IC): The topology model should allow association between 
components of different layers. For example, Layer 2 port may have several 
IPv4/IPv6 interfaces. The Layer-2 port and the IPv4/IPv6 interfaces would have 
an association.
[SC] How would this use case be implemented using the current  
draft-ietf-i2rs-yang-l2-network-topology? I would imagine that the multiple 
IPv4/IPv6 interfaces are running on different VLANs. As such without a way to 
represent a VLAN sub-interface on the layer 2 topology, it would be difficult 
to jointly work with ietf-l3-topology to support this use case. On the other 
hand if the layer 2 topology supports VLAN sub-interface TP, then a layer 3 TP 
modelled by ietf-l3-topology can be 1-1 supported by a VLAN sub-interface TP.

VT-TDM-REQ11b (OC): The topology data model should support the I2RS Client 
requesting the I2RS Agent to trace the path at all network layers that 
participate in the delivery of packets between two nodes. This trace MAY 
involve either an I2RS Agent information trace or the I2RS Agent requesting the 
routing function trace the path at multiple levels (L3/L2.5/L2/L1)
[SC] How would this use case be implemented using the current  
draft-ietf-i2rs-yang-l2-network-topology? Lets using L3VPN and provider bridge 
traffic as an example.




From: Stephen Cheng
Sent: 2020年7月11日 9:19 PM
To: Qin Wu ; i2rs@ietf.org; 
draft-ietf-i2rs-yang-l2-network-topol...@ietf.org
Cc: Dongjie (Jimmy) 
Subject: RE: EXTERNAL: RE: Mail regarding 
draft-ietf-i2rs-yang-l2-network-topology

Thank you for the quick reply.

1. I would like to better understand the use cases this proposed yang is 
supposed to address. I would say that in our experience many of the most useful 
l2 topology use cases require the modeling of vlan sub-interfaces as TP, 
without which I believe it would be of limited value.

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?

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?

  1.  The VLAN sub-interface YANG 
(https://tools.ietf.org/pdf/draft-ietf-netmod-sub-intf-vlan-model-06.pdf) 

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

[Stephen Cheng]

Thank you for the quick reply.

1. I would like to better understand the use cases this proposed yang is 
supposed to address. I would say that in our experience many of the most useful 
l2 topology use cases require the modeling of vlan sub-interfaces as TP, 
without which I believe it would be of limited value.

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?

3. Please also see inline comments below.

Thanks

 Original message 
From: Qin Wu 
Date: 9/07/20 19:08 (GMT+12:00)
To: Stephen Cheng , i2rs@ietf.org, 
draft-ietf-i2rs-yang-l2-network-topol...@ietf.org
Cc: "Dongjie (Jimmy)" 
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?

  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.

  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.
Aslo See section 4.4.6 Multihoming and link aggregation of RFC8345 for 
guideline.
[SC]: I understand that this draft propose to model the lag/membership using 
member-link-tp. My question was whether in addition to member-link-tp,   
whether LAG tp to membership tps are *also*  expected to be modeled as a 
supporting TP relationship?
Warm regards,
Stephen Cheng
Aviat Networks
___
i2rs mailing list
i2rs@ietf.org