Subject: [ieee-ietf-coord] Robert Wilton's report from the IEEE 802.1 interim meeting (was: FW: remotely attending the YANG session in Budapest)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 26 May 2016 10:36:22 +0000

A report from Robert Wilton who attended the IEEE 802.1 interim meeting in order to present the VLAN YANG data model I-Ds and discuss with the IEEE experts about the compatibility of this work with the IEEE 802.1 standards. Thanks to Robert for making the trip and for the report.

Regards,

Dan

From: Robert Wilton [mailto:[email-masked]]
Sent: Wednesday, May 25, 2016 7:02 PM
To: Glenn Parsons; Romascanu, Dan (Dan); Lou Berger; Benoit Claise (bclaise); Eric Gray; Kent Watsen; Michael Johas Teener; Janos Farkas; John Messenger
Subject: Re: remotely attending the YANG session in Budapest

Hi All,

I've tried to write up my understanding of the comments and mood of the 802.1 WG regarding my proposal draft.  Sorry, but I wasn't able to capture everything, so if you think that I have missed or misrepresented any key points then please feel free to correct or annotate my statements below.

1) There is a very clear and strong feeling that any IETF VLAN YANG model must inter-operate cleanly with 802.1Q.  I see that this is a valid concern and I think one that we should address:

1 a) One particularly strong concern is to ensure that tags are always matched/inserted/used in the right order.  I.e. for a double tag match ensure that the other tag is an s-vlan tag, and the inner tag is a c-vlan tag.  From several people I've spoken to, this seems to be their fundamental objection to the model and resolving this would potentially go a long way towards making this model acceptable.  It should be straight forward to implement these constraints using must statements, and I'll look at updating the model to reflect this.

2) There is a concern that the proposed model may potentially fundamentally violate the 802.1Q architecture:

2 a) In particular, it was pointed out at various times that a 802.1Q tag is not just a delimiter on traffic (as it is being used is some of the SP and subscriber related use cases) but represents protocol operations instead.  I.e. there is a concern that VLAN tags are being misused.  In the shorter term, I cannot see how this can really be addressed.  One long term solution could be to define a separate "mux/demux tag type" using its own Ethertype.  Its unclear to me whether there is any real desire to spend time defining this now, and the fact that it wouldn't inter-operate with 802.1Q bridges would seemingly make it less useful.

2 b) Mick Seaman doesn't seem to really agree with the sub-interface model and thinks that an alternative model would be better, although it is unclear exactly what that alternative model would look like.  I'll try and discuss this further with him if he is available.

3) There didn't seem to be consensus as to whether 802.1Q formally defines a host stack for inter-operating with a 802.1Q bridge (specifically VLAN-aware end stations).  There has been some opinion expressed that this may be missing from 802.1Q and that should possibly be added.  If this was done, and included a manageability interface then this would potentially overlap with the L3 part of my proposed model.

4) A concern was expressed that allowing more flexible classification might put undesired pressure on 802.1Q to develop new features (e.g. as QinQ historically did).  Given that the configuration supported by my proposed model is to support features and protocols that were standardized 10+ years ago I'm not sure that I see defining a common configuration model for those features now would add any significant additional pressure now.

5) A concern was expressed that the model should only allow for configurations that can be reasonably efficiently implemented in hardware.   I believe that this is already the case - given that the model is already implemented in hardware by multiple device and silicon vendors.

6) There was a suggestion that the WG might be more comfortable if the draft was marked as experimental or informational.  I personally don't think that marking it as informational would be appropriate, but possibly experimental could be used.

At the end of the meeting, I was thanked for attending and presenting at the IEEE interim and the 802.1 WG understood and appreciated the desire to produce a standard that is acceptable to the 802.1 WG.  I would also like to thank the 802.1 WG for giving me the time and opportunity to present.

Thanks,
Rob