Subject: [Coin] Draft minutes - COINRG interim meeting - 2019-06-07

From: "Schooler, Eve M" <[email-masked]>
Date: Fri, 14 Jun 2019 07:29:01 +0000

Hi All,
Here are the draft minutes from the interim meeting held last week,
gleaned from Jeffrey's notes and me listening to the recording made by Marie-Jose  (thank you both).
We welcome your suggested edits/inputs/corrections and would appreciate your help to capture the correct attendee list.
Many thanks to those who were able to participate,
JEM (Jeffrey, Eve, Marie-José)

-----
COINRG - https://irtf.org/coinrg
Friday 07 June 2019
Interim meeting
Chairs: Jianfei (Jeffrey) He, Marie-José Montpetit, Eve M. Schooler
Meeting materials: https://datatracker.ietf.org/rg/coinrg/meetings/
-----

Attendees:
--------------
Aaron, Alex, CORE WG, Dave Oran (Network Systems Research & Design), Dirk Kutscher (University of Applied Sciences Emden/Lee), Dirk Trossen (InterDigital), David Lou, Daniel Bernier (Bell Canada), Emile, Eve Schooler (Intel), Ike Kunze (RWTH Aachen), Jianfei (Jeffrey) He (Huawei), Jörg Ott (Technische Universität München), Marc LeClerc (NoviFlow), Marie-Jose Montpetit (MIT), Ronald van der Pol (SURFnet), Xavier de Foy (InterDigital), Yvon Savaria (Polytechnique Montreal)

Agenda:
----------
- Review of the charter towards actualizing it
- Montreal P4 hackathon
- Montreal IETF 105 meeting
- Other topics of interest

Charter
----------
MJM: Welcome to all. We have several folks from the P4 community, including those from Ecole Polytechnique and NoviFlow. And several newcomers.
The agenda today: discuss current charter, prepare for the upcoming P4 Hackathon (acknowledged as having a smaller scope than a COIN Hackathon), prepare for the upcoming COIN meeting.
Because we ran out of time at the last IETF, would like to focus the discussion here on the charter.
COIN proposes to look at everything that is programmable and  to advocate for richer programmability.
Its context is the Cloud-to-Edge continuum and the  evolution of the network from largely sending packets to combining networking with compute and storage.
High interest in what is currently underway with NetCache and Kubernetes, yet also very interested in use cases such as IIoT, AR/VR, autonomous/connected vehicles.
Need new architectures as well as functional distribution.
Paying close attention to DINRG and ICNRG (chairs from both are on the call), as well as interest in distributed networking (Dirk Trossen) and in the Transport area (Joerg Ott).
There is friction between E2E semantics of the network and E2E privacy/security, and COINRG ambitions to intercept some of the packets (an interest of Aaron Falk).
Decomposition of computational tasks is interesting, not just because of the Edge-ification of the Cloud that distributes parts of the computation, but also for energy efficiency.

Dirk K: Co-chair ICNRG and DINRG. Researching Networking and Distributed Systems.
One perspective to bring into the discussion: The list of topics in the scope includes programmable networks and devices.
However there are at least 2 things worthwhile to mention and to untangle.
Programmable networks, which could be perceived as using SDN for configuring and controlling the network and using languages like P4 to achieve (forwarding) behaviors for IP networks today.
The other aspect we haven't addressed sufficiently and certainly have not mentioned enough: networked computing, or distributed computing.
How could next generation distributed compute raise new requirements for networks and how could networks support them?
This could be the most interesting aspect of this group. Lots of distributed computing exists today in overlays in the cloud, but something new to look at: how could next generation distributed computing interact with the network, and how could the network support distributed computing from different research angles. What does it mean for protocols, security, manageability and also APIs? How would you actually work with this new capability and with this new kind of network?

MJM: Consider the aspect of mirroring: What can the network do for distributed compute and what can distributed compute do for networks? When we were looking at AI, a lot of people asked what can AI do for the network. Later, considered what can the network do for AI. Thus, raising the same kind of duality here.

Joerg Ott: [Happy Birthday! 2 days ago!]
Charter up to this point is written such that it could be interpreted or read in a number of different ways.
Assumption however has always been: What can the network do for applications and not what the network can do for network management.
MJM: Absolutely.

