2017-07-15: Minutes
slides-interim-2021-ietfieee-06-sessa-2017-07-15-minutes-00

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 <https://
  yangcatalog.org/>. 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
  <http://www.oiforum.com/wp-content/uploads/OIF-FLEXE-01.0.pdf>:

  "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 <draft-ietf-
  tsvwg-ecn-encap-guidelines> on using ECN in tunnels; there was a lot
  of coordination with IEEE on ECN uses.