[ieee-ietf-coord] Rough Notes from 2017-07-15 IETF-IEEE 802 Coordination Meeting

[Cindy Morgan <[e-mail]>]

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 



NOTES
-------------------

1. YANG models (Benoit)

Benoit: Will be describing what we've been doing with the YANG catalog. Since last time we've spent time improving this. We have many YANG models. We could say success, and if I look at my virtual machine I have more than 2000 YANG modules. However, this is just the beginning because unless the models are deployed in networks it's not enough. Need the tooling for the operators and customers, and the metadata.

Joe: As Benoit said, the goal is to provide tool chain. All of the code we've been contributing is open source. Benoit has roped in vendors and SDOs . The YANG search, initially one of the things we wanted to do is, I need to find something, we indexed all of these, and then we try to extract the metadata. When we talk about the APIs we developed we'll get into this a bit. You can search the MAC address. We have a number of ways to search. Getting a lot of feedback, the ability to search on module names, all by WG. In the Hackathon they're working on adding WG-specific metadata, and searched on specific node or schema types.

Joe: Some of the things we've augmented recently, name of node, revision of module, click on address field, get a tree view. Some of the newer things we've added are imported by the number of modules. Can sort and say I want to find all of the SDOs. We can say IEEE, see a few things there, and see then how many times was this module imported by other modules. If I am looking for specific type def, and I want to see how mature it is, I can search on it and start to search and order it and see if it matches the intent of what I'm working on and the maturity level. Using this sort of data, consumers and module developers can understand how stable it is. The other thing that we've been doing is the impact analysis visualizes it, and shows the dependencies. This allows module developers to see the impact their module has on other modules and vice versa. If you're trying to standardize it and you see the impact analysis, that tells you where there are bottlenecks. Show what the next focus area should be. The colors reflect the current maturity level. The mappings we've done thus far we've only focused on the IETF and BBF. What we want to do is bring other SDOs on board, have them provide their metadata, particularly that metadata that can't be automatically extracted. I can now look at the docs from which these were extracted to get more data.

Dorothy: What is the process for tracking changes over time?

Joe: It's a good questions. YANG modules have a revision to them and allow us to keep everything back forever. We treat the unique key around the name of the module, and as you're a vendor or a standards developer, so you would be able to look at see the maturity level at any point in time, and when it was ratified. We don't want to be a clearinghouse for modules. We don't want to have local copies of things that we serve, but we want to have pointers to the canonical place to download them. Show the metadata on how diffs evolve. That begs the question of how we get metadata into the API. What we've done is, the catalog itself, we recently submitted a draft in NETMOD that defines the catalog schema. Also have this up in github. Goal is to not necessarily be standardized but to be transparent int he work we're doing. That will change over time. Added a read-only API that you can see. That would show you the current metadata. This is an example pulled off of the catalog. What we call extractable and non-extractable fields. We have scripts that when a module is extracted from the catalog, others that generate this on the fly. Feed it through the set up scrips and one of the things we're using from the metadata are the organization and the from where the module came. If the module came from the IETF and was hand-written, he can run validators on it. The other things that are non-extractable, we want the module developers to provide are the maturity level and the document name. The other piece of metadata in our catalogs are the implementations in our catalog. Vendors can upload a different set of metadata to our catalog. Here are the modules I implement for this with this software flavor, and we haven't built it yet, but we want to find out what vendors implement one of these. Show me every implementation of IETF interfaces that we know. Or we could say we've go this, I want to see what would be supported if I upgrade. Get all the modules supported in that release. 

Joe: How this gets into the catalog is another API. Part of the early work in the hackathon, really documenting how one can get involved in the YANG model catalog project. Trying to make sure that at least some SDOs are careful with their drafts, but for as much data as you can share, check them into github. They then request a subset of the YANG catalog module, the fields that must be provided by the creator of the module. We have an example of this, upload it with an HTTPS put request, give us the metadata, extract the extractable fields. If you can see there, we have a path that is part of this to each of their module files. We don't want to be the canonical source, but we want to be able to point users to the canonical source. Down frothier we have similar API for vendors. They don't need to upload any modules, just give us access to the implementation metadata and point to their capabilities file. The NETCONF hello message from the device. Once we have that data we can populate our implementation sub-tree. The final thing we put up here, everything has been open source and we intend to keep it that way. Most of it has come out of IETF Hackathons, which have been  great collaboration environments. 

