Pet peeve: when talking about a new programming language in a technical context, show some code!

But the super-long page of course doesn't, and neither does the Wikipedia page [1]. Also the CODE-tab on the P4 site [2] fails at first glance ... getting frustrating but I bet the site is the right place to dig. Hang on ... Aha, it was on the front page! THANK YOU, P4 web people!

Here's a snippet, then:

    table routing {
      reads {
        ipv4.dstAddr : lpm;
      }
      actions {
        do_drop;
        route_ipv4;
      }
      size: 2048;
    }

    control ingress {
      apply(routing);
    } 

I don't know anything about large-scale network programming, but at least it's nice to get a hint of the concepts that the language deals with. Makes it more concrete, to me.

1: https://en.wikipedia.org/wiki/P4_(programming_language) 2: http://p4.org/code/

Wow, this article is extremely disingenuous with the notion that P4 is the first vendor-agnostic way to control forwarding behavior in switches. OpenFlow has been around for years now and is a vendor agnostic way to control forwarding behavior and it allows packet injection as well.

I get that a startup has to pretend this is a huge foundational advancement, but P4 is really an incremental improvement to the state of SDN that openflow brought. Disappointing that they don't even acknowledge it once.

OpenFlow and P4 address different levels of abstraction in switching.

OpenFlow (in its original form, for simplicity's sake) says "Hey, we have a match/action table with these 12 fields. Here's a way to put stuff in those fields and the switch will match and act accordingly."

P4 says "Hey, we have this piece of programmable silicon. Feel free to define the sorts of tables you want, the protocols you want to switch on, and we'll then give you tables and an API to program."

You can write an OpenFlow pipeline in P4.

Also, maybe take a look at the original OpenFlow paper [1] and the original P4 paper [2]. Nick McKeown, one of Barefoot's cofounders, is an author on both.

[1]: http://ccr.sigcomm.org/online/files/p69-v38n2n-mckeown.pdf [2]: http://yuba.stanford.edu/~nickm/papers/v44n3k2-bosshartA.pdf

Yes, different levels of abstraction but P4 is not a foundational beginning of SDN like this post makes it out to be.

Packet injection, etc were already possible with OpenFlow and this article pretends P4 is the first thing to enable that.

P4 can certainly allow much more than openflow, but some of the use cases this article pretends like P4 is the first to solve were already solved by openflow, etc.

Would you consider this as "huge foundational advancement"?

Can this handle IP fragmentation? I know it can process layer 3 headers (or layer 4, etc.) but am wondering about other layer 3 functionality.

AFAIK fragmentation is usually not a problem for switches/routers.

Reassembly could be, but luckily it doesn’t happen on the switch/router, but on the end host.

According to wikipedia, routers do it. Is this wrong? (Sincerely asking not begin argumentative)

https://en.wikipedia.org/wiki/IP_fragmentation

    In IPv4, routers perform fragmentation, whereas in IPv6, routers do not fragment, but drop the packets that are larger than their MTU.

Routers absolutely do fragment packets (...at least those that don't have the DF bit set) but it's up to the receiving host to reassemble the fragments.

Yes. And it’s not a problem. Reassembly can be a problem, but it’s usually not done on the router.

Maybe I missed it but where's the discussion of security issues and how to prevent code tampering within programmable switches? It's great to be able to program the data plane on demand to trace problems but this also opens up a huge opportunity for technically astute evildoers. I would expect at the very least to see some discussion of risks as well as possible solutions like code signing or secure enclaves but this seems to be absent from both the white paper as well as the cited sources.

In contrast other efforts on networking like Martin Casado's Sane work [1] and OpenFlow [2] explicitly addressed security issues up front.

[1] http://yuba.stanford.edu/ethane/sane.pdf [2] http://archive.openflow.org/documents/openflow-wp-latest.pdf

Switches are already programmable to a degree. This is out of scope -- and yes, it's slightly worse than the existing story, but not that much worse. I believe, as a community, we've decided that trusting the transport is a bad idea.

p.s., Did I mention denial-of-service attacks? All you need is intermittent failures in packet forwarding to sow chaos.

How does Barefoot plan to position themselves?

Do the plan to compete had to head with Cisco and Arista in the datacenter segment with this switch?

Or do they see themselves more as Broadcom competitors, and the their switch is a reference implementation for their chips?

There's a section 'Is Barefoot a systems company, a software company or a chip company?'[1] which talks about this.

[1]:https://barefootnetworks.com/white-paper/the-worlds-fastest-...

NVIDIA for networks sounds like a good pitch.

"the networking team only had ping and traceroute"

Thats idiotic. There have been lots of ways to generate health, performance, and usage signals for years. Netflow being a huge omission.

this is marketing.

Yeah, this is basically the IT version of those TV ads for some tool better than a standard tool where it demonstrates the "normal person" using it like a complete idiot to show how much better the new tool is.

I thought that was a very well written whitepaper: clearly explains the problem, why it needs solving, what their solution is and why it's a good solution.

Very nice piece of semi-technical writing.

There's a spelling mistake on the architectural diagram (figure two): "PRASER" instead of "PARSER", I assume.

But can you generate ICMP DF-set-and-fragmentation-needed packets with this?

the control (or management) plane generates packets. a dataplane does not generate packets; it ingests and expels packets.

And THIS is why people disable ICMP generation on routers. Which then breaks any systems that don't implement ICMP-less PMTUD. Ugh!!

Tried to watch the video about P4 at p4.org, but it failed with

    http://p4.org/html5boxplayer.swf - 404 not found

The P4 language is interesting. There are little programs, like shaders, which run for each packet. Presumably many units are running these programs in parallel. These programs can read tables set by the "control plane", a more conventional CPU, and can pass a packet to the control plane. That's similar to large routers today, but here, the lower level hardware is more flexible.

It seems sufficient for writing a router, but not, say, a stateful middlebox like a firewall or a SSL/TLS decoder. It seems designed for "software defined networking". The P4 programs detect that a packet isn't in a table that tells what to do with it, and pass that packet to the control plane. The control plane sets a table to handle routing for that flow, and, thereafter, packets from that flow are handled by the low-level system.

This is a threat to Cisco, Brocade, etc. in that it defines a generic architecture for commodity routing hardware.

The notion of a customizable table of packet matchers and actions is not new with P4. OpenFlow already enables this but the openflow API made it difficult to fully replicate common behaviors of legacy hardware (e.g. ARP).

>This is a threat to Cisco, Brocade, etc. in that it defines a generic architecture for commodity routing hardware.

I'm not so sure about this. OpenFlow and whitebox switches in general already cannibalized the market of customers that would have enough expertise to use P4. It will be interesting to see what customers P4 attracts that whitebox switching already hasn't.

The play button image is actually a link to http://p4.org/wp-content/uploads/2015/04/p4-demo-video-full.... [mp4; 41,439,148 bytes]

I don't have Flash (using Chromium; never installed it), so the page used HTML5. Looks like they need to invert the prioritization!!

It's a PowerPoint/Flash presentation, blown up to 41MB by making it into a video. It's essentially the same content as the P4.org paper.

...Right. I had no idea. Heh.

I havent played in this space for a year or three, but isnt this basically what everyone is doing for fixed port boxes? The os and routing daemons run on a set of low power xeons with a "bunch" of ram (RIB). That pushes forwarding down to the tomahawk et al asic (FIB). Unknown flows are punted up to the os, and possibly a remote controller (SDN). I thought this was already given inside the DC fabric, and becoming established for interconnect.

The places for the traditional giant carrier boxes are, and probably will be, wonky interface/proto/feature support beyond eth & routed IP.

Yes, the thing this replaces is basically the proprietary Broadcom API down at the switch level.

on the tofino chip, yes. what would be the broadcom api on a tomahawk, a P4-based toolchain is for tofino.

P4 is a domain-specific language for packet dataplanes. you can represent the various packet processing pipelines in a broadcom switch chip in P4. broadcom could easily build a P4 to tomahawk API.

P4 has tried very hard to be target independent. there are toolchains targeting GPUs, vSwitches, and FPGAs. you can compile P4 to eBPF.

Can this be tested on consumer level Broadcom SoCs like Linksys routers?

It would be an interesting approach to hardening them, by eliminating the OS and much of the attack surface.

This might require that it support wireless frames though, and maybe radio, MIMO, diversity if those aren't too far out of scope.

not until Broadcom provides a toolchain and writes a P4 backend.

TLDR: Barefoot’s Tofino is a 6.5Tb/s (65 x 100GE or 260 x 25GE) fully user-programmable switch.

Scroll hijacking 2.0. We capture your scroll and make it impossible for you to go back to HN quickly because every scroll action was performed as a navigation action and pushed to your history...

Thanks for avoiding me a bit of cringe.

Here's a nice "readable" version https://app.printfriendly.com/print?source=homepage&url_s=uG...

"Names including the letter i", right?