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

Qin Wu <bill.wu@huawei.com> Wed, 15 July 2020 03:35 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864B23A0E0E; Tue, 14 Jul 2020 20:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32ESOYNVW6Ti; Tue, 14 Jul 2020 20:35:44 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64013A0E0D; Tue, 14 Jul 2020 20:35:43 -0700 (PDT)
Received: from lhreml731-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 39BFC755720FC0C2A87A; Wed, 15 Jul 2020 04:35:41 +0100 (IST)
Received: from lhreml731-chm.china.huawei.com (10.201.108.82) by lhreml731-chm.china.huawei.com (10.201.108.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 15 Jul 2020 04:35:41 +0100
Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml731-chm.china.huawei.com (10.201.108.82) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Wed, 15 Jul 2020 04:35:40 +0100
Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.129]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0487.000; Wed, 15 Jul 2020 11:35:31 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Stephen Cheng <Stephen.Cheng@Aviatnet.com>, "i2rs@ietf.org" <i2rs@ietf.org>, "draft-ietf-i2rs-yang-l2-network-topology@ietf.org" <draft-ietf-i2rs-yang-l2-network-topology@ietf.org>
CC: "Dongjie (Jimmy)" <jie.dong@huawei.com>
Thread-Topic: EXTERNAL: RE: Mail regarding draft-ietf-i2rs-yang-l2-network-topology
Thread-Index: AdZaWPx/mdjq2jEgSJyIe1F7yD8CKA==
Date: Wed, 15 Jul 2020 03:35:31 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAAD848082@dggeml511-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.164.120.116]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD848082dggeml511mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/hDUFdhNxCFcCyjhRFg90nla-Shw>
Subject: Re: [i2rs] EXTERNAL: RE: Mail regarding draft-ietf-i2rs-yang-l2-network-topology
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2020 03:35:48 -0000

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 <bill.wu@huawei.com<mailto:bill.wu@huawei.com>>
Date: 9/07/20 19:08 (GMT+12:00)
To: Stephen Cheng <Stephen.Cheng@Aviatnet.com<mailto:Stephen.Cheng@Aviatnet.com>>, i2rs@ietf.org<mailto:i2rs@ietf.org>, draft-ietf-i2rs-yang-l2-network-topology@ietf.org<mailto:draft-ietf-i2rs-yang-l2-network-topology@ietf.org>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
Subject: EXTERNAL: RE: Mail regarding draft-ietf-i2rs-yang-l2-network-topology

Hi Stephen:

发件人: Stephen Cheng [mailto:Stephen.Cheng@Aviatnet.com]
发送时间: 2020年7月9日 12:53
收件人: i2rs@ietf.org<mailto:i2rs@ietf.org>; draft-ietf-i2rs-yang-l2-network-topology@ietf.org<mailto:draft-ietf-i2rs-yang-l2-network-topology@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.
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?
[Qin]: Not necessary if the L2 topo is the underlay topology or the lowest layer topology in the layered topology.
Warm regards,
Stephen Cheng
Aviat Networks