Benoit: As an OPS AD, this allows me to see the evolution of all these in the industry. Allows me to look at the bottlenecks. Also the impact of all these models together. The next thing, we want to distill research for type def. Next steps are, we've been doing great work with IEEE to have the modules in github but some of them still don't validate correctly. One of our vendor designer customer is searching for this and see the failed validation and don't use. And discussed the need to add metadata, if we could show how to add those APIs. Will in the end be beneficial for the IEEE as well. And having a coordination team for YANG models in the IEEE.

Pat: I think there was some discussion last week about trying to coordinate between the teams.

Glenn: I have arranged to create a YANG coordination group across 082, Monthy conference call across this group. We haven't discussed with other groups besides 802.3 and 802.1. Looking to coordinate style as well as other issues it may be helpful for us to have Started 5 new YANG projects in .1 last week. Question on the catalog and the API. Certainly there is a capability to reach out to other places, but I take it has not been added for the IEEE models yet?

Benoit: We have not done anything yet.

Glenn: I know Marc has been asking for YANG doctor review. Is that through the catalog? Curious as to how the IEEE YANG modules in the catalog got there?

Benoit: From the github links.

Glenn: I though someone had to create a login account...

Benoit: there are multiple ways.

Joe: All that's required is access the the module itself. The whole repo was cloned and the indexer ran on it.

Glenn: It was cloned instead of gotten?

Joe: We synchronized the github repo. If no one from IEEE is updating this.

Glenn: You have a year-old draft of the 802.1 module. It's changed significantly. What is the process to update it because we don't want an old module with an incorrect URN to propagate that. I'd like to understand what the process is, and if you include it that the most recent version is there, and make it clear what the maturity level is.

Benoit: I received this github repo as the place to go. I'm very surprised there is something that old in there. We do the churn job everyday. We do keep the old revisions when new ones are added. 

Glenn: Would that mean that by the search, I would get all of the modules, the old ones and the new ones forever? That's problematic from our perspective.

Benoit: Point taken.

Dan: Sounds like there is a lot unknown about each other's procedures. Trying to think of an action item to take from here. Maybe we should define a couple of people who can talk once a month in order to communicate this type of information.

[Benoit and Glenn to talk offline about this.]

Dorothy: One issue is how do we indicate that we have a revision and it's status. Looking at the graph options for the status. We would need a way to indicate what it is.

Pat: That is the metadata we're talking about.

Benoit: 2 last points. At the hackathon, we're doing the graphic interface with REGEX. And we plan to have a GUI to load a specific module to show the python code to go and test the device. 




2. 48-bit and 64-bit MAC Addresses Interworking (Bob H.)

Bob: Not much has transpired since I took the action a couple of weeks ago. Looking to see if we can come up with something on this.

Glenn: Why do we want to do this?

Bob: Maybe we don't, we're investigating. I figure over the next few months we figure out if the answer you guys came up with is still the answer.

Russ: This came up in the meeting in Chicago, and on the coordination call a couple of weeks ago someone noted that we hadn't seen anything about this and that Bob was the stuckee.

Norm: We've had a couple of joint meetings in .1 and .15 where we've discussed various aspects of this. The feeling was if I had a wired 60 bit and a wired 48 bit world it's a pretty straightforward problem to solve. Lots of cute little problems to work on there. But when you ask what the value of bridging is, we have who addresses, and we provide reliable fast broadcast. In a wired world that works well. In a .11 world in only barely works. In a .15 world, there is no such thing as reliable fast broadcast and bridging doesn't work. That's why a lot of .1 people thing it's a bad idea. It doesn't solve your problems. 

Pascal: Building a subnet has been solved, the docs are close to last call in 6lo. Have a registration mechanism and this enables us to proxy the IPv6 neighbor discovery mechanism. Transform the association. As far as we are concerned there is no additional problem to be solved. As far as IETF is concerned this is solved. 

Pat: I think we've decided it solves it enough and we don't want to pursue a pure layer 2 solution. The issue isn't so much 48 to 64. Especially now since we have the ability to use the local address space. The problem is the differences in behavior that break the expectations of protocols.

Bob: Sounds like we're at the consensus we were originally, where we consider this done and take it off the list.


3. Network Slicing (Deborah)

Deborah: Will be a NETSLICING BOF on Monday. Benoit is the responsible AD. For anyone interested, you can attend. And if you're interested in it more from a network view we're also working on it in TEAS and DETNET in the RTG Area. If you're interested, go to the BoF.

