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

[Stephen Cheng <[e-mail]>]

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 <[e-mail]>
Date: 9/07/20 19:08 (GMT+12:00)
To: Stephen Cheng <[e-mail]>, [e-mail], [e-mail]
Cc: "Dongjie (Jimmy)" <[e-mail]>
Subject: EXTERNAL: RE: Mail regarding draft-ietf-i2rs-yang-l2-network-topology

Hi Stephen:

发件人: Stephen Cheng [mailto:[e-mail]]
发送时间: 2020年7月9日 12:53
收件人: [e-mail]; [e-mail]
主题: 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