Protocol Independent Switch Architecture
barefootnetworks.com
barefootnetworks.com
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);
}
1: https://en.wikipedia.org/wiki/P4_(programming_language) 2: http://p4.org/code/
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 (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
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.
Reassembly could be, but luckily it doesn’t happen on the switch/router, but on the end host.
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.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
First, getting code into the data plane opens up the entire network to new attacks or at least makes them far easier. For instance, just knowing the bytes that are traversing the network gives you a lot of information about what applications are doing, regardless of application encryption. [See https://news.ycombinator.com/item?id=14070130 for an enjoyable discussion.] In short this would undo the benefits of strategies like micro-segmentation.
Second, a lot of backend traffic is unencrypted because managing the crypto infrastructure (e.g., managing X509 certs, keeping up ciphers, staying fully patched) is a pain in the tail when you have communication between hundreds or thousands of services. Individual services can do it, yes, but as far as I can tell there's no general solution for managing application-level security across diverse services. My current employer is pretty sophisticated about enterprise security but we really struggle with this problem. At some point you just say some parts of the network are trusted.
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?
[1]:https://barefootnetworks.com/white-paper/the-worlds-fastest-...
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.
My point is that a networking department for a wall street firm would know that there were more tools available than ping and traceroute.
Very nice piece of semi-technical writing.
http://p4.org/html5boxplayer.swf - 404 not found
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.
I don't have Flash (using Chromium; never installed it), so the page used HTML5. Looks like they need to invert the prioritization!!
The places for the traditional giant carrier boxes are, and probably will be, wonky interface/proto/feature support beyond eth & routed IP.
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.
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.
>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.
Here's a nice "readable" version https://app.printfriendly.com/print?source=homepage&url_s=uG...