Russ: What is the overlap for IETF and IEEE here?

Pat: I think the thing people want to talk about is we have 3 technologies going on about dividing up the use of the network for different clients. Another one is FlexE which is being done in OIF but IETF is considering doing control protocols for. And then there is DetNet. We're going to make virtual network pieces in the pipe, and the DetNet work is about making reservations for specific flows. 

Janos: Network slicing comes from 3GPP?

Jari: It's an interesting topic, useful to know it's the desire to have these networks partitioned for particular customers. 

Deborah: Flexible Ethernet is a totally different beast from these two. I think while some people are hoping for changes to this data plane that's not what this is about.

Ted: On Tuesday during lunchtime, some of our 3GPP colleagues will be here to talk about 5G in general, to have a broad discussion of what types of discussions are needed to make 5G a reality. The extent to which very constrained access technologies are very significant for 5G links. How much does building all the pieces imply that you might now do something different with your upstream link. The extent of the implications are not yet clear, and that is the sort of thing we are hoping to discuss with 3GPP.

Dorothy: Do we need to register?

Ted: No. It's all IETF, on the schedule, no lunch provided.


4.  Where is collaboration needed for Security?

Russ: One thing is that the network inside automotive is becoming a hot topic and we know that security is an important requirement within that, but so far no new requirements identified. 

Pat: Have been discussing that in 802.1 as well.

Russ: Opportunistic wireless encryption was published as an RFC and is getting widely deployed. TLS 1.3 is close to wrapping up  up. EAP TLS method used widely in many places. Asked that someone take a look and make sure the new TLS version don't mean any changes to the EAP method, Dorothy volunteered Dan for that.


5. Where is collaboration needed for IoT?

Pat: There is a lot of things going on that can be described as IOT related work that is a very broad list. We easily came up with 14 or more things and that just scratches the surface. How much of that actually needs coordination? How can we distill all of the work into a coordination interface. One of the things is that IETF has an IOT directorate, and IEEE-SA has an IOT steering committee to look at it on a high level. Possibly a good idea to get some communication between those two groups. Suresh and Jon will coordinate from their respective sides. Jodi will send an introductory email to get people in touch. Already collaborating on some IOT related areas, DetNet, TSN. Another think was about whether link layer in MUD should include encryption. In some areas we're already collaborating tightly but that might benefit from more.

Ted: Dan and I will talk to Eliot about that.

Pat: And should there be some work on the tension that exists between providing a secure identity to the devices that should know your identity in order to do their job properly and protecting privacy from the rest of the world. Being discussed in 802.1 and IETF. 

Potential actions

- Communication between IETF IoT Directorate and IEEE-SA IoT Steering Committee

- Already collaborating on
  o    DetNet/TSN
  o   802E Privacy

- Ted Hardie to dscuss with Eliot Lear whether device level descriptions in MUD should include link layer info

- Should there be a workshop or something between IEEE 802 and IETF on the tension between providing a secure identity and protecting privacy?