Dirk K.: Why APIs are important is that it is always good to have a certain perspective on the implementation.
How can a research group enable real experiments that in some way evaluate these ideas?
May not need an extended list of milestones attached to the charter, but instead need a few first Goals.
What could COIN do to enable experimentation and validation?

[20:32-21:03 - audio outage]

Dirk T : When read the RG title, found it interesting it was called Computing in the Network. Reminded of a presentation given in a related effort in the ITU which is looking into Network 2030. Discussion in there on Edge computing.
Dirk has submitted a scenario on application level services as an I-D to COINRG.
Here, let's discuss and question where the boundary of the network is, what is it that the network can bring to the task at hand?

MJM: The definition of the network is currently very fluid. This is why we are calling it a continuum.
But as a research group we need to focus and to scope.
Let's move the editing of the charter to the mailing list.

Dirk T: A final comment on the charter: the use cases are geared toward requirements analysis. Identify what we are talking about and what we are NOT talking about, going forward. Requirements sounds too solutions/development oriented.
MJM: There exists many Edge research efforts. We are looking for something original or unique, looking at research that is off the beaten path that is not being done elsewhere.

P4 Hackathon
-----------------
MJM: The P4 language is dedicated to packet filtering at line speed. Has a C-like language. Done for speed. Doesn't do floating point or multiplication, but does other cool things. We have experts on the call today.
Hackathon to happen 7/20-7/21. Remote participation will be possible. Will have multiple levels of people there. Beginners and experts. MJM falls in the middle; participated in a hackathon in Boston.
Marc to supply the group with the licenses and also will send us a few helpers.

Marc: Would like to tie the hackathon to the practical side.

Joerg: Caution that we should not let people misunderstand "COIN is exactly p4" or "COIN is only P4".  What MJM liked around the Hackathons at the IETF, there are multiple WGs in the same room and cross fertilization. Acknowledged that this hackathon will be simpler and have a smaller scope than a COIN Hackathon.
Focused on P4, because there is a big P4 community in Montreal.

Marc: As a marketing person, sees a hackathon as having two objectives: 1) promote ideas and 2) attract people to participate in the execution of those ideas. Could call it a hackathon focused on a programmable forwarding plane.
However, need to make it interesting, yet the technology should not be too broad. In the case of Noviflow, we've been developing programmable forwarding planes for 7 years. We have a lot of experienced engineers who know how to use the Barefoot development tools. Therefore the hackathon could basically use Barefoot's toolkit to do the exercises. In contrast to what was done in Boson, have a suggestion on areas for things to look into. Example: take a look at the intimate connection between forwarding plane and application and services, e.g., ask the students to accurately test the latency of services, which would be a specific target so can be delivered within the scope of 2 days. Contrary to the Boston P4 hackathon, have more of a unified environment, have experts from NoviFlow provide assistance so they can focus on the idea creation, not on the tools.

MJM: Noa shared a link to tutorials, cheat sheets and basic P4 tools. Will share it to the mailing list. P4.org exists and is promoting the language.

Yvon: We have several students interested in using P4 for better network devices. Would like to have some of the students involved and help with this Hackathon.

Eve: In an Edge environment, marshalling resources and configuring those resources, marrying resource capabilities and job tasks, is all very complicated. How to scope down the space for a hackathon? Perhaps we think about a long term hackathon objective and break it down into smaller steps, over the course of several hackathons. Demonstrate a big hairy audacious goal, like some sort of smart city application. How to incrementally have hackathons that nibble on concepts in the space that demonstrate programmability and computation in the network. And their interplay with data management.

MJM: As Joerg noted, COIN is not about p4, there is a much bigger picture; a small piece of that picture is P4. Could use Montreal to define a bigger project. Will ask the list if there are specific project ideas for the Hackathon in mailing list. Will post P4 tools to the mailing list as well.

IETF 105 Montreal meeting
--------------------------------
MJM: 2 hours requested. COINRG was mostly successful in Prague, though didn't have enough time to really discuss the charter. Need to look at and review the drafts, which include I-Ds from Dirk T, Eve, MJM, Jeffrey. Potentially a new draft on Industrial networks is in the works. Also someone from Chicago (new way to look at video distribution, a cool way of using computing in the network).

Ike: We are working on the industrial application draft. We are planning to be in Montreal, either me or my professor. We will try to submit the draft in time.

