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

Stephen Cheng <Stephen.Cheng@Aviatnet.com> Sat, 11 July 2020 09:18 UTC

Return-Path: <Stephen.Cheng@Aviatnet.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 8B0243A0978; Sat, 11 Jul 2020 02:18:41 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.onmicrosoft.com
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 yNHoMt4PCPd2; Sat, 11 Jul 2020 02:18:39 -0700 (PDT)
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2051.outbound.protection.outlook.com [40.107.236.51]) (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 D61843A0977; Sat, 11 Jul 2020 02:18:38 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FDXw40ZzKooDFcYrPwcTcI6lzVkoVI7VDinn9/pdd2JXy4/p5lvCbf8ixzJAYJC7ZJ6R0/dmcfCoecRrPlW1joaazxYl+MUKuUF6jDDtdvUooYoCE2owF6Fx+x+DYu++G/MXRTpGhKkKGHw8Wwvdq0o3hxQrMxLm/vBgJ5fHMRnFXxExZyQNby3BJ/JyJD4w5nd9/zcdSgnKLzA/D+Jocw5FhpNVV1nxZAsdENbXnAOfnjzsR7q6YTlA056ITYnSAkNXGHhVj6K7YKRyyxPczhx3eVcwv3x7xtwBXYimv0U00/7Opv7RV4ubkZemm5myMRszC8yavFZLbCWC+WYgEA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6ofbedDjnmeDAChAwWRAiN+l0wDBKnhrRN6O62X8D84=; b=ZB4u0pbg6L+8z/yFOcft/LINKJblPjTmnKUNzbcSdiif2BvmE8g0Qi22XC2CzF7pgdP+bcd17LieYhQaE7CuHPwZXaTA3KwvvRV9io9ra8y1LsIQI/u8Mhup72w9QMkahdA+Vrt/wx/+UwOPeOvXc5QpgxHqDmA7deVjCDWB2lSWdj/69jqhuNHleU0SFeHU0juDTRP1x+Hr3pPMezFpSlFUYJWwXzN0+zPsrkYGEuSO9sBx0pI9f9sGpiWikD8EWqDWtjXPWIHHv50QforfYRaVTK7LTMuKab+VspYuO6hnWW2tgk/yCOEuVde2lUaiiZ4YXlWpLCiSil5opw9xUg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=aviatnet.com; dmarc=pass action=none header.from=aviatnet.com; dkim=pass header.d=aviatnet.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatus-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6ofbedDjnmeDAChAwWRAiN+l0wDBKnhrRN6O62X8D84=; b=YY28dAWox78oqNoPOz1bZNGt8cYVpNnpDEXMCHsqclHGZOorxfvBxrWtf2ddUUHTRhfQfI9Z5VWZlbuvj1BaR42Y9akK4kX/r6lJE3pxTyrLdsRdXSVrzBHoxQ/j5HEO5ExzEHqx3TZqjetpZvsvP0cHzeyM64ypTCX9VLEg7bM=
Received: from CY4PR2201MB1239.namprd22.prod.outlook.com (2603:10b6:910:66::15) by CY4PR22MB0631.namprd22.prod.outlook.com (2603:10b6:903:e7::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20; Sat, 11 Jul 2020 09:18:36 +0000
Received: from CY4PR2201MB1239.namprd22.prod.outlook.com ([fe80::351b:4d5b:7181:543c]) by CY4PR2201MB1239.namprd22.prod.outlook.com ([fe80::351b:4d5b:7181:543c%4]) with mapi id 15.20.3174.024; Sat, 11 Jul 2020 09:18:36 +0000
From: Stephen Cheng <Stephen.Cheng@Aviatnet.com>
To: Qin Wu <bill.wu@huawei.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: AQHWV2F/6lWCVOMcsEqhGacuA6/7Mg==
Date: Sat, 11 Jul 2020 09:18:36 +0000
Message-ID: <CY4PR2201MB12393F904AB5980C2F0FF7E099620@CY4PR2201MB1239.namprd22.prod.outlook.com>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=Aviatnet.com;
x-originating-ip: [49.224.102.148]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 15ac4e34-cfe4-4c80-b32a-08d8257b6414
x-ms-traffictypediagnostic: CY4PR22MB0631:
x-microsoft-antispam-prvs: <CY4PR22MB0631CBD89324ED69114BAFC699620@CY4PR22MB0631.namprd22.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zysES0aRpKrzbwz+IxZnlI/+5chzX1X9XInOM7K09QB1LD9DVtYdFT3kc7d7Qa3xWWdCZecDVupVWe0+qWPHoY3YivkLmOUzrNuDs1+2MXfSAZI+NwweHd6/TnH57jRI8oo13JDzEaKtHcbrUV/0D7ic+ymiqFiOXp6RBJHg6fUl5ImxZaU987M+SLSnT42Hf6GweK7PEXMjR1yA7PzDakr/i3Wf56ksmvNMnCeEtS0TZWd42xRFcs4WumV2beEnF/i4aj3quvvFw4NRj56GyHoQLkWfliVeOgC1Rj+fs6wlyiR/QAHQT+FuGsMeIj24cb4rtqBJX90d/zLWI+jFdhBfgZQV7dDW9iQkgqE7RA74GTOzco65AYn2bPjDPVcUCdlPyVnFyKsGDSCaTCXLDA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR2201MB1239.namprd22.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(376002)(136003)(39850400004)(396003)(26005)(110136005)(6506007)(53546011)(7696005)(4326008)(8676002)(55016002)(9686003)(2906002)(66556008)(8936002)(83380400001)(86362001)(166002)(33656002)(52536014)(316002)(186003)(478600001)(5660300002)(91956017)(71200400001)(64756008)(66446008)(66476007)(76116006)(66946007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: MbnM5sDTGHYVwXoMteo1knUJ+p3jj8bo5nYdrzSTClTGKk5/5vTtVKFJ5SB/SComZrb4P5YXLf0H40U0wTT7UlcGQIpfPmHRP0XvJ/tcrULXq3O80f38zR85Atwpm3e10Bq9ZJZxw0httVWy5TfSoX49RgJ1Bce78WZwgR8S2JjHYbi9vlUPzxEiKEqzUR5GdBR8CxPjh/JlDlWn4ualSIUM/9stLIvq0cCZFXqIx5X+X97/9uNRkAHxcCXk2bFCIIcOgSHHXHW5crd8uFFxui3Ewb90ebZaTztve3g1Dg6ZYZuWTAhgaVaV9/USgDAV4q2Zr7Q7aG4LRBbCKWM551XaByi2oTwppjKpNFbxjhA4PArR5XTEVy1Nt5/aZ8ss/yBdxsbd1zsOtlRpK5j2PJrnMX3NGXLfvCbCD/u5jukY9nBSoQN5skEeRtWUVla8PDNv3EjImkE9S8R1Qm9FnIQCdS/08SVh6ZXtHEBiGEnarMiPiTygPdp14M9/batf
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CY4PR2201MB12393F904AB5980C2F0FF7E099620CY4PR2201MB1239_"
MIME-Version: 1.0
X-OriginatorOrg: aviatnet.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CY4PR2201MB1239.namprd22.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 15ac4e34-cfe4-4c80-b32a-08d8257b6414
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2020 09:18:36.1769 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8d7d22b9-3890-4eef-95a6-a226e64151be
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: q3a37gBtWuvb2rZSf053N1r6QKEQ4/MmQh1Vf400Cd02JJh7PjlS2pFW5/wxQy49YMtkhggH5xc2CQixVv0zGA147u+sJ1449aBTBRc6Q4g=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0631
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/Q-JLUqxzD3JgpZ05-MGmrU1wiGo>
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: Sat, 11 Jul 2020 09:18:42 -0000

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

  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