6. Time-sensitive Networking/DETNET (Norm)

  Slide 1: IETF DetNet and IEEE 802.1 Time-Sensitive Networking

  Slide 2: Outline
  - The common vision
  - TSN description and status
  - DetNet description and status
  - Cooperation status

  Slide 3: TSN and DetNet: a common vision
  - A DetNet/TSN data stream:
    - May be unicast or multicast.
    - Has an absolute maximum bandwidth, and uses most of it.
    - Requires an absolute upper bound on end-to-end latency.
    - Requires 0 congestion loss in the network.
    - May require extraordinary protection against random or equipment  
      failures.
    - Can afford to make and wait for a resource reservation to obtain 
      these goals.
  - A small to enterprise-sized network can carry any mix of TSN and 
    non-TSN traffic.
  - DetNet/TSN applications typically require time synch to < 1 µS.

  Slide 4: Time-Sensitive Networking Task Group
  - TSN is one of 5 Task Groups of the IEEE 802.1 Higher-layer LAN 
    Protocols Working Group of the IEEE 802 LAN/MAN Standards Committee.
  - IEEE 802.1 chair: Glenn Parsons.  TSN chair: János Farkas.
  - TSN TG (née AVB TG) has been active since 2005.
  - Typically, 2/3 of the 50-60 voting members of 802.1 participate in 
    TSN.
  - Six face-to-face meetings / year, approx. 24-32 hours / meeting
  - 2 hours/week teleconferences.

  Slide 5: TSN completed standards
  Amendments to IEEE Std 802.1Q Bridges and Bridged Networks:
  - 802.1Qat Stream advertisements and resource reservation
  - 802.1Qav Credit-based shaper
  - 802.1Qbu Transmission preemption (along with IEEE Std 802.3br)
  - 802.1Qbv Time scheduled output queues
  - 802.1Qca Extensions to ISIS for multi-pathing and reservations
  - 802.1Qch Cyclic Queuing and Forwarding
  - 802.1Qci Per-Stream Filtering and Policing
  Stand-alone IEEE standards:
  - 802.1AS Timing and Synchronization
  - 802.1BA Profile for plug-and play AVB networks
  - 802.1CB Frame Replication and Elimination for Reliability

  Slide 6: TSN standards in progress
  Amendments to IEEE Std 802.1Q Bridges and Bridged Networks:
  - 802.1Qcc Enhancements for stream reservation protocol
  - 802.1Qcp YANG models for bridges
  - 802.1Qcr Asynchronous Traffic Shaping
  - 802.1Qcw YANG models for all TSN queuing and filtering techniques
  Stand-alone IEEE standards:
  - 802.1AS Timing and Synchronization revision and enhancements
  - 802.1CM Profile for CPRI front-haul networks over bridges
  - 802.1CS Link-local Registration Protocol


  Slide 7: TSN Acceptance
  - Increasing interest, actual deployments.
  - Many vendors, including major bridge/switch vendors, claim 
    compliance with AVB standards.
  - Multiple vendors are claiming compliance with just-completed TSN 
    standards, including credit-based shapers and cyclic queuing and 
    forwarding.
  - Active participation in TSN and in industry fora (ODVA, Avnu) by 
    industrial, automotive, infotainment, and audio-video studio users.
  - IEEE 802.3 has several TSN-specific MAC/PHYs started or starting.
  - AVB deployment is growing.  TSN deployments have commenced.


  Slide 8: TSN issues
  - Vendors and customers have both been waiting for each other.
  - Many relatively small vendors of end stations must make a big leap 
    from dedicated digital busses to a protocol stack.
  - Standards are often ahead of products.
  - No support for routers.


  Slide 9: TSN summary
  - A vendor can build a network claiming compliance to TSN standards 
    that meet all of the goals in the “common vision”, above.
  - There are gaps in management capabilities that hinder 
    interoperability among different vendors, for which projects are now 
    in place to close.
  - Additional capabilities, as requested by certain verticals, are now 
    in progress.


  Slide 10: IETF Deterministic Networking WG
  - DetNet is in the Routing Area, AD Deborah Brungard
  - Charter approved October 5, 2015
  - Chairs: Pat Thaler, Lou Berger
  - 3 face-to-face meetings / year, 2-3 hours/meeting,
  - 2 hours/week teleconferences
  - Appreciable, but not heavy, activity on 3 mailing lists

Norm: Not getting as many person hours on DetNet as on TSN.


  Slide 11: DetNet status
  - Two drafts adopted by WG:
    - Deterministic Networking Architecture
    - Deterministic Networking Use Cases
    - One or both may progress from this meeting
  - Other DetNet drafts:
    - 4 Additional use cases
    - 1 Security
    - 1 Data plane
    - 2 Information model
    - 1 Architecture
    - 1 Control plane
    - A few are likely to be adopted from this meeting, especially the 
      data plane draft.


  Slide 12: DetNet issues
  - Approximately one year behind original milestones.
  - Standards are often ahead of products.
  - The target users are still awakening to the value of networking, and 
    to the differences between bridging and routing.


  Slide 13: Cooperation status
  - Significant common membership
    - More than half of active DetNet participants are also active in 
      TSN.
    - Official liaisons have not been necessary.
  - Apparent agreement on L2 vs. L3 data plane issues.
  - Work on information models (YANG) is just blossoming in both TSN and 
    DetNet.
    - There is a potential for conflict; perhaps a mailing list and 
      teleconference series for information modeling is in order.
  - Potential participants must ask in order to get access to TSN 
    resources.
  - All in all, cooperation has been very successful.

Dan: You mean data models?

Janos: In DetNet they are focusing only on the information models.


Eric Gray: You mentioned discussion on 3 different mailing lists; sounds like a recipe for disconnection.

Norm: Design team mailing list, DetNet security mailing list, and the main mailing list.

