[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