[ieee-ietf-coord] Notes from the 2018-11-09 IETF-IEEE 802 Coordination Meeting, Bangkok

Cindy Morgan <cmorgan@amsl.com> Fri, 09 November 2018 02:21 UTC

Return-Path: <cmorgan@amsl.com>
X-Original-To: ieee-ietf-coord@ietfa.amsl.com
Delivered-To: ieee-ietf-coord@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4B5031288BD for <ieee-ietf-coord@ietfa.amsl.com>; Thu, 8 Nov 2018 18:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Ks_c4SxeU6un for <ieee-ietf-coord@ietfa.amsl.com>; Thu, 8 Nov 2018 18:21:12 -0800 (PST)
Received: from mail.amsl.com (c8a.amsl.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5B7124D68 for <ieee-ietf-coord@ietf.org>; Thu, 8 Nov 2018 18:21:12 -0800 (PST)
Received: from localhost (localhost []) by c8a.amsl.com (Postfix) with ESMTP id 67A2A1C35F7 for <ieee-ietf-coord@ietf.org>; Thu, 8 Nov 2018 18:20:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([]) by localhost (c8a.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8jnGu3XqYYYy for <ieee-ietf-coord@ietf.org>; Thu, 8 Nov 2018 18:20:56 -0800 (PST)
Received: from dhcp-8840.meeting.ietf.org (dhcp-8840.meeting.ietf.org []) by c8a.amsl.com (Postfix) with ESMTPSA id ED6A61C2DBA for <ieee-ietf-coord@ietf.org>; Thu, 8 Nov 2018 18:20:54 -0800 (PST)
From: Cindy Morgan <cmorgan@amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <5965E45B-0796-4AB3-BA45-11B77368240A@amsl.com>
Date: Fri, 9 Nov 2018 09:21:06 +0700
To: "<ieee-ietf-coord@ietf.org>" <ieee-ietf-coord@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ieee-ietf-coord/SFkXIst3VnR9ILDcn74wy7NZrhY>
Subject: [ieee-ietf-coord] Notes from the 2018-11-09 IETF-IEEE 802 Coordination Meeting, Bangkok
X-BeenThere: ieee-ietf-coord@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Management-level discussions between IEEE and IETF on topics of interest to both SDOs <ieee-ietf-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ieee-ietf-coord>, <mailto:ieee-ietf-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ieee-ietf-coord/>
List-Post: <mailto:ieee-ietf-coord@ietf.org>
List-Help: <mailto:ieee-ietf-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ieee-ietf-coord>, <mailto:ieee-ietf-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Nov 2018 02:21:15 -0000

2018-11-09 IETF-IEEE 802 Coordination Meeting, Bangkok


- Lou Berger
- Deborah Brundard
- Benoit Claise 
- Alissa Cooper
- Spencer Dawkins
- Donald Eastlake
- Janos Farkas
- Ted Hardie
- Russ Housley
- Suresh Krishnan
- Warren Kumari
- Scott Mansfield
- Cindy Morgan
- Paul Nikolich
- Erik Nordmark
- Eric Rescorla
- Jon Rosdahl
- Dorothy Stanley
- Jeff Tantsura
- Pascal Thubert
- Gunter Van de Velde
- Eric Vyncke
- Peter Yee
- Juan Carlos Zuniga
- Robert Wilton

	a.      yangcatalog.org update – Eric

Eric: You have already seen the yangcatalog.org site in previous meetings where IETF and other SDOs can upload their YANG models, and we have a lot of tools that are around those YANG models. Worked on it in the IETF Hackathon to transition it to IETF tools, move the backend. Once you are there, we have a catalog of tools and a place where you can learn how to apply your own models. You have a search engine that can search all the models and where you are searching. It give you many models. In the search part, you can search for IEEE and find about 75 models, and you see they are from. The model and the impact, this module has been used by other modules or is using other modules. If you go into the web interface you can see who is doing what and access directly through GitHub the models, and the description. We can also see a link to how many warnings you get when you do validation. About 4 different tools to check the simplex of the YANG models. If I go to the tree, you can see a preview to find all of the leaves. All of the information you can find by search is what will impact how the module is used and see the links between the interfaces. What you can do as well is to go to another page which is where you can prepare requests. 

[Live walk-through of website]

Benoit: Most of the work has been in the background, but we have some questions to IEEE. We put some stuff in GitHub, and we want to know if we're up to date in GitHub with IEEE. And on some there is some data we can't extract. We would like to have the metadata populated.

Scott: The short answer is that it is up to whether or not the editors of the YANG modules have actually uploaded them. From looking at it before this meeting, it looks like a number of them have been uploaded for consideration at this meeting. We can talk about how we want the structure to be for IEEE. And I haven't been putting the metadata in the system yet, so there is still some work to do in the YANG repository to support the YANG catalog. 

Benoit: Do you need any help? 

Scott: One thing we've been doing is we've had a couple of people who have been checking for compiling errors and the way it works in that regards, it seems to be working fine. It's just a matter of herding the cats and getting them to put the things in that need to be done.

Russ: This started as a grassroots effort, and the community in the IETF has found it very helpful, and it's become part of our critical structure, and our Secretariat is going to take over management of it early next year, so this is really part of our infrastructure now.

Scott: There are a couple of issues, and one of them is that the use of the YANG catalog has nothing to do with the technology and everything to do with the intellectual property. We've been working with IEEE legal and we have a set of text that we must include. The IEEE people working on the modules absolutely love the fact the we have a GitHub repo to share the information with all of the other groups, MEF, ITU-T. We're at a point where the IEEE has approved a doc with a YANG module in it, and we're still in the process of negotiating how we structure the repository so that we can have a published part and a draft thing. These are the things we've been going around about. Trying to get people used to using it, and keeping the pressure on the IEEE to allow us to use it, because people are finding it extremely helpful.

Russ: We went through some of this with MIB modules, is the difference that you only ever got those when the module was final.

Scott: Yes. And the people that care about process in the IEEE is that the only YANG module that matters is the one in the published PDF document. If there is any disagreement, it is the one in the doc. But it is such a huge pain to pull them out of the docs. One selling point for me is it is easy to say this module is in the spec and go.

Benoit: You mention that you like that it is GitHub. We made sure it's not a YANG repo. We have a link to whatever you put, we are not there to distribute the YANG modules.

Scott: That is correct.

Benoit: What we have now is supported by the Tools Team. We knew who were supporting the YANG catalog, and there is a tracker of who is solving issues. 

	b.      IEEE 802 YANGSTERS – Scott

Scott: The thing that is important to understand is there is a web presence, and on that website that you can find from the .1 page is all of the notes that we've been talking about. We've had 15 official meetings and you'll find the meeting notes. At this meeting, I'll try to predict the future, and if you want to find information about the YANGSTERS cause. We have 2 calls a month. One that is coordination within 802, and there are a number of topics, including guidelines development. Looking at what MEF, ONF, IETF are doing in terms of YANG guidelines. Something that we've already been trying to get around are naming conventions. I created a thing that says this is how we'd like them named so that a module written in .1 looks like one in .3, etc. We also hold a YANGSTERS meeting at the IEEE face to face meeting. Are there some documentation and training we can provide to make the YANG catalog easier to use.

Jeff: For the last two years in routing area meetings I've been trying to get people to learn how to use YANG. We have recordings I can send you.

Scott: That would be great.

Jeff: At this one we have open source tooling.

Scott: It's kind of a training area for people who might not know what YANG is. And the sensitivity that the IEEE has about the standards process, so we need to make sure that we don't violate anything by trying to use these tools in the IEEE. 

Benoit:  We are reaching a new level with this and you were mentioning how to populate the metadata, and you can't just be changing things in the hackathon. 

Scott: Something I spend a lot of time on is coordinating with other standards bodies and we are getting the word out on how to use this. It's a matter of keeping the momentum and getting the information out. 

Alissa: There is a mailing list for announcement, is it a broadcast list? Does the wider community know about it.

Benoit: Not sure how many people who are subscribed, but we can check. 

Robert: You mentioned that the master copy would be in the spec itself, but what about bug report process?

Scott: Looking for a process on that, thank you for volunteering.

Benoit: I believe there is also an issue to discuss on IEEE.

Rob: There is an item I'm trying to do in NETMOD, asked to bring it to the 802.1 community, and I've discussed it with John Messenger and Janos. I can't go to the IEEE next week but Lou will be there and I can give him a couple of slides to present it so we can get it sorted out. 

2) Information item: 

- IEEE ICAID: https://standards.ieee.org/industry-connections/
- https://standards.ieee.org/industry-connections/icsg/index.html and Encrypted Traffic Inspection WG https://standards.ieee.org/industry-connections/icsg/eti.html

Dorothy: This is to make sure you're aware that the IEEE has an industry connections set of activities. If you go to the website, this is what you'll see. These are pre-standard activities for people to get together and address a topic. Top level, there are a bunch of these activities including an industry connections security group. This is where work has moved related to encrypted traffic inspection work. I don't want to throw red meat in front of the lions, but I don't have an update on the progress of the group. 

EKR: There's not much there. It's not detailed. How would we, some of the various things I've seen floating in this space are perhaps not good. How do we find out what is going on and provide input?

Dorothy: An ICAID activity is not standards input, but you can send email to Olaf.

Russ: He's not answering.

EKR: It would be helpful to get a report out from these activities. 

Paul: I think we should get IEEE staff to identify who is doing what in each group, but that is the POC I'd reach out to.

Dorothy: I will take the action to follow up. I did ask Jodi Haasz before and she had no info. I'll ping again and put any info to the list.

3) Link State over Ethernet

