Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3D43A07FC for ; Mon, 13 Jul 2020 14:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JMeqa3EJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=v0PTBd44 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 oN6bt4g6d5_W for ; Mon, 13 Jul 2020 14:54:51 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B343A0CB0 for ; Mon, 13 Jul 2020 14:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13430; q=dns/txt; s=iport; t=1594677266; x=1595886866; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=XElqA81BRrvTn5BFYTK7ZQucxNjcamVtTjx0JlKZaVU=; b=JMeqa3EJdRD7BFiPJHxzlj/DP4zetqokPE6oZ+o3IjiRu83hrAqe7FkC 915vcB1PXXKhoJnGQikyd+QIOHfy2t5IFHQi5xgwLeG8mUe5YwLwgJt7p buOcGXXuMQn/2mxg//VnJssISu/bLZJWg5ycSmx8RqCJ6ws/ytKtmJXPN M=; IronPort-PHdr: =?us-ascii?q?9a23=3AQRLRBxxeDAuSIpHXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWFt/FkhlmPW4jHuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorHWyO04THsviNBXep3So5msUHR?= =?us-ascii?q?PyfQN+OuXyHNvUiMK6n+C/8pHeeUNGnj24NLhzNx6x6w7Ws5ob?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMCQDo1gxf/5pdJa1WCoEJgm0vIy4?= =?us-ascii?q?Hb1gvLAqHbwONUZNyhGyCUwNVCwEBAQwBASMKAgQBAYRMAoIaAiQ4EwIDAQE?= =?us-ascii?q?LAQEFAQEBAgEGBG2FWwyFbwEBAQEDEhsTAQElBg0PAgEIDgMEAQEvMh0IAQE?= =?us-ascii?q?EARIIGoMFgX5NAy4BAwuebQKBOYhhdIE0gwEBAQWBRkGDIhiCDgMGgTiCaoo?= =?us-ascii?q?IGoFBP4ERQ4FPfj6CXAIDAYEuBCsrgxyCLY81iVacFQqCXYhRkSiCdIk2kwC?= =?us-ascii?q?RbIoilFICBAIEBQIOAQEFgWojgVdwFYMkUBcCDZIPhRSFQnQ3AgYIAQEDCXy?= =?us-ascii?q?NB4E1AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.75,348,1589241600"; d="scan'208,217";a="781202717" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Jul 2020 21:54:24 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 06DLsPmn017869 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Jul 2020 21:54:25 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 13 Jul 2020 16:54:24 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 13 Jul 2020 16:54:24 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 13 Jul 2020 16:54:23 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XfhgoebBrhjvGCby1gtmqV/Swpsqlrkamy1pt2xj/9jHU6lykYbdcJ0K9ndTt89TiNjBLemE67MCzi2O2X8fCqpPuDpHhYe5T9IsNnwDfNXZ34y+SB5uY8EWti3QElKAAtCSw3vEYfF4KsFthsRAiwD1Sqy/z0i4+6W0E85Ex2bFQ5kGRUuIuSuM4yidVUHhHkD+2EYUuL/WgeCgSjBmv0cVtTLA8H/v54S2uyjDrKa+uZDoQVE84jOMHHJo7fYGofI+aoSkITwQj4YutlcLiHlaZDGCis/lyymRL9EFdIgyDlgUZjG/e50oaMnqpWCGXEGKw1NweiF5+d0eFmBBCQ== 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=sSdn7wcv6DUWu9WyYOTAmkAsNENKmmz2Ah9128kOhgQ=; b=SLsLWFNU0vlG9PHJ/7XqoipHjoUq+0dVc5kbcLhtT1rjd6w716WmIiVGqXZIwxeOjMuP8CX+dueehnsfhEnu2wbVgnQvBaqY1QUX+7VqiA8WwpNF6zCIFIlCHhepnA4Wd58g5ypLMtb0GNVb6dUSAhbsLAapOjWzqzYa+T1WTX5PvH9k6Hw7nDl8ppz3/KeQSoEZybZXvoQf8NkxM5mwTI64V3+c/a/QDxpzxp4PjbLz7u47Y5ZjmUf72NUNQeokDCkRRMisd3By0+YCJd0qZWKi9zj9kwdIVUBB+6NJUIJOn08jyZLBLL8oydwd+iLzDSKalVmba3n2odxuVp0MWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sSdn7wcv6DUWu9WyYOTAmkAsNENKmmz2Ah9128kOhgQ=; b=v0PTBd44gp13a57CI15SEErAA90ULfmVQK9FnkTMJDg1YJJdOtdSO9tr3QM9Wuz6boGIKBl0xVWqG57TOeCE/7Te9XpjBINzE4D4RfJxbyk7mNTICe84853K2lS+qjFDr8GykDqqpsSiD5nDaN0HJ3jE/xfG3/QzjjhfNEcdD9I= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4333.namprd11.prod.outlook.com (2603:10b6:208:195::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.22; Mon, 13 Jul 2020 21:54:22 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18%5]) with mapi id 15.20.3174.025; Mon, 13 Jul 2020 21:54:22 +0000 From: "Rob Wilton (rwilton)" To: Don Fedyk , "netmod@ietf.org" Thread-Topic: [netmod] Comments on draft-ietf-netmod-sub-intf-vlan-model-05 Thread-Index: AdVvtb220WVlpvm3Rs2epRVdtzLyQTpqhNzw Date: Mon, 13 Jul 2020 21:54:22 +0000 Message-ID: References: <000801d56fb6$9d76fe90$d864fbb0$@labn.net> In-Reply-To: <000801d56fb6$9d76fe90$d864fbb0$@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: labn.net; dkim=none (message not signed) header.d=none;labn.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.15.79.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c6fb3fb9-fb62-4497-0820-08d827774d83 x-ms-traffictypediagnostic: MN2PR11MB4333: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LUY7Ylp/QsdjQF3uwaz1iwemkYqmy9z84fDJ5tEbiW20PpkrrfeJNwM8G7wrKzxSL5EOvlmZuZOxrNKVuqxCMyYfUTzZQ+wbQtjAQguA/XGSyLT9023izQTQrLacsII5MWLljeb4x4VxAnDRAjp5+UK/adISRWPhbr4gvCkxwkNrpoyO2i2twmhTJ45uQORT9JEzYv8wDAafyLFzbsMX/TIZs9wOMO+aUro25wYvJaS8yKohfUZyNh2H7G9v2b/e+9b6f8jzyZnfnVk+blCxNT4XDjw0p6t8RH2Zvl8fOSIgQtZoolmwBe/NZdFs2jCF8R28kiNXaa09uPD2tBi/Fb6LMnIkkVm4wkBh55ab/CpL+QPWGT/BLTNzHvt9z8Ku7z6hhgQi8HfqA3g47yrJhQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(396003)(39860400002)(366004)(346002)(8936002)(33656002)(5660300002)(7696005)(478600001)(166002)(83380400001)(966005)(86362001)(8676002)(2906002)(26005)(52536014)(9326002)(55016002)(6506007)(66556008)(110136005)(66446008)(66946007)(64756008)(66476007)(186003)(316002)(53546011)(9686003)(76116006)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: bs/3feIwAA8A4oZSCJiHs9SFLkln8NPwSoMXq13uYILBfSOgH0YG2/rFPk1FMDk4Bvka4FtVs9vXFw2WWyRWD/DoIqeX9H6d4mWb7KsEVK0QA/+c0kWuug1hzeBISDahEvDnL9fVlMg0qIceX22vJGi7JXOMWg3wbrZxru01cnZNX1Whrgh+xApZ8itmBdtkVI5BbRVpNW4KIT53xZ5LRe1wf7/bIuQ0r320szeGcMDavrcQSW6EbG56O+uqQfgn+Dy2dYWGDU5G2yImR459E/DA+aQxi+X6MpwkazOINTBnnrWH/Ly3UzzNqsKvKb7SIbnEKcj5g4xeVRm3kIVJ3gpFpJmJMv58zQ26/nTbLKFtopSzuQ40DOLbcQ+wAYSfdGZsds1I2iidFi/SQHEUIqoYh42c+vYFUIYEvQ4F3q0tzwoM+g5oaFJkwcw92RPVihimueYcErm5VpkwFrMx9IXaM8t0I6Ka1/1IWc9hxIM= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB436640579B8A35CD291453C8B5600MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c6fb3fb9-fb62-4497-0820-08d827774d83 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2020 21:54:22.5351 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Jy3erdKZ0cyGM37T3Y5z+u9TH5ihoQ+LRra/1jyYCUfem5CxU1AKA4gCBShTLjfEdyq3ut4IsWxkKoHVTkHIzg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4333 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [netmod] Comments on draft-ietf-netmod-sub-intf-vlan-model-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 21:54:54 -0000 --_000_MN2PR11MB436640579B8A35CD291453C8B5600MN2PR11MB4366namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Don, Apologies for being so slow to get back to you on these comments. As you are aware, I have added some examples to the document, and tweaked a= little bit of the introduction text to hopefully help make it a bit more c= lear about how this YANG module is used in conjunction with IP or L2VPN YAN= G models. If you have time, please can you take a look at the latest draft version (-= 07) https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/= to see if you think the text is sufficient, or further explanation is requ= ired? Regards, Rob From: netmod On Behalf Of Don Fedyk Sent: 20 September 2019 14:24 To: netmod@ietf.org Subject: [netmod] Comments on draft-ietf-netmod-sub-intf-vlan-model-05 Some comments on the draft : On the content of the draft L3 Section: Overall the draft assumes quite a bit of knowledge about L3 service configu= ration. I don't know where L3 service to interfaces in the IETF models. I= 'd guess it is routing to interfaces and IP forwarding based on routing but= if it is defined, pointers in the draft would help. From what I understan= d this draft allows a L3 service interface to terminate to an Ethernet with= any combination of 2 VLAN tags. The draft does not state it but I assume = this encapsulation is symmetric. (Symmetrical/Asymmetrical is only mention= ed for L2). Note the implied service context (what you get when you strip= the tags) allows for symmetric traffic . For L3 this is typically MPLS or= IP 5 tuple etc. On the layer 2 section: For the L2VPN case there is already a YANG file that describes the Service = VLAN tagging. I'm trying to figure you what your draft brings to this cas= e. It seems to me this draft allows (more) flexible tagging for the unqual= ified/unqualified learning VPNs. By allowing translation and possibly carr= ying more tags a single VLAN can carry more diverse traffic. However there= are subtleties in doing VLAN translation. Without examples of application= s I'm left guessing how this is intended to be applied. Also it is not as = easy for me to understand the service context as with L3 above. How do yo= u identify untagged traffic (or is it a tag swapping model?) In L2 VPNs the= classic case of qualified learning (also called independent VLAN learning = in IEEE) removes the (one) outer tag and carries the second tag in the MPLS= frame. The MPLS label stack is the context for the service. The second ta= g is assumed unique in the qualified domain. In Unqualified learning (or sh= ared VLAN learning) removing the one outer tag and means the possibility co= llisions in the second tag space - no unique context is maintained this is = where VLAN translation has typically been used. In both cases the second t= ag is not changed. One application of your draft implies to me that you su= pport he same models but the second tag can be changed. Can you support bot= h unqualified and qualified with the flexible tagging and does it change an= y of the established capabilities? Or something else? It would be really = great clarify. Some text on applicability with concrete L2VPN examples wo= uld help and what it offers over the current L2VPN Yang. Therefore my suggestion is that the draft say something to the effect that: * The draft is limited to the a port/service interface/access m= odel * The draft is agnostic to the full range of the Ethernet funct= ions that rely on the IEEE 802.1 component model. * The draft uses Ethernet compatible Tagging to allow bridging = in between endpoints or interworking with bridges in a with a subset functi= onality.* *Note the draft is adding some other functionally that is outside/alternati= ve to the IEEE 802.1 functions but it interworks with Ethernet on a subset. I think you do have to revisit some the language around compatibility with = compliant bridges with respect to the above points. Best regards Don --_000_MN2PR11MB436640579B8A35CD291453C8B5600MN2PR11MB4366namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Don,

