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 <[email protected]> Date: 9/07/20 19:08 (GMT+12:00) To: Stephen Cheng <[email protected]>, [email protected], [email protected] Cc: "Dongjie (Jimmy)" <[email protected]> Subject: EXTERNAL: RE: Mail regarding draft-ietf-i2rs-yang-l2-network-topology Hi Stephen: 发件人: Stephen Cheng [mailto:[email protected]] 发送时间: 2020年7月9日 12:53 收件人: [email protected]; [email protected] 主题: 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 [email protected] https://www.ietf.org/mailman/listinfo/i2rs
