Re: [Coin] P4 Hackathon tools

[Marc LeClerc <[e-mail]>]

Hello all,

Just to be clear we are proposing the use of P4-16 tools, not p4-14. Our development team is well versed in both environments if P4-16 isn’t acceptable.

VBR/Marc

 
Marc LeClerc
VP Strategy and Marketing
NoviFlow Inc.
Tel: [phone]
Mob: [phone]
[e-mail]

www.noviflow.com



> On Jun 17, 2019, at 8:13 AM, [e-mail] wrote:
> 
> Send Coin mailing list submissions to
> 	[e-mail] <mailto:[e-mail]>
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.irtf.org/mailman/listinfo/coin <https://www.irtf.org/mailman/listinfo/coin>
> or, via email, send a message with subject or body 'help' to
> 	[e-mail] <mailto:[e-mail]>
> 
> You can reach the person managing the list at
> 	[e-mail] <mailto:[e-mail]>
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Coin digest..."
> Today's Topics:
> 
>   1. Re: Draft minutes - COINRG interim meeting - 2019-06-07
>      ([e-mail] <mailto:[e-mail]>)
> 
> From: <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Coin] Draft minutes - COINRG interim meeting - 2019-06-07
> Date: June 17, 2019 at 8:13:09 AM GMT-4
> To: "'Hejianfei \(Jeffrey\)'" <[e-mail] <mailto:[e-mail]>>, "'Marie-Jose Montpetit'" <[e-mail] <mailto:[e-mail]>>
> Cc: "'Schooler, Eve M'" <[e-mail] <mailto:[e-mail]>>, <[e-mail] <mailto:[e-mail]>>
> Reply-To: <[e-mail] <mailto:[e-mail]>>
> 
> 
> 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 <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 <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 <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) <[e-mail] <mailto:[e-mail]>> 
> Sent: Sunday, June 16, 2019 10:23 PM
> To: Marie-Jose Montpetit <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Cc: Schooler, Eve M <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
> Subject: 答复: [Coin] Draft minutes - COINRG interim meeting - 2019-06-07
>  
> A few suggestions for the P4 hackathon in Montreal ( chair hat off):
> 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?
> 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/ <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 <http://www.cs.yale.edu/homes/aspnes/pinewiki/ConvergeCast.html?highlight=%28CategoryDistributedComputingNotes%29>)?
> My two cents,
> Jianfei(Jeffrey)
>  
> 发件人: Marie-Jose Montpetit [mailto:[e-mail] <mailto:[e-mail]>] 
> 发送时间: 2019年6月14日 22:40
> 收件人: [e-mail] <mailto:[e-mail]>
> 抄送: Schooler, Eve M <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; Hejianfei (Jeffrey) <[e-mail] <mailto:[e-mail]>>
> 主题: Re: [Coin] Draft minutes - COINRG interim meeting - 2019-06-07
>  
> 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, <[e-mail] <mailto:[e-mail]>> <[e-mail] <mailto:[e-mail]>> wrote:
>  
>  
> From: Coin <[e-mail] <mailto:[e-mail]>> On Behalf Of Schooler, Eve M
> Sent: Friday, June 14, 2019 3:29 AM
> To: [e-mail] <mailto:[e-mail]>
> Cc: Schooler, Eve M <[e-mail] <mailto:[e-mail]>>; Marie-Jose Montpetit <[e-mail] <mailto:[e-mail]>>; Hejianfei (Jeffrey) <[e-mail] <mailto:[e-mail]>>
> Subject: [Coin] Draft minutes - COINRG interim meeting - 2019-06-07
>  
> 
> P4 Hackathon
> -----------------
> 
> 
> 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 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
>  
> 
> 
> Coin mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.irtf.org/mailman/listinfo/coin <https://www.irtf.org/mailman/listinfo/coin>