Thanks Andrew for the link, Our use case is something like this:
Consider that you have a pool of NFV containers which are connected using a software solution (using Hypervisor, OVS, VPP, or any other approaches). Now from the control point of view we require to have a full knowledge about the behavior of those NFVs. Simple case is the delay that they introduce to the path of a packet. Those NFVs could be third party apps so solution should be transparent for them. One solution might be adding metadata to those packets when they are transferred through the VPP for instance, however, again this requires changing the behavior of copying from Mbuf to socket buffer (or vise versa) in containers which is not desired. Injecting proper info to the packets in In-band structure will be another solution which will be sort of transparent for NFVs. Thanks, Soheil On Fri, Jun 30, 2017 at 1:05 AM, Andrew Yourtchenko <ayour...@gmail.com> wrote: > Soheil, > > Quite some platforms switch the packets with up options in software. An > example: > > http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/31sga/ > configuration/guide/config/mcastmls.html#wp1082100 > > How do you plan to deal with this behavior in the network ? > > --a > > On 29 Jun 2017, at 20:00, Soheil Abbasloo <ab.soh...@gmail.com> wrote: > > Dave, > > 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 > > 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? > > Thanks all, > Soheil > > > > On Thu, Jun 29, 2017 at 11:24 AM, Dave Barach (dbarach) <dbar...@cisco.com > > wrote: > >> I agree with Ole. See https://www2.eecs.berkeley.edu >> /Pubs/TechRpts/2005/EECS-2005-24.pdf >> >> >> >> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On >> Behalf Of *Burt Silverman >> *Sent:* Thursday, June 29, 2017 12:49 PM >> *To:* Ole Troan <otr...@employees.org> >> *Cc:* Soheil Abbasloo <ab.soh...@gmail.com>; vpp-dev <vpp-dev@lists.fd.io >> > >> *Subject:* Re: [vpp-dev] IPv4 Option field >> >> >> >> I believe the standards should be adhered to. RFC791 has not been >> obsoleted. One man's opinion (sentence 1). >> >> Burt >> >> >> >> On Thu, Jun 29, 2017 at 11:11 AM, Ole Troan <otr...@employees.org> wrote: >> >> Soheil, >> >> Others my correct me, but as far as I know IPv4 options are for all >> practical purposes deprecated. >> Lots of forwarding planes do a validation check of 0x45 on the first >> octet. Likewise for middleboxes (e.g. NAT). >> Have you tried if you can get these packets passed any routers / across >> the Internet? >> >> Not impossible to change the IP4 VPP path, although it would require >> fixing all code that finds the L4 header. But I think you would end up in >> horrific deployment issues... >> >> Cheers, >> Ole >> >> >> > On 29 Jun 2017, at 02:21, Soheil Abbasloo <ab.soh...@gmail.com> wrote: >> > >> > Hi all, >> > >> > This is Soheil. We are working on a project involving the IPv4 In-Band >> OAM. >> > >> > I have tried to use VPP in a simple scenario (like the simple >> switching/routing tutorial in fd.io) to pass IPv4-Options (in out case >> TIMESTAMP option) between two containers. However, packets having IP-Option >> field will be dropped by VPP due to the checksum error. >> > >> > I have checked the source code (17.04) and found that VPP only handles >> fixed 20 Bytes IP headers (there is a header size check in ipv4-input node >> {<>!=0x45}). Which might indicate that VPP doesn't handle IP-options; hence >> the source of wrong checksum calculations in VPP. >> > >> > So is there any plan for support IPv4-Option fields in VPP? Is there >> any reason for not supporting it?! Or maybe I'm doing something wrong, can >> you please tell me what I have missed here? >> > >> > ( >> > Just a few things: >> > 1- I have checked checksum calculations in my server where I insert >> IP-options and they are fine! >> > 2- When I don't insert options, everything is fine and packets can be >> received at client >> > ) >> > >> > Thanks, >> > Soheil >> > _______________________________________________ >> > vpp-dev mailing list >> > vpp-dev@lists.fd.io >> > https://lists.fd.io/mailman/listinfo/vpp-dev >> >> >> _______________________________________________ >> vpp-dev mailing list >> vpp-dev@lists.fd.io >> https://lists.fd.io/mailman/listinfo/vpp-dev >> >> >> > > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io > https://lists.fd.io/mailman/listinfo/vpp-dev > >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