Dirk T: will be Montreal, if no conflict, will present my draft in person.
Jianfei: Dirk K mentioned in the mailing list that he may share some ideas about function placement and stateful computing.

Dirk K: Let me think about how I'd package and frame these ideas.

---

From: <[email-masked]>
Date: Fri, 14 Jun 2019 07:17:10 -0400

Please see inline below preceded by "<hs>".  Wow, lot has happened since the
meeting occurred.  Barefoot is now Intel. 

From: Coin <[email-masked]> On Behalf Of Schooler, Eve M
Sent: Friday, June 14, 2019 3:29 AM
To: [email-masked]
Cc: Schooler, Eve M <[email-masked]>; Marie-Jose Montpetit
<[email-masked]>; Hejianfei (Jeffrey) <[email-masked]>
Subject: [Coin] Draft minutes - COINRG interim meeting - 2019-06-07

P4 Hackathon

-----------------
MJM: The P4 language is dedicated to packet filtering at line speed. Has a
C-like language. Done for speed. Doesn't do floating point or
multiplication, but does other cool things. 

<hs> P4 supports multiplication.  It's division nor modulo arithmetic which
are not supported by P4.  Before P4 it was hard to do rapid prototyping of
networking data plane. 

We have experts on the call today.

Hackathon to happen 7/20-7/21. Remote participation will be possible. Will
have multiple levels of people there. Beginners and experts. MJM falls in
the middle; participated in a hackathon in Boston.

Marc to supply the group with the licenses and also will send us a few
helpers.

Joerg: Caution that we should not let people misunderstand "COIN is exactly
p4" or "COIN is only P4".  What MJM liked around the Hackathons at the IETF,
there are multiple WGs in the same room and cross fertilization.
Acknowledged that this hackathon will be simpler and have a smaller scope
than a COIN Hackathon.

<hs> P4 is the only means to program the data plane of a networking device
in the field.  What is COIN going to run on?  Switching asic, FPGA, or
generic compute - all are supported by P4.  See more details at:
https://github.com/hesingh/p4-info

Marc: As a marketing person, sees a hackathon as having two objectives: 1)
promote ideas and 2) attract people to participate in the execution of those
ideas. Could call it a hackathon focused on a programmable forwarding plane.

However, need to make it interesting, yet the technology should not be too
broad. In the case of Noviflow, we've been developing programmable
forwarding planes for 7 years. We have a lot of experienced engineers who
know how to use the Barefoot development tools. Therefore the hackathon
could basically use Barefoot's toolkit to do the exercises. 

<hs> To use Barefoot's Tofino tools chain, one needs to sign an NDA with
Barefoot.  NoviFlow has NDA with Barefoot.  What about random folks who come
to the hackathon and don't have NDA will Barefoot?  Would such folks sign
NDA with NoviFlow or Barefoot? The public-domain P4 compiler (p4c) and its
tools chain are also fine for use at any hackathon.  

MJM: Noa shared a link to tutorials, cheat sheets and basic P4 tools. Will
share it to the mailing list. P4.org exists and is promoting the language.