&nbs= p;

Apologies= for being so slow to get back to you on these comments.<= /p>

&nbs= p;

As you ar= e aware, I have added some examples to the document, and tweaked a little b= it of the introduction text to hopefully help make it a bit more clear abou= t how this YANG module is used in conjunction with IP or L2VPN YANG models.

&nbs= p;

If you ha= ve time, please can you take a look at the latest draft version (-07) https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf= -vlan-model/ to see if you t= hink the text is sufficient, or further explanation is required?

&nbs= p;

Regards,<= br> Rob

&nbs= p;

&nbs= p;

From: netmod <netmod-bounces@ietf.org> On Behalf Of Don Fedyk
Sent: 20 September 2019 14:24
To: netmod@ietf.org
Subject: [netmod] Comments on draft-ietf-netmod-sub-intf-vlan-model-= 05

 

Some comments on the draft :

 

On the content of the draft L3 = Section: 

Overall the draft assumes quite= a bit of knowledge about L3 service configuration.  I don’t kno= w where L3 service to interfaces in the IETF models.  I’d guess = it is routing to interfaces and IP forwarding based on routing but if it is defined, pointers in the draft would help.  From what I = understand this draft allows a L3 service interface to terminate to an Ethe= rnet with any combination of 2 VLAN tags.  The draft does not state it= but I assume this encapsulation is symmetric.  (Symmetrical/Asymmetrical is only mentioned for L2).   Not= e the implied service context (what you get when you strip the tags) allows= for symmetric traffic . For  L3 this is typically MPLS or IP 5 tuple = etc.

 

