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