Janos: Tomorrow there is a tutorial on TSN. Includes both DetNet and TSN. Will be demo after the tutorial tomorrow, also Thursday afternoon in the coffee break.


7. 5G (Jeff and Glenn)

Glenn: My understanding is we want to talk high level on this. IEEE 5G initiative is not just 802, it is all of IEEE. More than the standards aspect. Conferences, groups, publications, various societies. One of the efforts they do every year is identify new topic areas that will be catalysts for members of IEEE. What they created this year was a IEEE 5G Initiative to establish IEEE as a thought leader essential to the 5G community, bring together people from all standards and sectors.  The activity is organized in several tracks. Education, publication, etc. Prepare a road map of all the standards activity underway in IEEE, led by Paul Nikolich. Identifying new standards areas IEEE can work on. This is the overall initiative. They meet quarterly and have conference calls. The goal is high level interaction and bringing the constituency together. So fat focused just on coordination. An underlying desire to coordinate something in the standards space.

Glenn: The second thing I wanted to talk about is what we've done in IEEE 802. Last year I led an effort to asses 5G and IMT 2020. We were chartered for only half the year.  Wanted to determine if we would work on an IEEE 5G spec an if we would provide a proposal for IMT-2020. That was what we were looking to do. One thing we discovered when we take about this last year was at that time 5G meant many different things to different people. This is one of the things we ended up, there are technology differences. Talking about new services. 

  - 5G is understood many ways.
  - Facets that distinguish 5G may include:
    - Technology: radical new technologies or technology sets
      - could include spectrum-related technology issues
        - millimeter wave spectrum
        - technologies designed for unlicensed use
Service: provides new services or new service sets
Performance: new levels of performance to users, or to operators
Operator ecosystem, either: 
next step for the existing 2G/3G/4G incumbent mobile operators
an opportunity for new operators
Standards: set of interoperability standards rolled out by an ecosystem according to a roadmap
Other Characteristic: a marketing label, a revolution, etc.
  - Scope of an “IEEE 5G specification” would likely differ from scope of other 5G endeavors.

Glenn: Split it into 2 pieces. IMT-2020 is defined by ITU-R, and where we ended up is that we chose 2 paths. We would not do a submission as 802 to IMT-2020. Would prefer to see IEEE tech work with 3GPP tech. Work via liaison relationships with 3GPP. And for the second piece, we decided not to call it 5G. 

Glenn: Created an industry connections activity (bar bof equivalent) that is a non-standards creating activity where we'll discuss the new markets and whether there is something for us to develop. The more interesting part from the 3GPP arrangement is that we have created a new group in 802.11 (AANI advanced access network interface). We have been sending liaisons back and forth. Have requested to 3GPP RAN and then through to PCG was to have a more formal arrangement between 802 and 3GPP for the 5G context. Looking towards us being references in the 3GPP docs and perhaps joint development of an aggregation mechanism between the 2. 3GPP felt the relationship we had already was sufficient and a newer one was not required. 802 is most of the technologies, views of license of spectrum would be handled by our regulatory organization. We would have joint meetings between .1 and .11 as necessary. We had an introspective look at the 5G context, decided what we wanted to do and then executed that. Specifically for trying to work with 3GPP for what the industry thinks 5G is (IMT-2020). That's the high level view. 

Glenn: They have created in 3GPP on how they will work with 802.11 and there are 2 levels of aggregation integration. We'd like to have more interaction but at this stage they've told us what they've done and they'll liaison when they have questions.

Dorothy: In addition we have requests for specific metrics and additional definitions of metrics to support the work they're doing to integrate .11. Asked for us to define the metrics. Have a call for contributions out on this now. There are 3-4 different ways that .11 technologies are being integrated into their system. Goal is that in a 5G system the radio tech is another peer technology.

Jeff: Now have formal requirements from 3GPP for liaison. We interact through liaison managers. There is a BOF for NETSLICING. The number of use cases identified. Hopefully at some point 3GPP will provide this. New use cases are EAP for authentication. A lot of work in data model, RTG area in general. Looking into SDN and using packet network for transport. Work in I2RS, NETMOS, NETCONF, TEAS. Must work to distribute the constraints. New data plan computation to provide data plan model.

Jeff: A lot of work happening around SPRING and routing, to be used within 5G concept, how to provide a set of resources. None of this is explicitly asked by 3GPP. This is work we assumed they would need. Discussed DetNet, it's explicitly needed and we should be able to provide a set with low latency. Talked about data modeling in TEAS, ACTN. Could be useful to provide network layer slicing. A new transport QUIC layer in TSV. Need to ensure that the existing tools that there are for TCP-based solutions have sufficient definitions as new QUC transport is being developed. Have a pretty good relationship with them. 

