Ole, 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. 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. Thanks, Soheil On Thu, Jun 29, 2017 at 12:57 PM, Ole Troan <otr...@employees.org> wrote: > Soheil, > > > That paper only shows that "in their experiments they saw that half of > the routers in INTERNET drop the packets with IPv4-Option", but > measurements targeted for the path of packets in internet is just a use > case. > > > > Think about different third party NFV containers running on our private > datacenter to process the incoming packets (even from internet or where > ever!) and usage of VPP as software switch/router/processing-point under > those containers. > > > > Now use of IPv4 iOAM to get some local performance measurements in this > private network (which usually gets Ipv4 packets as input) makes sense. So > IMO saying that half of "their" tested routers doesn't support ipv4 options > doesn't seem a good reasoning for not supporting IPV4 option in VPP. > > > > Ole, > > > > It's not obsoleted. As Burt mentioned it's still part of the standard. > Even recent ietf drafts are considering this feature. For instance look at > https://tools.ietf.org/html/draft-brockners-inband-oam-data-04 > > Lots of features in RFC791 that aren't deployed anymore or deployable. > No-one has bothered to go around and clean up the document. > > > VPP already supports iOAM for IPv6 which is I guess base on the > available IOS solution for IPv6 from Cisco. We were going to add Ipv4 iAOM > functionality to VPP; however, from what you're saying I feel there won't > be support for accepting IPv4-Options in VPP in future, and it seems that > there is no solid reasoning behind that decision, am I right? > > I'm the co-chair of the 6MAN working group in the IETF. We have spent > about a year and a few thousand email messages discussing the merits of > header injection for IPv6. Which I presume you are proposing here? The > consensus is that neither for IPv4 nor IPv6 is there any support in text > for changing a packets size in flight (aka inserting options / headers). > Inserting at source is not a problem of course. But removing it at exit is. > > You can of course propose to do something new with IPv4. Just note that > with IPv4 exhaustion the IPv4 address space has bled into the transport > layer. The IPv4 header is now essentially a fixed header of 28 bytes. > Address and TCP/UDP ports. > > You can do this many different ways. Encapsulation for example. > > This sounds like something would require some level of standardisation. > Have you written your ideas up? > > Cheers, > Ole >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
