Re: [netmod] [802.1 - 12909] IETF Sub-interface VLAN YANG Data Models - draft-ietf-netmod-sub-intf-vlan-model-04

John Messenger <jmessenger@advaoptical.com> Tue, 13 November 2018 04:55 UTC

Return-Path: <jmessenger@advaoptical.com>
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 23B84126F72 for <netmod@ietfa.amsl.com>; Mon, 12 Nov 2018 20:55:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 kn_i27QTblUS for <netmod@ietfa.amsl.com>; Mon, 12 Nov 2018 20:55:35 -0800 (PST)
Received: from mail2.advaoptical.com (mail2.advaoptical.com [91.217.199.72]) (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 16FDA124408 for <netmod@ietf.org>; Mon, 12 Nov 2018 20:55:34 -0800 (PST)
Received: from MUC-S-EX16D.advaoptical.com ([172.20.1.28]) by muc-vs-fsmail2.advaoptical.com (8.16.0.22/8.16.0.22) with ESMTPS id wAD4tQv1023851 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=FAIL); Tue, 13 Nov 2018 05:55:26 +0100
Received: from MGN-S-EX16B.advaoptical.com (172.25.1.192) by MUC-S-EX16D.advaoptical.com (172.20.1.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1591.10; Tue, 13 Nov 2018 05:55:25 +0100
Received: from MGN-S-EX16B.advaoptical.com ([fe80::c022:bed0:3eb:b5c5]) by MGN-S-EX16B.advaoptical.com ([fe80::c022:bed0:3eb:b5c5%7]) with mapi id 15.01.1591.008; Tue, 13 Nov 2018 05:55:25 +0100
From: John Messenger <jmessenger@advaoptical.com>
To: Robert Wilton <rwilton@CISCO.COM>, Lou Berger <lberger@labn.net>, "Holness, Marc" <mholness@ciena.com>, "STDS-802-1-L@LISTSERV.IEEE.ORG" <STDS-802-1-L@LISTSERV.IEEE.ORG>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [802.1 - 12909] IETF Sub-interface VLAN YANG Data Models - draft-ietf-netmod-sub-intf-vlan-model-04
Thread-Index: AQHUdOi9tjNIF+LjDU2pKDc3UZOkWaVNIrng
Date: Tue, 13 Nov 2018 04:55:25 +0000
Message-ID: <9485c56783074f19b4fbf357e5e82946@advaoptical.com>
References: <14a5c6fd-b24a-9669-7701-75dd822f95e2@cisco.com>
In-Reply-To: <14a5c6fd-b24a-9669-7701-75dd822f95e2@cisco.com>
Accept-Language: en-GB, de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.20.1.231]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-13_03:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/b1qMztDgg0xQEksZ1lRweWdWjSw>
Subject: Re: [netmod] [802.1 - 12909] IETF Sub-interface VLAN YANG Data Models - draft-ietf-netmod-sub-intf-vlan-model-04
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: Tue, 13 Nov 2018 04:55:38 -0000

Hi,

At the 802.1 TSN meeting this morning, Lou Berger made a presentation on behalf of Rob Wilton summarising the recent changes in this draft.  I like the changes to the structure which are intended to align the VLAN tag structure to that specified in 802.1Q.  I notice that the draft retains clause 2.2 (Extensibility) but I think that's a bug, because it's not reflected in the model (which is a fixed structure of one or two tags).

Right now, it says that the Ethertypes are taken from dot1q-tag-type.  Would this allow tags other than 802.1QTagType (81-00) and 802.1QSTagType (88-A8)?  That shouldn't be allowed.

My preference would be to remove the forward-looking statement quoted here because it implies a willingness to extend to 3 tags:
	The structure of the model is currently limited to matching or
   rewriting a maximum of two 802.1Q tags in the frame header but has
   been designed to be easily extensible to matching/rewriting three or
   more VLAN tags in future, if required.

It looks like you could parse an untagged frame as either :(untagged) or :(dot1q-vlan-tagged) (without either of the optional tags).  Is that a bug?

Thanks,
	-- John 

-----Original Message-----
From: List HELP only <hdk.1-oeyo8vs4@hjkeen.net> On Behalf Of Robert Wilton
Sent: 05 November 2018 16:16
To: STDS-802-1-L@LISTSERV.IEEE.ORG
Subject: [802.1 - 12909] IETF Sub-interface VLAN YANG Data Models - draft-ietf-netmod-sub-intf-vlan-model-04

Ballot due Nov. 6: P802.1Qcx/D0.4
For particulars see
  https://1.ieee802.org/active-ballots/
802.1 list help: https://1.ieee802.org/email-lists/
List archives (access-controlled) by date:
               www.ieee802.org/1/private/email2/mail1.html
-----

Dear esteemed 802.1 WG members,

A few years back, at the start of my IETF and IEEE standards journey I wrote a draft defining a sub-interface based VLAN termination YANG model.  After discussion and presentations in both IETF NETMOD WG and IEEE 802.1 WG, there was a general agreement that it would be acceptable for IETF to publish this YANG model as an informational RFC, with the acknowledgement that 802.1Q VLAN technology is owned by IEEE, and in future the IEEE 802.1 WG may choose to publish a VLAN termination model.

As part of that IETF NETMOD WG process, and after IEEE 802.1 WG had reviewed the model, I made a small change in structure of the YANG model with the sole aim of making the model simpler to use. In particular, the older model required a slightly clunky indexed list of VLAN tags, and that is replaced with a simpler structure supporting two explicit named VLAN tags ('outer-tag' and 'second-tag').  A while back, Glenn requested that I pass these changes by the IEEE 802.1 WG to ensure that the changes are acceptable to the IEEE 802.1 WG, hence this email.

The change is perhaps best illustrated via the following change in the YANG tree output.

The*older format* of the YANG model (that members of the 802.1Q WG previously saw) was like this:

*if-cmn:encaps-type: +--:(vlan) +--rw vlan +--rw tags +--rw tag* [index] 
+--rw index uint8 +--rw dot1q-tag +--rw tag-type dot1q-tag-type +--rw
vlan-id dot1q-vlan-id*

The *updated format *of YANG model in the current draft is like this:

        +--:(dot1q-vlan)
           +--rw dot1q-vlan
              +--rw outer-tag!
              |  +--rw tag-type    dot1q-tag-type
              |  +--rw vlan-id     ieee:vlanid
              +--rw second-tag!
                 +--rw tag-type    dot1q-tag-type
                 +--rw vlan-id     ieee:vlanid

The same equivalent change has been made for L2 sub-interfaces as well.

The latest internet draft is 
https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-04

In particular, it may also be useful to look at the instance data 
examples in chapter 7, that give a couple of examples of how the YANG 
model is expected to be used both for L3 termination, and also when used 
in conjunction with the IETF L2VPN YANG model to provision a 
point-to-point L2 service.

I hope to submit this draft to the NETMOD WG chairs for WG last call 
after the current IETF 103 meeting.  So if anyone has any concerns then 
please may I ask that you raise them.  ideally I would like to get them 
informally addressed before this document progresses.  Alternatively if 
you need more time to review this change, or need this as a formal 
liaison then please let me know, and I'll do my best.

Thank you for your time,
Rob Wilton


===
Unsubscribe link: mailto:STDS-802-1-L-SIGNOFF-REQUEST@LISTSERV.IEEE.ORG
IEEE. Fostering technological innovation and excellence for the benefit of humanity.