Glenn: There has been no formal request from 3GPP. The last release, there were IETF dependencies.

Russ: A whole slew of them.

Glenn: Are you expecting that again?

Russ: That started much less formally and got more and more formal as they got closer to shipping stuff we weren't done with. Except that might happen again that way for 5G.

Suresh: They way 3GPP tracks dependencies with the IETF has changed. All the IETF items are tracked in the 3GPP work plan with their own dependencies inside. 

Jeff: It's completely outdated.

Suresh: I can send you the work plan.

Jari: The bigger picture is that 3GPP is working on so much they have much to do in a short amount of time, and will likely make their decision on the technology very late in the process, which is why they can't send us requirements. 

Subir: I have seen email that circulated a few days ago that said they are promoting the use of QUIC; is that similar? I thought since QUIC is not mature yet and is not in release 15 it will be in release 16.

Ted: [] will be talking about that in QUIC. Doesn't look like it will fit the release 15 timeline, not clear if it will fit 16 either. Not writing a new application protocol on top of QUIC. There would be no particular requirements for QUIC to respond to SBA except to say this is a useful implementation draft to test against. 

Deborah: Re ACTN, there are several WG docs on that in TEAS now. 

Subir: Who is the current person from 3GPP?

[Georg Mayer]

Suresh: There's a meeting not on the schedule about this with them on Monday, not specifically about 5G but about ongoing work. 

Jeff: Is anyone attending who can report back?

Suresh: Ben has most of the dependencies.

Jeff: Can you report back?

Ben: I can try.





8. FlexE (Deborah)

Deborah: Disclaimer: I didn't put this on the agenda.


  Slide 2: FlexE (Flexible Ethernet)
   • OIF (Optical Internetworking Forum) dataplane
   http://www.oiforum.com/wp-content/uploads/OIF-FLEXE-01.0.pdf


  Slide 3: CCAMP
   • GMPLS Routing and Signaling Framework for Flexible Ethernet (FlexE)
   https://datatracker.ietf.org/doc/draft-izh-ccamp-flexe-fwk/
   • ISIS extensions for Flexible Ethernet
   https://www.ietf.org/id/draft-zcdc-isis-flexe-extention-01.txt
   • Couple of liaisons:
     - CCAMP->ITU-T SG15 –ask status
     - ITU-T SG15->CCAMP –answer
     https://datatracker.ietf.org/liaison/1535/
     - BBF –request information on CCAMP’s work
     https://datatracker.ietf.org/liaison/1523/

Warren: I've only looked at this briefly and would like to understand more. Why would you want to take 100 and make it work at 50.

Pat: They're making it work like you can have a 50 and 2 25s and they also want to be able to do it say they can bond them together. Like LAN except it's one link. It's down in layer 1 bonding them together. 

Deborah: It's all these calendar slots you combine. You could use an OTM interface. The advocates of this say it's a simple ethernet link to connect the data centers.

Pat: Probably it is more unique in what you get when you bond them together than what you get when you split them.

Jari: Is there a connection to IEEE in this? Why are we discussing this today?

Norman: It's interesting that a group working on the MAC layer would come to IETF to work on a control protocol when the control protocol will clearly be working at the MAC layer.

Pat: It's not clear what level it will be working at. 

Deborah: Early docs in CCAMP trying to change the data plane control. That's not our data plane.

Pat: There have been inquiries if 802 cares if IETF does the work OIF asks them. 802.3 has no position on FlexE. They know it's being done and have chosen o not take any official position on it. It's on thing whether you think it's useful or not, but as far as would be care or be bothered if IETF works on the control protocol, I don't think we care. I think the idea is that the control protocol might not work at layer 2. 

Norman: Even at layer 2 you can't be sure you're talking to your neighbor.

