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 <[email protected]>; [email protected]; [email protected] Cc: Dongjie (Jimmy) <[email protected]> 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 <[email protected]<mailto:[email protected]>> Date: 9/07/20 19:08 (GMT+12:00) To: Stephen Cheng <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]> Cc: "Dongjie (Jimmy)" <[email protected]<mailto:[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]<mailto:[email protected]>; [email protected]<mailto:[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
