Thanks Sue, see additional comments inline. 发件人: Susan Hares [mailto:[email protected]] 发送时间: 2020年7月14日 23:23 收件人: 'Stephen Cheng' <[email protected]>; Qin Wu <[email protected]>; [email protected]; [email protected] 抄送: Dongjie (Jimmy) <[email protected]> 主题: 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:[email protected]] On Behalf Of Stephen Cheng Sent: Tuesday, July 14, 2020 12:06 AM To: Qin Wu; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 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. [Qin]:Correct, in addition, SRLG is more Traffic engineering specific attribute, there is another topology model called TE topology model which has already entered into RFC Queue and specified lots of TE specific attributes. 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. Qin has implementation reports on this fact – so I will let him speak regarding implementations. The VLAN interface was planned as a basic sub-interface for IP (draft-ietf-netmod-sub-intf-vlan-model-07<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-sub-intf-vlan-model-07>). As such, this model is being developed as one of the basic models in NETMOD. Please let us know if you find any discontinuities in the model. Qin, I and others on the I2RS WG would be glad to discuss the combination of these models. If you feel the draft-ietf-netmod-sub-intf-vlan-model-07.txt should have a virtual example, please let us know as well. If you feel that an explanation draft would be helpful on this point, please let us know. [Qin]: I think L2 topology focuses on Layer 2 attributes definition which has already specified vlan-id as one attribute under l2-termination-point-attributes, l3 topology (RFC8346)focuses on layer 3 attributes definition which has already specified IPv4/IPv6 address as one attribute under l3-termination-point-attributes. As described in RFC8345, the network hierarchy (stack) allows any given network to have one or more "supporting networks" and constitute layered topology, see the figure 2 and figure 3 of RFC8345 for example, section 4.4.2 and section 4.4.7 of RFC8345 has already provided mapping strategy, which can help establish the mapping between L3 termination point in the upper layer topo and L2 termination point in the lower layer topo. L2 Topology just derived this mapping strategy from RFC8345. Not additional guidelines and principles are specially defined. Also how to do this mapping is implementation specific. Hope this clarifies. 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) Path tracing for L2 might be appropriate for Provider Based Bridging. At this point, the L2 topology trace involves simply query the models. [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. For PBB, it would be by a direct query method. If there is a new path query function from IEEE 802.1, it could be added as an augment to this L2 topology model. For L3 VPNS, I refer you to the netmod sub-interface yang model (draft-ietf-netmod-sub-intf-vlan-model) and the TEAS basic topology models (draft-ietf-teas-yang-te-topo-22.txt , RFC8776). Again, I will refer to Qin and his co-authors for the implementation details of how these models have been implemented. They are working with specific developers and have first hand knowledge. [Qin]: not sure this should be functionalities that should be tied with L2 topology, I think L2 topo, L3 topo, TE topo, Network topo could be a good foundation, but how path trace functionality can work together with network topology is more like a broad question, is this something related to OAM, please refer to https://tools.ietf.org/wg/lime/ https://tools.ietf.org/html/draft-ietf-bfd-yang-17 is this something related to generic data collection mechanism that is defined in IETF, please refer to https://tools.ietf.org/html/rfc8641 https://tools.ietf.org/html/rfc8639 We can use YANG push and NETCONF polling mechanism to get the data we request. -Qin From: Stephen Cheng Sent: 2020年7月11日 9:19 PM To: Qin Wu <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: Dongjie (Jimmy) <[email protected]<mailto:[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