On the layer 2 section:  <= o:p>

For the L2VPN case there is alr= eady a YANG file that describes the Service VLAN tagging.   IR= 17;m trying to figure you what your draft brings to this case.  It see= ms to me this draft allows (more) flexible tagging for the unqualified/unqualified learning VPNs.  By allowing translation and p= ossibly carrying more tags a single VLAN can carry more diverse traffic.&nb= sp; However there are subtleties in doing VLAN translation.  Without e= xamples of applications I’m left guessing how this is intended to be applied.  Also it is not as easy for me to understa= nd the service context as with L3 above.   How do you identify un= tagged traffic (or is it a tag swapping model?) In L2 VPNs the classic case= of qualified learning (also called independent VLAN learning in IEEE) removes the (one) outer tag and carries the second = tag in the MPLS frame.  The MPLS label stack is the context for the se= rvice. The second tag is assumed unique in the qualified domain. In Unquali= fied learning (or shared VLAN learning) removing the one outer tag and means the possibility collisions in the sec= ond tag space – no unique context is maintained this is where VLAN tr= anslation has typically been used.  In both cases the second tag is no= t changed.  One application of your draft implies to me that you support he same models but the second tag can be changed. C= an you support both unqualified and qualified with the flexible tagging and= does it change any of the established capabilities?  Or something els= e?  It would be really great clarify.   Some text on applicability with concrete L2VPN examples would help and wha= t it offers over the current L2VPN Yang.

 

 

Therefore my suggestion is that= the draft say something to the effect that:

•    =          The draft is limited to th= e a port/service interface/access model

•    =          The draft is agnostic to t= he full range of the Ethernet functions that rely on the IEEE 802.1 compone= nt model.

•    =          The draft uses Ethernet co= mpatible Tagging to allow bridging in between endpoints or interworking wit= h bridges in a with a subset functionality.*

 

*Note the draft is adding some = other functionally that is outside/alternative to the IEEE 802.1 functions = but it interworks with Ethernet on a subset.

I think you do have to revisit = some the language around compatibility with compliant bridges with respect = to the above points.

 

 

Best regards<= /p>

Don

--_000_MN2PR11MB436640579B8A35CD291453C8B5600MN2PR11MB4366namp_--