Dear Soheil, > We are in the design phase and investigating different platforms to see which > one might be used in our scenario. Here, I don't wannna discuss the > characteristics of a software router solution we all already know that! But > simply one of the key properties of a software solution like VPP should be > the flexibility that it brings up to the table, which in this case it doesn't. > > Encapsulation techniques won't work in our scenario, because NFVs might be > third party solutions which expect generally IPv4 packets as their input. So > any change like encapsulation causes problem for them. > > Regarding the dynamic header insertion (in this case IP-option) and > standardization, actually as you know there are already standards defining > the structure like the old one: RFC 781. Recently there are effort from > facebook, Barefoot and other guys out there for extending the concept of > Packet-telemetry using all these available (if we can still say this word!) > options.
No, RFC781 does not indicate support for header insertion (if all RFCs could be that brief! ;-)). There is no support in the IP architecture for inserting neither IP4 or IP6 options/extension headers by intermediate nodes in the network. There are _proposals_ for doing that, but those do not have consensus as of now. The main issues with header insertion (non-exhaustive list) are: - fundamentally breaks PMTUD - leads to source host receiving ICMP errors on parts of the packet it knows nothing about - breaks AH It might be possible to do this in constrained environments, although the IETF argument is always that "packets leak". A proposal to do this does have to say something about the three issues above at least. > The key idea is that when you own the network, you need to have mechanisms to > to measurements and why not doing it in dataplane in high speed/low cost > compared to control plane. > > So would you please confirm (or anyone who knows about the future plan of > VPP) that VPP won't support header option (which already is defined for Ipv4 > and other ones) or dynamic packet header sizes if you will. I idly tried this in scapy, but couldn't very much replying apart from my first-hop router. ;-) p = sr1(IP(dst="8.8.8.8", options=IPOption())/ICMP()) Now, all this said... I understand the temptation of the solution and while I think it is likely a bad idea, and likely undeployable, nothing would stop you from trying it out in VPP if you like. There is some code that assumes the TCP header follows a 20 byte IP header, but that could easily dealt with for a prototype. I think I'd like to see where the industry would be going with this before favouring any upstreaming of such a change though. Also note, that NIC offloading features are unlikely to work. Any feature like the classifier, which uses vector instructions on fixed offsets in packets will not be easily reworked and that the extra header size might lead to the header bleeding into another cache line and this will have performance consequences. Best regards, Ole
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
