[netmod] Comments on draft-ietf-netmod-sub-intf-vlan-model-05
"Don Fedyk" <dfedyk@labn.net> Fri, 20 September 2019 13:24 UTC
Return-Path: <dfedyk@labn.net>
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 139001200C3 for <netmod@ietfa.amsl.com>; Fri, 20 Sep 2019 06:24:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.625
X-Spam-Level:
X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 AJu0irS5i3Sg for <netmod@ietfa.amsl.com>; Fri, 20 Sep 2019 06:23:58 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (outbound-ss-348.hostmonster.com [74.220.202.212]) (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 328F5120024 for <netmod@ietf.org>; Fri, 20 Sep 2019 06:23:58 -0700 (PDT)
Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 00ABB1E08BE for <netmod@ietf.org>; Fri, 20 Sep 2019 07:23:39 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id BIssi5Rc3awnoBIssiLd6Q; Fri, 20 Sep 2019 07:23:38 -0600
X-Authority-Reason: nr=8
X-Authority-Analysis: v=2.3 cv=V9xTL9vi c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=DAwyPP_o2Byb1YXLmDAA:9 a=G5z4KiUBrY_248OUbIQA:9 a=byM0q-JwBf9Ob5qq:21 a=QQwHU-k5PcfrtbK8:21 a=x-TTg3k61sHEMACEjG8A:9
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=RHVFMHImGgDs/Rrp7E7yRqkgw5n+YWjQXR+39NDFl98=; b=BjnI4LJg1I3Df6M9KADUREtbDM eiw+zbiCtik8tPFDYMQttC5NntPUpWn5uaEhdZsS2RNwovfWCqM0WwJPH/4Tbo5/trV4xAryD0ksH nE9oQGHg8EZqvx8IWYaN16UQl;
Received: from [109.144.218.212] (port=12737 helo=FedykLabn) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <dfedyk@labn.net>) id 1iBIss-002hIH-EK for netmod@ietf.org; Fri, 20 Sep 2019 07:23:38 -0600
From: Don Fedyk <dfedyk@labn.net>
To: netmod@ietf.org
Date: Fri, 20 Sep 2019 09:23:36 -0400
Message-ID: <000801d56fb6$9d76fe90$d864fbb0$@labn.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01D56F95.166621E0"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdVvtb220WVlpvm3Rs2epRVdtzLyQQ==
Content-Language: en-us
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 109.144.218.212
X-Source-L: No
X-Exim-ID: 1iBIss-002hIH-EK
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: (FedykLabn) [109.144.218.212]:12737
X-Source-Auth: dfedyk@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/1gnxfg-WEbhe36qmMNVEqJ2UC9g>
Subject: [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 <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Sep 2019 13:24:00 -0000
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 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 understand 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 mentioned 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 case. It seems to me this draft allows (more) flexible tagging for the unqualified/unqualified learning VPNs. By allowing translation and possibly carrying more tags a single VLAN can carry more diverse traffic. However there are subtleties in doing VLAN translation. Without examples of applications 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 you 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 tag is assumed unique in the qualified domain. In Unqualified learning (or shared VLAN learning) removing the one outer tag and means the possibility collisions in the second tag space - no unique context is maintained this is where VLAN translation has typically been used. In both cases the second tag is not changed. One application of your draft implies to me that you support he same models but the second tag can be changed. Can you support both unqualified and qualified with the flexible tagging and does it change any of the established capabilities? Or something else? It would be really great clarify. Some text on applicability with concrete L2VPN examples would 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 model . The draft is agnostic to the full range of the Ethernet functions 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 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 Don
- [netmod] Comments on draft-ietf-netmod-sub-intf-v… Don Fedyk
- Re: [netmod] Comments on draft-ietf-netmod-sub-in… Rob Wilton (rwilton)
- Re: [netmod] Comments on draft-ietf-netmod-sub-in… Don Fedyk