Pat: But officially as 802 we have no position and don't care. 

  Slide 4: Extra, Extra


  Slide 5: Deep Dive (from OIF IA)
  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).


  Slide 6: More... (from OIF IA)
  • The general capabilities supported by the FlexE implementation 
    agreement are:
  • Bonding of Ethernet PHYs, e.g., supporting a 200G MAC over two 
    bonded 100GBASE-R PHYs.
  • Sub-rates of Ethernet PHYs, e.g., supporting a 50G MAC over a 
    100GBASE-R PHY.
  • Channelization within a PHY or a group of bonded PHYs, e.g, support 
    a 150G and two 25G MACs over two bonded 100GBASE-R PHYs.
  • Note that hybrids are also possible, for example a sub-rate of a 
    group of bonded PHYs, for example, a 250G MAC over three bonded 
    100GBASE-R PHYs.


  Slide 7: And More...
  • Refer to Fig. 2 and Fig. 3 of IA
  • Is it Ethernet or not? Has 802.3 PHY, does not have MAC frame – no 
    MAC address, FEC is optional.
  • Uses a FlexE frame comprised of calendar slots which contain 
    64B/66B encoded clients (with their own separate MACs).



9. Privacy. What is being done? What more should we do?

Suresh: We had a chat about the work we're both doing on the privacy front. Mostly synced already; Ted and Juan-Carlos both working both sides. If they work in a coordinated fashion they can deliver maximum benefits. Not much to do except keep in touch.

10. Multicast and Wireless.

Donald: Lot of discussion. Conclusion is we need to get people who are concerned about this problem in a broad way and get them together, routing and radio, and have them come up with a global problem statement. Investigate whether existing solutions might be more widely applicable or if new solutions are needed.





11. Ether-type Definition

Mahesh: This should have gone with the YANG topic. Look at what will it take to get a consistent set of definitions for the stack. Currently we have several occurrences after the definition. MEF has defined its own. Other than just making sure there is just one place for the definition, there is what should the definition be. 1q defines it as a string but the expectation then is then the customer has toe specify the route. Make sure that the value is correct. 

Mahesh: One possible solution is to describe it as a [] in YANG with a base type of ether type base. Discussion statement if this defines it then value of 100. This is good if the idea is you want to make the ether type extensible. My understanding of how they are allocated is they are not distributed, they are centralized with the RAC. Define them as ENUM.  The ball is for IEEE to say whether are willing to take up the work or not.

Pat: We had some discussion on this at our meeting. They are centrally distributed in that the registration authority distributes them based on requests for them, the thing is that the request allows it to be a private ether type which the requestor doesn't necessarily publish what protocol it's for. One couldn't necessarily say, this is the ether type of value x. Even when it's not private they don't all say what protocol they're for.

Norm: Very unlikely that all ether types would have names.

Pat: And not sure how we'd keep the list, can't do it in a standard since it's changing all the time.

Dan: In the IETF we have registries maintained in a MIB module. The process is kind of similar to IANA. Historically similar. Standards organizations could come to IANA and ask for a new one, there is an expert review to check to see if there is a stable and publicly available [] for the request. Don't know if that process would work for ether types.

Glenn: The IEEE RAC has a registration for ether types. Have to fill out a form and say why you want it. Application is vetted and reviewed by a consultant. If it passes the review, the registration authority will assign an ether type. Listed on the page with a protocol field that the assignee provides. The assignee in some cases indicates no protocol, or something totally different from what it's currently used for. Unclear what IETF wants here. There are 2 paths. One is where it is completely automated, in that they registration authority of ether types is translated into a YANG module. All that will be available is what is in the database, and you won't be able to get pretty names, you'll get whatever is in the database. Or does IETF want the "well known" list of ether types, and would they like it curated?  We were stuck on the "why do you want this at all?"

Mahesh: The well known ether types, we want to be consistent across vendors. 

Pat: It's always public when an ether type is assigned. Whether it's private or not it's public who bought it. It's not clear to me that there is a way to come up with a definitive base for more than a fraction of the ether types where there's bunch where all you know if the number.

Norman: Given that YANG tends to be up in bit bucket, I would suggest only the owner of the ether type has any business picking a name for it. My biggest worry would be making sure that your list matches the RAC's list. Can't have people allocating themselves an ether type in your database.

Pat: It depends who is you, potentially it could be easy to say it should come from our YANG. Should income from some IETF YANG or something else.

Dorothy: Could be an IEEE RAC YANG module.

Russ: Could be that followed by 4 digits, and if you want more go talk to them.

Jeff: Enforce uniqueness.

Pat: A meaningful an where we have a meaningful name and it's up to us to figure out how. But might need YANG experts to help with this.

Glenn: Write a script to generate this.

Norman: Could do aliasing. Just don't want 2 different people generating that list of numbers.