<hs> P4 has a Slack channel (https://p4-lang.slack.com).  Please join it for
any P4 help.

Best,

Hemant

---

From: <[email-masked]>
Date: Fri, 14 Jun 2019 10:24:03 -0400

P4 Hackathon

-----------------

However, need to make it interesting, yet the technology should not be too
broad. In the case of Noviflow, we've been developing programmable
forwarding planes for 7 years. We have a lot of experienced engineers who
know how to use the Barefoot development tools. Therefore the hackathon
could basically use Barefoot's toolkit to do the exercises. In contrast to
what was done in Boston, have a suggestion on areas for things to look into.
Example: take a look at the intimate connection between forwarding plane and
application and services, e.g., ask the students to accurately test the
latency of services, which would be a specific target so can be delivered
within the scope of 2 days. Contrary to the Boston P4 hackathon, have more
of a unified environment, have experts from NoviFlow provide assistance so
they can focus on the idea creation, not on the tools.

<hs> Boston hackathon, which I attended for the whole day, did have a
unified environment - all of us used p4lang/p4c (open-source P4 compiler).
All of us in Boston who wrote P4 programs hit the ground running with
p4lang/p4c.  Thus, even, we spent time on ideas, not tools.   We had over 19
years of data plane programming experience at Boston.  MNK Consulting
(http://mnkcg.com ) with > 13 years of Cisco pxf, Cisco QFP,  Cavium Xpliant
data planes, and P4 experience since Fall 1996.  Juniper was there with 6
years data plane programming.  Now, MNK Consulting has Barefoot Tofino
experience as well - I am working remotely on Saturday and available for
help  via the P4 Slack channel (userid: Hemant).

I see a problem with Barefoot's Tofino tools chain.  For example, there are
20 of us at the P4 hackathon.  Each one of us would like the Tofino tools
chains installed on our laptops.  How would NoviFlow help with that before
the hackathon?  Or will NoviFlow provide 20 machines with Tofino tools chain
built and ready for use?  Sharing machines slows down productivity.  What if
some of us are remote - how do we login to the machines remotely?  I have
already asked about NDA issues with Barefoot.

In contrast, if one uses the p4lang/p4c, we have no external dependency and
start writing P4 programs immediately. P4lang/p4c also includes a tools
chain to test using packets.   I suggest to use either environment and crank
out P4 code.  

We should get more ideas - please add them to the wiki:
https://trac.ietf.org/trac/ietf/meeting/wiki/105hackathon  

Hemant

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Fri, 14 Jun 2019 10:39:59 -0400

Thanks for this.

I plan to work on the hackaton next week. I was and still am in all day meetings all week in Montreal.

mjm

> On Jun 14, 2019, at 10:24 AM, <[email-masked]> <[email-masked]> wrote:
> 
>  
> From: Coin <[email-masked] <mailto:[email-masked]>> On Behalf Of Schooler, Eve M
> To: [email-masked] <mailto:[email-masked]>
> Cc: Schooler, Eve M <[email-masked] <mailto:[email-masked]>>; Marie-Jose Montpetit <[email-masked] <mailto:[email-masked]>>; Hejianfei (Jeffrey) <[email-masked] <mailto:[email-masked]>>
> However, need to make it interesting, yet the technology should not be too broad. In the case of Noviflow, we’ve been developing programmable forwarding planes for 7 years. We have a lot of experienced engineers who know how to use the Barefoot development tools. Therefore the hackathon could basically use Barefoot's toolkit to do the exercises. In contrast to what was done in Boston, have a suggestion on areas for things to look into. Example: take a look at the intimate connection between forwarding plane and application and services, e.g., ask the students to accurately test the latency of services, which would be a specific target so can be delivered within the scope of 2 days. Contrary to the Boston P4 hackathon, have more of a unified environment, have experts from NoviFlow provide assistance so they can focus on the idea creation, not on the tools.
>  
> <hs> Boston hackathon, which I attended for the whole day, did have a unified environment – all of us used p4lang/p4c (open-source P4 compiler).  All of us in Boston who wrote P4 programs hit the ground running with p4lang/p4c.  Thus, even, we spent time on ideas, not tools.   We had over 19 years of data plane programming experience at Boston.  MNK Consulting (http://mnkcg.com <http://mnkcg.com/> ) with > 13 years of Cisco pxf, Cisco QFP,  Cavium Xpliant data planes, and P4 experience since Fall 1996.  Juniper was there with 6 years data plane programming.  Now, MNK Consulting has Barefoot Tofino experience as well – I am working remotely on Saturday and available for help  via the P4 Slack channel (userid: Hemant).
>  
> I see a problem with Barefoot’s Tofino tools chain.  For example, there are 20 of us at the P4 hackathon.  Each one of us would like the Tofino tools chains installed on our laptops.  How would NoviFlow help with that before the hackathon?  Or will NoviFlow provide 20 machines with Tofino tools chain built and ready for use?  Sharing machines slows down productivity.  What if some of us are remote – how do we login to the machines remotely?  I have already asked about NDA issues with Barefoot.
>  
> In contrast, if one uses the p4lang/p4c, we have no external dependency and start writing P4 programs immediately. P4lang/p4c also includes a tools chain to test using packets.   I suggest to use either environment and crank out P4 code.  
>  
> We should get more ideas – please add them to the wiki: https://trac.ietf.org/trac/ietf/meeting/wiki/105hackathon <https://trac.ietf.org/trac/ietf/meeting/wiki/105hackathon>  
>  
> Hemant

---

From: "Hejianfei (Jeffrey)" <[email-masked]>
Date: Mon, 17 Jun 2019 02:23:14 +0000

A few suggestions for the P4 hackathon in Montreal ( chair hat off):

(1)    Tool kit: I tend to agree with Hemant to use P4C compiler and bmv2 as the behavioral model for the P4 software switch.  We can generate virtual ports from Linux, connect these ports to this P4 software switch, use tools(e.g scapy + wireshark) to send and check the in/out packets of the switch to test if it works correctly. Then, every team in this hackathon only need a server or Virtual machine to run these software?

(2)    We also need some tasks for the teams to select and challenge, right? The attractive part of P4 and programmable switches to me is essentially to process packets in a “stateful”/correlated way. then, according to

1) these correlated packets are in the same flow or from different flows

2) the objective for processing is for better forwarding/transport or non traditional forwarding(e.g cache/compute),

we may have 4 quadrants:

1) single-flow processing for better forwarding: e.g FEC, re-ordering, flowlet-based load balancing etc.