Gunter: A lot of the routers have a very high degree of connectivity, tens or hundreds of thousands of routers. New router technologies are in the process of being developed, and one is link state routing. A WG was chartered about a year ago, morph topological aspects into a BGP technology. How we introduce SPF. What you see if very typical, some routes in the network environment and each creates its own link state packet. We are reusing existing technology, but we have discovered that we need to figure out who is a neighbor, who am I, and we don't have to do thins manually. Looking at the different technologies out there. We need a market analysis on what is available. What we need is technology we can understand and provide us with the right hooks so BGP can be established. Data center has lots of devices and the more complex it becomes. Looking into that the initial first was LLDP, so we were looking into. If we look into the simplicity of link state vector routing, it's a pretty good fit. There is high potential that the size of the packets will be bigger than one single frame on the internet and it becomes more complicated as a result. So we looked at designing something new, very simple, tailored to this. So this would be like a new layer 2 neighbor discover technology. In the link state vector routing WG, we are now in process of link state over ethernet, so if it will be adopted it will be part of link state vector routing. It is a simple protocol, and then you start exchanging some of the information attributes. Everything is TLV based going forward. May be a need for a new ethertype for his. Understanding what the different procedures are that are involved and working with IEEE to develop the right tools to make this technology a reality. There will be a more technological update on this in tomorrow's data center part of the efforts. This is just a quick heads up.

