The 2005 paper that Dave references has an unusual union of Abstract and Conclusions. The abstract states:
>Surprisingly, our findings indicate that it is feasible to restore support for options in the wide-area. I read that expecting to see some magic technical solution in the conclusion. The magic solution is for the operators of edge routers to stop disabling option processing. If the current year were 2005, then I'd say that the paper does not support the VPP approach. But being that Soheil you mention IOAM, the draft you refer to itself refers to a draft https://tools.ietf.org/html/draft-brockners-inband-oam-transport-03#page-6 that tells me that a GRE header is used for encapsulation -- I guess that is what Ole you are describing. So that is the best way to go? [In other words, option processing is not involved.] [Admittedly I have not been following this stuff closely.] I forget the correct name, although I'm sure there is one, but I think there should be a qualification document that states explicitly that part of an RFC will not be supported. No loosey goosey just ignoring an RFC document that has not been obsoleted, even if that is what everybody else is doing. Keep it formal. Burt On Thu, Jun 29, 2017 at 3: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