2) co-flow processing for better forwarding: e.g new scheduling or AQM? (I am not sure how we can control the queue management part in the BVM2, need to check).

3) single-flow 4) co-flow processing for non-traditional forwarding function: Quite a few research projects has been listed in the draft(https://datatracker.ietf.org/doc/draft-he-coin-managed-networks/), but maybe the simplest use case is the ConvergeCast(http://www.cs.yale.edu/homes/aspnes/pinewiki/ConvergeCast.html?highlight=%28CategoryDistributedComputingNotes%29)?
My two cents,
Jianfei(Jeffrey)

发件人: Marie-Jose Montpetit [mailto:[email-masked]]
发送时间: 2019年6月14日 22:40
收件人: [email-masked]
抄送: Schooler, Eve M <[email-masked]>; [email-masked]; Hejianfei (Jeffrey) <[email-masked]>
主题: Re: [Coin] Draft minutes - COINRG interim meeting - 2019-06-07

Thanks for this.

mjm

On Jun 14, 2019, at 10:24 AM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

From: Coin <[email-masked]<mailto:[email-masked]>> On Behalf Of Schooler, Eve M
Sent: Friday, June 14, 2019 3:29 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Schooler, Eve M <[email-masked]<mailto:[email-masked]>>; Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>>; Hejianfei (Jeffrey) <[email-masked]<mailto:[email-masked]>>
Subject: [Coin] Draft minutes - COINRG interim meeting - 2019-06-07

P4 Hackathon
-----------------

<hs> Boston hackathon, which I attended for the whole day, did have a unified environment – all of us used p4lang/p4c (open-source P4 compiler).  All of us in Boston who wrote P4 programs hit the ground running with p4lang/p4c.  Thus, even, we spent time on ideas, not tools.   We had over 19 years of data plane programming experience at Boston.  MNK Consulting (http://mnkcg.com<http://mnkcg.com/> ) with > 13 years of Cisco pxf, Cisco QFP,  Cavium Xpliant data planes, and P4 experience since Fall 1996.  Juniper was there with 6 years data plane programming.  Now, MNK Consulting has Barefoot Tofino experience as well – I am working remotely on Saturday and available for help  via the P4 Slack channel (userid: Hemant).

We should get more ideas – please add them to the wiki: https://trac.ietf.org/trac/ietf/meeting/wiki/105hackathon

Hemant

---

From: <[email-masked]>
Date: Mon, 17 Jun 2019 08:13:09 -0400

There could be another pitfall with using Tofino tools chain.  Switch companies, e.g., Cisco have shipped p4-14 code with their Tofino switch.  I suspect, even Arista switch using Tofino shipped with p4-14.   What if NoviFlow brings Tofino switches and p4-14 tools chain to the hackathon?  Nobody in the research community works with older p4-14.  Folks are using p4-16.

Regarding Jeffrey’s notes, below, item 1 is totally possible.  Just use a Windows laptop with Ubuntu running in a virtual machine.  I’d give 20G-30G disk space to Ubuntu and 4G of RAM.  P4lang/p4c does not use much disk space.  P4lang/p4c also supports MacOS.  

See P4 code I checked in.  The code was tested using STF packets and virtual bmv2 simple_switch from p4lang/p4c.

https://github.com/IETF-Hackathon/p4-ipv6-switch-ml/blob/master/ipv6-switch-ml-bmv2.stf#L52                                                                             

A STF (Simple Test Framework) file uses “packet” to send and “expected” packet to test received packet from the virtual simple_switch.  I do generate my packets using Scapy and use a small Python program to convert Scapy packet to STF byte format.  See https://github.com/jafingerhut/p4-guide/blob/master/README-scapy.md and a function called bytes_to_hex.  STF also allows commands to program data plane tables.   If you see the wiki (https://trac.ietf.org/trac/ietf/meeting/wiki/105hackathon), I have added more notes to the IPv6 Switch ML project.  The notes list one script that downloads p4lang/p4c and behavioral-model software and dependencies.  Just build both software and then one is ready to use p4c and STF packets with bmv2 and simple_switch.  If have also provided a link to MacOS users.   p4lang/p4c is the P4 compiler and p4lang/behavioral-model includes the virtual simple_switch software to run packets thru.  

Regarding item 2, I agree it’s good work and also challenging.  P4 is not the best language to maintain state.  After all, P4 was designed for forwarding packets over 6 Tbps.  P4 uses registers to maintain state.  I will add notes to the wiki for how to maintain state using P4 registers with example of p4-16 code. 

Thanks,

Hemant

From: Hejianfei (Jeffrey) <[email-masked]> 
Sent: Sunday, June 16, 2019 10:23 PM
To: Marie-Jose Montpetit <[email-masked]>; [email-masked]
Cc: Schooler, Eve M <[email-masked]>; [email-masked]
Subject: 答复: [Coin] Draft minutes - COINRG interim meeting - 2019-06-07

1.	Tool kit: I tend to agree with Hemant to use P4C compiler and bmv2 as the behavioral model for the P4 software switch.  We can generate virtual ports from Linux, connect these ports to this P4 software switch, use tools(e.g scapy + wireshark) to send and check the in/out packets of the switch to test if it works correctly. Then, every team in this hackathon only need a server or Virtual machine to run these software?
2.	We also need some tasks for the teams to select and challenge, right? The attractive part of P4 and programmable switches to me is essentially to process packets in a “stateful”/correlated way. then, according to 

we may have 4 quadrants: 

My two cents,

Jianfei(Jeffrey)

发件人: Marie-Jose Montpetit [mailto:[email-masked]] 
发送时间: 2019年6月14日 22:40
收件人: [email-masked] <mailto:[email-masked]> 
抄送: Schooler, Eve M <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Hejianfei (Jeffrey) <[email-masked] <mailto:[email-masked]> >
主题: Re: [Coin] Draft minutes - COINRG interim meeting - 2019-06-07

Thanks for this.

 

mjm

 

On Jun 14, 2019, at 10:24 AM, <[email-masked] <mailto:[email-masked]> > <[email-masked] <mailto:[email-masked]> > wrote:

From: Coin < <mailto:[email-masked]> [email-masked]> On Behalf Of Schooler, Eve M
Sent: Friday, June 14, 2019 3:29 AM
To:  <mailto:[email-masked]> [email-masked]
Cc: Schooler, Eve M < <mailto:[email-masked]> [email-masked]>; Marie-Jose Montpetit < <mailto:[email-masked]> [email-masked]>; Hejianfei (Jeffrey) < <mailto:[email-masked]> [email-masked]>
Subject: [Coin] Draft minutes - COINRG interim meeting - 2019-06-07

P4 Hackathon

-----------------

<hs> Boston hackathon, which I attended for the whole day, did have a unified environment – all of us used p4lang/p4c (open-source P4 compiler).  All of us in Boston who wrote P4 programs hit the ground running with p4lang/p4c.  Thus, even, we spent time on ideas, not tools.   We had over 19 years of data plane programming experience at Boston.  MNK Consulting ( <http://mnkcg.com/> http://mnkcg.com ) with > 13 years of Cisco pxf, Cisco QFP,  Cavium Xpliant data planes, and P4 experience since Fall 1996.  Juniper was there with 6 years data plane programming.  Now, MNK Consulting has Barefoot Tofino experience as well – I am working remotely on Saturday and available for help  via the P4 Slack channel (userid: Hemant).

We should get more ideas – please add them to the wiki:  <https://trac.ietf.org/trac/ietf/meeting/wiki/105hackathon> https://trac.ietf.org/trac/ietf/meeting/wiki/105hackathon  

Hemant