Janos: I see HELLO at the top?

Gunter: Not ISIS, but directly on top of ethernet.

Janos: Have you looked at []? Because I think we have everything in there.

Gunter: We have analyzed everything out there and nothing quite met all of our requirements.

Suresh: Is LLDP a carrier for this?

Gunter: We were thinking about using LLDP but it has a lot of additional packets attached to it. You are stopping to other issues.

Jeff: We started this effort about 3 years ago and had a BOF when there were already 4-5 proposals on the table that led to 2 new WGs. Layer 2 and 3 with BGP. There is a lot of work going on; some of it will be covered tomorrow. 

Suresh: If you already did the study and said why things aren't suitable, if you put them in the doc that would be helpful for the future.

Janos: Have you sent a liaison on this to 802.1?

Gunter: This is the first time we've reached out, but it will come. Learning how to initiate in the most appropriate way. 

Dorothy: I think this is a good example of the usefulness of these meetings, to thank you for this, Gunter. 

4) Pre-bar BOF re: Predictable and Available Wireless

Dorothy: This is based on work that occurred this week, organized by Pascal Thubert. This was held yesterday and was well-attended. Will presented in .11 next week.

Pascal: This relates to 6tisch, which does IPv6 over deterministic back, 802.15.4. The other is an IEEE effort which may provide capability to do something similar, in which case 6tisch would be portable over wifi. 6tisch never worked on the "deterministic" wireless. 6tisch would be the IPv6 best effort.

Slides:  https://www.dropbox.com/s/mdwsny81sp7g317/pthubert-paw.pdf?dl=0 

5) Informal 802.11 member feedback on https://tools.ietf.org/html/draft-friel-brski-over-802dot11-01 

Dorothy: There is an informational, individual (not working group) doc called brski-over-802dot11. There was some informal feedback to the authors this week and I think it was productive and there will be other conversations ongoing. As a doc that called out 802.11 directly I wanted to make sure people were aware of it. 

6) Other Business

Suresh: I have 2 things for the coordination list, and will send email. 

7) Review of Saturday and Sunday agenda

[Reviewed agenda for Saturday and Sunday meetings]