IAB, IESG and IEEE 802 Executive Committee Minutes of the 15 July 2017 Meeting, Prague Reported by: Cindy Morgan (IAB Executive Administrative Manager) ATTENDEES ------------------- Jari Arkko Alia Atlas Ignas Bagdonas Deborah Brungard Ben Campbell Benoit Claise Joe Clarke Subir Das Donald Eastlake János Farkas Norman Finn Eric Gray Jodi Haasz Ted Hardie Bob Heile Russ Housley Mahesh Jethanandani Suresh Krishnan Warren Kumari Cindy Morgan Erik Nordmark Glenn Parsons Alvaro Retana Dan Romascanu Jon Rosdahl Dorothy Stanley Jeff Tantsura Pat Thaler Pascal Thubert Yan Zhuang MINUTES ------------------- 1. YANG Catalog Benoit Claise described the work on the YANG catalog . There are more than 2000 modules in the catalog, but they still need tooling for the operators, as well as the metadata. Joe Clarke added that the goal is to provide a tool chain. All of the code that has been contributed is open source. Improvements to the metadata are still in progress. Dorothy Stanley asked what the process is for tracking changes over time. Joe Clarke replied that vendors or standards developers can see the maturity level at any time, as well as when it was ratified. Rather than serving local copies of the modules, they will have pointers to the canonical places from where to download the modules. There is a draft in NETMOD that defines the catalog schema. Benoit Claise said that the next steps include working with the IEEE to add their YANG models to the catalog. Benoit and Glenn Parsons will coordinate offline about how to best handle this; IEEE 802 recently formed a YANG coordination group to coordinate internally on their YANG modules. 2. 48-bit and 64-bit MAC Addresses Interworking Bob Heile reported that he is investigating interworking between 48- bit and 64-bit MAC addresses and whether that is something that should be worked on. Norman Finn noted that there have been joint meetings in 802.1 and 802.15 that have discussed various aspects of this and concluded that bridging here does not actually solve the problems. Pascal Thubert added that IPv6 unicast connectivity over a multilink subnet is now done, and the documents are close to Last Call in 6LO. The registration mechanism enables us to proxy the IPv6 neighbor discovery mechanism. This is the Layer 3 equivalent of the Layer 2 association. As far as IETF is concerned this piece is solved. Pat Thaler said it is solved enough that they do not want to pursue a pure Layer 2 solution. With the ability to use the local address space, the problem is now the differences in behavior that break the expectations of protocols. Bob Heile concluded that it sounds like there is consensus to take this item off the work list. 3. Network Slicing Deborah Brungard reported that the NETSLICING BOF will be held on Monday during IETF 99, adding that the topic is also being discussed from a network point of view in the TEAS and DETNET WGs. Russ Housley asked what the overlap between the IETF and IEEE is for this work. Pat Thaler replied that there are three technologies dividing up use of the network for different clients. Janos Farkas added that network slicing also comes up in 3GPP. Ted Hardie noted that some folks from 3GPP will be talking about 5G in general during a Tuesday lunchtime session at IETF 99. 4. Breakout: Where is collaboration needed for Security? Russ Housley said that the network inside automotive is becoming a hot topic. Security is an important requirement within that, but so far no new requirements have been identified. Pat Thaler said that the topic has been discussed in 802.1 as well. Russ noted that opportunistic wireless encryption was published as an RFC and is being widely deployed, TLS 1.3 is close to wrapping up, and EAP TLS is being widely used in many places. Dan Harkins will review the new TLS versions to make sure that they don't mean any changes to the EAP methods. 5. Breakout: Where is collaboration needed for IoT? Pat Thaler asked how much of the work on IoT needs coordination between the IETF and IEEE 802. The IETF has an IoT directorate, and IEEE-SA has an IoT steering committee to look at things on a high level. Suresh Krishnan and Jon Rosdahl will coordinate from their respective sides, with Jodi Haasz sending an introductory email. IETF and IEEE 802 are already collaborating in some IoT-related areas (e.g. DetNet, TSN, 802E privacy). Pat Thaler asked whether the link layer in MUD should include encryption; Ted Hardie replied that he would talk to Eliot Lear about that. Pat noted that there should be some work on the tension between providing a secure identity and protecting privacy 6. Time-sensitive Networking/DETNET Norm Finn updated the group on IETF DetNet and IEEE 802.1 Time- Sensitive Networking. Slides: https://www.iab.org/wp-content/IAB-uploads/2013/01/slides-99-ieeeietfcoord-detnet-tsn-update-01.pptx Janos Farkas noted that there will be a tutorial on IEEE 802.1 Time- Sensitive Networking on Sunday during IETF 99. 7. 5G Glenn Parsons updated the group on the IEEE 802 EC 5G / IMT-2020 Standing Committee. Slides: https://www.iab.org/wp-content/IAB-uploads/2013/01/ec-16-0119-01-5GSG-report-ieee-802-ec-5g-imt-2020-sc.pptx Dorothy Stanley noted that IEEE 802 has requests for specific metrics to support the work they are doing to integrate 802.11. The goal is that in a 5G system, the radio tech is another peering technology. Jeff Tantsura said that the IETF NETSLICING BOF has a number of use cases identified, and hopes that 3GPP will be able to help with this. The new use cases are using EAP for authentication. There has been a lot of work in the Routing Area on the data model. They are also looking into SDN and using a packet network for transport. IETF also has related work in I2RS, NETMOD, NETCONF, and TEAS. There is also a lot of work happening in the SPRING WG around 5G concepts, on how to provide a set of resources. None of this has been explicitly asked for by 3GPP, but it is work the IETF assumed they would need. It has also been discussed in DETNET, TEAS, ACTN, and QUIC. Glenn Parsons noted that there has been no formal request from 3GPP, but the latest release had a lot of IETF dependencies, and asked if that was expected to happen again. Russ Housley replied that the communications with 3GPP started out informally and got more formal as they were closer to shipping; it may happen that way again with 5G. Suresh Krishnan added that 3GPP has changed how they track dependencies with the IETF. Georg Mayer is the current contact from 3GPP. 8. FlexE Deborah Brungard updated the group on FlexE (Flexible Ethernet), a protocol published by the OIF. Slides: https://www.iab.org/wp-content/IAB-uploads/2013/01/FlexE-at-IETF.pdf Per the OIF Flex Ethernet Implementation Agreement : "The Flex Ethernet (FlexE) implementation agreement provides a generic mechanism for supporting a variety of Ethernet MAC rates that may or may not correspond to any existing Ethernet PHY rate. This includes MAC rates that are both greater than (through bonding) and less than (through sub0rate and channelization) the Ethernet PHY rates used to carry FlexE. This can be viewed as a generalization of the Multi-Link Gearbox implementation agreements, removing the restrictions on the number of bonded PHYs (MLG2.0, for example, supports one or two 100GBASE-R PHYs) and the constraint that the FlexE clients correspond to Ethernet rates (MLG2.0 supports only 10G and 40G clients)." IETF's CCAMP WG has done some work on this; Pat Thaler noted that there have been inquiries to 802 about whether they care if the IETF does this work. 802.3 has chosen not to take an official position on FlexE. 9. Breakout: Privacy--What is being done? What more should we do? Suresh Krishnan reported that both IETF and IEEE 802 are doing work on the privacy front, and that the work is mostly synced already. 10. Breakout: Multicast and Wireless Donald Eastlake reported that the group discussing multicast and wireless concluded that the people who are interested in this topic from the routing and radio sides need to get together and come up with a global problem statement. They should also investigate whether existing solutions can be more widely applicable, or if new solutions are needed. 11. Ethertype Definition Mahesh Jethanandani noted that there is not a consistent set of definitions for YANG ethertypes. One possible solution is to describe it in YANG with a base type of ethertype base, which is good if you want to make the ethertype extensible. Since the ethertype allocation is centralized with the IEEE RAC, it is up to IEEE as to whether they are willing to take up the work. Pat Thaler replied that this was discussed at the recent RAC meeting. Ethertypes are distributed based on requests received, which allows for the possibility of private ethertypes where the requestor does not publish what protocol it will be used for. Norman Finn added that it would be very unlikely that all ethertypes would have names. Dan Romascanu observed that the IETF uses registries maintained in a MIB module, with a process that is similar to the IANA registries (i.e. expert review). Glenn Parsons replied that the IEEE RAC has a registration for ethertypes, where the requestor fills out a form that asks why it is being requested. The applications are vetted and reviewed by a consultant. If an application passes the review, then the registration authority will assign an ethertype, which is then listed on a page with a protocol field that the assignee provides. In some cases, no protocol is is indicated, or what is listed is different from what it currently being used for. He said it is unclear what the IETF is asking for: a completely automated process where the registration authority of ethertypes is translated into a YANG module, and the requestor is assigned a name based on what is available (no requests for "pretty" names), or a "well-known" list of curated ethertypes? Mahesh Jethanandani replied that IEYF would like the well-known list of curated ethertypes, so that they could be consistent across vendors. Pat Thaler said that it is always public when an ethertype is assigned even if the assignment itself is private. She added that it is not clear to her that there is a way to come up with a definitive base for more than a fraction of the ethertypes when there are some where all you know is the number. Norman Finn said that only the owner of the ethertype has any business picking a name for it, but they would need to make sure that people outside the IETF couldn't allocate themselves an ethertype that was in that curated list. Dorothy Stanley suggested that it could be in an IEEE RAC YANG module. Glenn Parsons replied that he did not think they would do a curated one. 12. Low Latency Mirja Kuehlewind updated the group on low latency networking in the IETF. Slides: https://www.iab.org/wp-content/IAB-uploads/2013/01/ietf99-low-latency.pdf Pat Thaler noted that there are two kinds of latency reduction: going for the lowest maximum latency (as in DetNet), and going for efficiency on throughput. Russ Housley asked if the CDN work in the IETF brought up any additional places where the IETF should be coordinating with IEEE 802. Pat Thaler replied that there is currently not much work going on in 802 about congestion control. Pascal Thubert said that they have asked for low latency in transport, a multi-operator mesh. They have ended up doing a fragment; there are no controls so all the fragments are pushed, causing congestion loss until time-out, blocking the buffers. In 6LO they have started new work about fragmentation that boils down to doing a form of transport at the 6LoWPAN sublayer. There is always a one-hop recovery mechanism but no end to end over the multi-hop mesh. Wireless is lossy by nature. The goal is to be able to recover and avoid buffer bloat within the network. Mirja Kuehlewind noted that there is a draft in TSVWG on using ECN in tunnels; there was a lot of coordination with IEEE on ECN uses.