Suresh: If you look in the YANG catalog, you'll look in and see, there is a reputation based thing. I think this will solve itself. I think the scope of what Mahesh wants to do is the ones in IETF protocols. Go ahead and do it in the RAC, but we can have better names.

Russ: Desire is to see if the RAC will generate a YANG module.

Glenn: I don't think they'll do a curated one.




12. Low Latency (Mirja)

  Slide 1: Low latency networking in the IETF 


  Slide 2: Note on latency in networking
  Approaches may optimize for two different kind of latency:
  - Total (file) transmission time 
    e.g. request/response like in HTTP 
  - Per-packet latency and latency variation (jitter) 
    e.g. interactive communication like WebRTC


  Slide 3: Low Latency 	Applications and the Internet Architecture
  • https://tools.ietf.org/html/draft-arkko-arch-low-latency-01
  • Applications with Special Focus on Low Latency
  • Role of Low-Latency vs. Other Communications
  • Selected Improvements to Communications Latency
  • Architectural Considerations & Implications


  Slide 4: Application/Security
  • tls: 0-RTT session resumption in TLS1.3
  • rtcweb: use of DiffServ codepoints to request network support
  • alto: service to provide and request information for server 
    selection


  Slide 5: Transport and Congestion Control
  • tcpm:  
    • TCP’s Initial Window of 10 (IW10)  
    • TCP Fast Open (TFO) enables data on TCP SYN 
    • TCP Rack fast loss detection for short transmission with tail loss 
    • Datacenter TCP (DCTCP) Congestion Control for datacenters to avoid
     high loss and delay due to incast 

  • QUIC: new, encrypted transport protocol that also provides a 0-RTT
    transport handshake on session resumption 

  • rmcat: RTP Media Congestion Avoidance Techniques that aims to 
    minimize self-induced latency 

  • mptcp: aims to utilize the path with the best performance if 
    multiple paths with different characteristics are available


  Slide 6: AQM and queuing 
  • aqm: new Active Queue Management (AQM) schemes that are optimized 
    to keep queuing delay low, e.g. CoDel
    and PIE (wg finished and will be closed soon)

  • tsvwg: L4S (Low Latency, Low Loss, Scalable
    Throughput) services provide a separate queue for
    scalable congestion control


  Slide 7: Networking and Routing 
  • detnet: Provisioning of paths that can provide bounds on latency, 
    loss, and packet delay variation (jitter).


Pat: There are two kinds of latency reduction. There is latency reduction as we do it in detnet, where we do it for known streams. Going for the lowest maximum latency, versus, and in order to do that you're willing to have a bit worse average latency, you know you're never worse than this bar. And then there is low latency for efficiency on throughput. Highly variable amounts of stuff. Any times we're moving it we want to get through the network as fast as the network will bear.

Mirja: Talk a lot about buffer bloat, sometimes they have been over dimensioned. Everything that is more related to routing and caching, move everything to something closer and move the traffic to there. 

Russ: CDNs in the IETF. Does this spark any places where we should be coordinating that we're not already?

Pat: I think for the most part the trend has been to say we want to have consistent layer 2 and 3 networks. We've decided not to embark further on congestion control so far. Decided not to pursue additional ones at this point. Right now there's not a lot going on in 802 about congestion control. Outside 802 there is a revival of interest, but I don't know where that will go.

Norman: MAC in MAC data center.

Pascal: We are asking for this in transport, a multi operator mesh. What we end up doing is a fragment. No controls so we push all the fragments. Time out and block your own buffers. We are now starting new work in 6lo about fragmentation that boils down to doing a form of transport at 802. There is always a one hop recovery mechanism. It's lossy by nature. This is not new news, but now we are wanting to be able to recover and avoid buffer bloat within the network, we are doing all this and our trouble is to do it and be respectful. We want to do it right.

Mirja: There is/was a draft on using ECN in tunnels. I can forward it to you. And we had a lot of coordination with IEEE on ECN uses.

Pat: It's a draft in TVWG.

Suresh: ECN encap guidelines.

Pat: I think it would be good for you to talk to TSVWG.

Pascal: Need continuous support, there are numbered things we need. 

Suresh: This is 2 pieces of IETF that need to coordinate.

Dorothy: Thank you for the presentation. I appreciate that this work is going on in the IETF because the better the core network works, the better the end to end service is. We all look better. 

Mirja: This notion that latency is something to look out is moving on. 

Subir: Any work on level 2?

Mirja: Not connected to low latency. There are applications that don't rely on transport.




13. Any other business