Re: [vpp-dev] IPv4 Option field

[Soheil Abbasloo]

I guess you are right, there was a misunderstanding, though in both cases
lack of support from the router will lead to the same result, drop of
packets! The guys who argue that it is not a good idea might say that from
routers point of view generally there would be no difference between the
case that the insertion of Option has been done by its previous router or
by the source of the packet.

However, if we are managing our network, the idea of having an option in
routers to select between processing or not processing the packets with
IP-option still makes sense, because you can dictate which routers should
expect IP-options and which ones should not. That is all about how you are
going to manage them, and the amount of flexibility that you have.

Let's not forget that the IP layer was not intended to be an end-to-end
layer. Even for L4 which was primarily defined to be an end-to-end Layer,
the trend in today's networks is to violate that end-to-end nature for the
sake of performance (as an example look at the usage of DCTCP in Microsoft,
Google and other datacenters which violates the end-to-end nature of TCP
and marks L4 headers in the network by switches).

Unfortunately (or fortunately) VPP is just a tool and its marketing
concerns gets higher priority. ;)

Thanks
Soheil


On Fri, Jun 30, 2017 at 3:37 PM, Burt Silverman  wrote:

> Just to be clear, Soheil, are you fine with the idea that the options like
> timestamp are only added at the origination node? Your use of the word
> "inject" made some people believe that you expected intermediate nodes to
> add an option, based on the replies I see on this list. Perhaps, by
> "inject" you just meant that you can get a set of routers/switches,
> including VPP, that process the option and forward the packet, as opposed
> to dropping the packet. That would be nice, being that Joel and Ole pointed
> out that the other choice is not supported by the standards.
>
> Happy prototyping -- or whatever comes to pass.
>
> Burt
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_3541350063443403557_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Fri, Jun 30, 2017 at 2:08 PM, Soheil Abbasloo 
> wrote:
>
>> Thanks Burt, good hint. However, the problem they try to solve doesn't
>> happen in all scenarios.
>>
>> Consider a simple case: Say we are Verzion and want to do some
>> measurements in "our" owned network. Packets having IP-options can be
>> dropped at the edge of the network to prevent security issues, "but" in our
>> network we need the "Option" to configure routers/switches to inject
>> desired options at desired points in the network.
>>
>> Basically, what all of these documents want to prevents is preventing the
>> END-USER to do some scary jobs! So accepting option field in headers of
>> packets (as an example) in our network which is controlled by US should be
>> a simple available feature in software solutions.
>>
>> Thanks,
>> Soheil
>>
>> On Fri, Jun 30, 2017 at 6:52 AM, Burt Silverman  wrote:
>>
>>> I discovered the "formal document" that addresses part of the situation:
>>> RFC 7126 Filtering of IP-Optioned Packets is a Best Current Practice,
>>> and it recommends that timestamp optioned IPv4 packets be dropped. They
>>> recognize that this breaks network troubleshooting techniques, but the
>>> feeling is that those are already broken, and there are security issues
>>> associated with the timestamp option.
>>>
>>> On the other hand, I believe there are options that they believe should
>>> be handled. So I am not sure that testing the header size byte for 0x45 is
>>> best practice, but I have not given RFC 7126 a thorough read through.
>>>
>>> Burt
>>>
>>> On Fri, Jun 30, 2017 at 4:05 AM, Andrew Yourtchenko 
>>> 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/catalyst45
 00/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  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.

Re: [vpp-dev] IPv4 Option field

[Burt Silverman]

Just to be clear, Soheil, are you fine with the idea that the options like
timestamp are only added at the origination node? Your use of the word
"inject" made some people believe that you expected intermediate nodes to
add an option, based on the replies I see on this list. Perhaps, by
"inject" you just meant that you can get a set of routers/switches,
including VPP, that process the option and forward the packet, as opposed
to dropping the packet. That would be nice, being that Joel and Ole pointed
out that the other choice is not supported by the standards.

Happy prototyping -- or whatever comes to pass.

Burt


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, Jun 30, 2017 at 2:08 PM, Soheil Abbasloo 
wrote:

> Thanks Burt, good hint. However, the problem they try to solve doesn't
> happen in all scenarios.
>
> Consider a simple case: Say we are Verzion and want to do some
> measurements in "our" owned network. Packets having IP-options can be
> dropped at the edge of the network to prevent security issues, "but" in our
> network we need the "Option" to configure routers/switches to inject
> desired options at desired points in the network.
>
> Basically, what all of these documents want to prevents is preventing the
> END-USER to do some scary jobs! So accepting option field in headers of
> packets (as an example) in our network which is controlled by US should be
> a simple available feature in software solutions.
>
> Thanks,
> Soheil
>
> On Fri, Jun 30, 2017 at 6:52 AM, Burt Silverman  wrote:
>
>> I discovered the "formal document" that addresses part of the situation:
>> RFC 7126 Filtering of IP-Optioned Packets is a Best Current Practice,
>> and it recommends that timestamp optioned IPv4 packets be dropped. They
>> recognize that this breaks network troubleshooting techniques, but the
>> feeling is that those are already broken, and there are security issues
>> associated with the timestamp option.
>>
>> On the other hand, I believe there are options that they believe should
>> be handled. So I am not sure that testing the header size byte for 0x45 is
>> best practice, but I have not given RFC 7126 a thorough read through.
>>
>> Burt
>>
>> On Fri, Jun 30, 2017 at 4:05 AM, Andrew Yourtchenko 
>> 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/catalyst45
>>> 00/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  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 
 *Cc:* Soheil Abbasloo ; vpp-dev <
 vpp-dev@lists.fd.io>
 *Subject:* Re: [vpp-dev] IPv4 

Re: [vpp-dev] IPv4 Option field

[Soheil Abbasloo]

Ole,

> 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.

Regarding the VPP modification I thought that you said: "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..."  ;)

BTW, good points from you.

Thanks
Soheil


On Fri, Jun 30, 2017 at 1:12 PM, Ole Troan  wrote:

> 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
>
>
>
>
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] IPv4 Option field

[Joel Halpern]

Ole, I was taking the permissive view, which has often been taken with IPv4.  
Your argument that the specs do not permit insertion even in v4 is quite 
defensible.  My point was that even if it is permitted, it is such a bad idea 
that we do not want to go there.

Also, just for clarity, I agree with you that it is not permitted in v6.  And I 
consider it a dangerous practice in both places.
As you point out, the argument "my network, my rules" fails in the face of the 
repeated evidence that things will leak out of anyones network.

Yours,
Joel

-Original Message-
From: Ole Troan [mailto:otr...@employees.org] 
Sent: Friday, June 30, 2017 3:59 PM
To: Joel Halpern 
Cc: Soheil Abbasloo ; Burt Silverman ; 
vpp-dev 
Subject: Re: [vpp-dev] IPv4 Option field

Joel,

At the risk of turning this into the IETF list.

> The issue is that many existing routers will drop, or if you are very lucky 
> slow-path, and IP4 packets with options.
> Yes, the specification allows such options.  The IPv4 specs even allow adding 
> and removing such options.
> However, because of issues like ECMP / LAG support, such options have been 
> observed not to work.

We have been over this a few times with regards to the IPv6 header insertion 
proposals.
I have seen no support for the statement "the IPv4 specs even allow adding and 
removing such options", if by that you mean adding or removing options by 
intermediate nodes along the packets forwarding path.
What the IPv4 RFCs allow is changing options en-route (so does IPv6), but that 
requires the host to insert the scratch space, i.e. the option at source. Happy 
to be proven wrong, but Bob and I thought we went over the "history" here quite 
a few times...

> Thus, while there may be some cases where they can be made useful, it 
> requires great care in many other aspects of the network.
> Depending upon what measurements are needed, there are other ways to get the 
> needed information even in data centers.

Best regards,
Ole

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] IPv4 Option field

[Ole Troan]

Joel,

At the risk of turning this into the IETF list.

> The issue is that many existing routers will drop, or if you are very lucky 
> slow-path, and IP4 packets with options.
> Yes, the specification allows such options.  The IPv4 specs even allow adding 
> and removing such options.
> However, because of issues like ECMP / LAG support, such options have been 
> observed not to work.

We have been over this a few times with regards to the IPv6 header insertion 
proposals.
I have seen no support for the statement "the IPv4 specs even allow adding and 
removing such options", if by that you mean adding or removing options by 
intermediate nodes along the packets forwarding path.
What the IPv4 RFCs allow is changing options en-route (so does IPv6), but that 
requires the host to insert the scratch space, i.e. the option at source. Happy 
to be proven wrong, but Bob and I thought we went over the "history" here quite 
a few times...

> Thus, while there may be some cases where they can be made useful, it 
> requires great care in many other aspects of the network.
> Depending upon what measurements are needed, there are other ways to get the 
> needed information even in data centers.

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

Re: [vpp-dev] IPv4 Option field

[Joel Halpern]

The issue is that many existing routers will drop, or if you are very lucky 
slow-path, and IP4 packets with options.
Yes, the specification allows such options.  The IPv4 specs even allow adding 
and removing such options.
However, because of issues like ECMP / LAG support, such options have been 
observed not to work.

Thus, while there may be some cases where they can be made useful, it requires 
great care in many other aspects of the network.
Depending upon what measurements are needed, there are other ways to get the 
needed information even in data centers.

Yours,
Joel

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Soheil Abbasloo
Sent: Friday, June 30, 2017 2:09 PM
To: Burt Silverman 
Cc: vpp-dev 
Subject: Re: [vpp-dev] IPv4 Option field

Thanks Burt, good hint. However, the problem they try to solve doesn't happen 
in all scenarios.

Consider a simple case: Say we are Verzion and want to do some measurements in 
"our" owned network. Packets having IP-options can be dropped at the edge of 
the network to prevent security issues, "but" in our network we need the 
"Option" to configure routers/switches to inject desired options at desired 
points in the network.

Basically, what all of these documents want to prevents is preventing the 
END-USER to do some scary jobs! So accepting option field in headers of packets 
(as an example) in our network which is controlled by US should be a simple 
available feature in software solutions.

Thanks,
Soheil

On Fri, Jun 30, 2017 at 6:52 AM, Burt Silverman 
> wrote:
I discovered the "formal document" that addresses part of the situation: RFC 
7126 Filtering of IP-Optioned Packets is a Best Current Practice, and it 
recommends that timestamp optioned IPv4 packets be dropped. They recognize that 
this breaks network troubleshooting techniques, but the feeling is that those 
are already broken, and there are security issues associated with the timestamp 
option.
On the other hand, I believe there are options that they believe should be 
handled. So I am not sure that testing the header size byte for 0x45 is best 
practice, but I have not given RFC 7126 a thorough read through.
Burt

On Fri, Jun 30, 2017 at 4:05 AM, Andrew Yourtchenko 
> 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 
> 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) 
> 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 >
Cc: Soheil Abbasloo >; vpp-dev 
>
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 
> wrote:

Re: [vpp-dev] IPv4 Option field

[Soheil Abbasloo]

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 
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  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)  > 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 
>> *Cc:* Soheil Abbasloo ; vpp-dev > >
>> *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  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  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 

Re: [vpp-dev] IPv4 Option field

[Soheil Abbasloo]

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  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

Re: [vpp-dev] Buffer allocation failure

[Alessio Silvestro]

Thanks for the help, it works!

Alessio

On Fri, Jun 30, 2017 at 3:29 PM, Dave Barach (dbarach) 
wrote:

> +1... Thanks… Dave
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *Luke, Chris
> *Sent:* Friday, June 30, 2017 8:29 AM
> *To:* Alessio Silvestro ; vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] Buffer allocation failure
>
>
>
> The packet you receive, what do you do with it?
>
>
>
> If you don’t forward it, you have two choices:
>
>
>
>- You could deallocate its buffer.
>- Or, better, recycle it and use that packets buffer for your outgoing
>packet. That way you avoid the expense of allocating a new one.
>
>
>
> Chris.
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io
> ] *On Behalf Of *Alessio Silvestro
> *Sent:* Friday, June 30, 2017 8:25
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] Buffer allocation failure
>
>
>
> Dear vvp-dev,
>
>
>
> I developed a new vpp node that listen for UDP traffic on a specific port,
> then, for each received packet, create a new buffer and send an UDP packet
> to the source IP address.
>
>
>
> The application is running fine, but when I send some thousands of
> packets, at some point vpp starts to give "buffer allocation failure" error.
>
>
>
> Where do you think could be the problem.
>
>
>
> Is the node not correctly de-allocating the buffer or there is some
> specific vpp and/or system configuration that can cause this problem?
>
>
>
> Best regards,
>
> Alessio
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] VPP API / CLI, shared memory vs trivial method.

[Dharmaray Kundargi]

Why is shared memory is not considered between client(slowpath) and VPP 
fastpath to pass on the arguments to create session and use vlib API to issue 
create command pass on the handler/index_into_shared memory to VPP fastpath.
I believe that would help in bit complex use cases where there are more 
parameters for a session (lets' say complex ACL rules).


Regards
Dharmaray S Kundargi

Please Note: My email address is changing. Starting May 1st 2017 my email will 
solely be my Mavenir email firstname.lastn...@mavenir.com. All other prior 
email accounts will become inactive. To ensure continuity, please send all 
emails to my Mavenir email ID which is currently active and available for use.


This e-mail message may contain confidential or proprietary information of 
Mavenir Systems, Inc. or its affiliates and is intended solely for the use of 
the intended recipient(s). If you are not the intended recipient of this 
message, you are hereby notified that any review, use or distribution of this 
information is absolutely prohibited and we request that you delete all copies 
in your control and contact us by e-mailing to secur...@mavenir.com. Thank You. 
This message contains the views of its author and may not necessarily reflect 
the views of Mavenir Systems, Inc. or its affiliates, who employ systems to 
monitor email messages, but make no representation that such messages are 
authorized, secure, uncompromised, or free from computer viruses, malware, or 
other defects.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] Buffer allocation failure

[Luke, Chris]

The packet you receive, what do you do with it?

If you don’t forward it, you have two choices:


  *   You could deallocate its buffer.
  *   Or, better, recycle it and use that packets buffer for your outgoing 
packet. That way you avoid the expense of allocating a new one.

Chris.

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Alessio Silvestro
Sent: Friday, June 30, 2017 8:25
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Buffer allocation failure

Dear vvp-dev,

I developed a new vpp node that listen for UDP traffic on a specific port, 
then, for each received packet, create a new buffer and send an UDP packet to 
the source IP address.

The application is running fine, but when I send some thousands of packets, at 
some point vpp starts to give "buffer allocation failure" error.

Where do you think could be the problem.

Is the node not correctly de-allocating the buffer or there is some specific 
vpp and/or system configuration that can cause this problem?

Best regards,
Alessio
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] IPv4 Option field

[Andrew Yourtchenko]

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  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)  
>> 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 
>> Cc: Soheil Abbasloo ; vpp-dev 
>> 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  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  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

[vpp-dev] Need some help on VPP

[Mahesh Ishwar Mathad]

Hi all,

Thanks for support.

I need to know why *vlib_node_runtime_t *nodes_by_type[4]* in 
structure*vlib_node_main_t*. I am really not understanding what is usage 
of*runtime nodes*.


On Monday 05 June 2017 11:26 PM, Dave Barach (dbarach) wrote:


I stand corrected, at least in a general sense... ()...

Thanks… Dave

*From:* vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] *On Behalf Of *Damjan Marion

*Sent:* Monday, June 5, 2017 1:34 PM
*To:* Dave Wallace 
*Cc:* Mahesh Ishwar Mathad ; 
vpp-dev@lists.fd.io

*Subject:* Re: [vpp-dev] Need some help on VPP

Actually not :)

We dropped dependency on dpdk ptype due to history of issues and lack 
of mpls ptype and we purely rely on ethertype.


From the metadata only thing we use today is ip4 hdr checksum.

On 5 Jun 2017, at 14:56, Dave Wallace > wrote:


To be pedantic, the VPP dpdk-input node checks the classification
metadata for each packet which was set by DPDK and decides whether
to bypass the ethernet-input node.

Thanks,
-daw-

On 6/5/2017 3:23 AM, Nagaprabhanjan Bellari wrote:

DPDK can be thought of as a device driver - there can be
multiple device drivers - tap interface handler is also,
technically, a device driver. So are the host-if, ssvm etc.
etc. Their job is to collect packets from their respective
"media" (a physical interface for dpdk, kernel for tap, shared
memory for ssvm etc.) and hand them off to VPP.

DPDK essentially collects the packets and feeds them to the
VPP forwarding engine. VPP will then start parsing the packet.
It so happens that DPDK does some optimization and directly
feeds the packet to IP rather than to the ethernet node in the
graph (because Intel adapters can validate IP checksum etc.).
Without optimization (for other device drivers) the packets go
to ethernet input and gets processed from byte 0 of the packet.

Hope this helps.

Thanks,

-nagp

On Mon, Jun 5, 2017 at 11:59 AM, Mahesh Ishwar Mathad
> wrote:

Thanks for the great support.

The VPP platform grabs all available packets from RX rings
to form a
vector of packets. These vector of packets who will
classify these
packets either DPDK or VPP ?. If it is VPP how VPP will
classify packet
because what I am thinking for every packet VPP is
decapsulating to know
which packet actually it is, that particular packet is
sent to the
respected node. By this doing this mechanism VPP is simply
wasting
machine cycle. If my thinking is worng, please tell me
which algorithm
is this VPP is following so that i can understand.

-- 
Thanks & Regards,

Mahesh Mathad.

Disclaimer:- The information contained in this electronic
message and any attachments to this message are intended
for the exclusive use of the addressee(s) and may contain
proprietary, confidential or privileged information. If
you are not the intended recipient, you should not
disseminate, distribute or copy this e-mail. Please notify
the sender immediately and destroy all copies of this
message and any attachments. The views expressed in this
E-mail message (including the enclosure/(s) or
attachment/(s) if any) are those of the individual sender,
except where the sender expressly, and with authority,
states them to be the views of GlobalEdge. Before opening
any mail and attachments please check them for viruses
.GlobalEdge does not accept any liability for virus
infected mails.

___
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



--
Thanks & Regards,
Mahesh Mathad.


Disclaimer:- The information contained in this electronic message and any 
attachments to this message are intended for the exclusive use of the 
addressee(s) and may contain proprietary, confidential or privileged 
information. If you are not the intended 

Re: [vpp-dev] IPv4 Option field

[Ole Troan]

> I want to know what this IPv4 Option field affects the end user? Are there 
> any protocols or user programs that stop working without this?

No. Nothing on the Internet.

> We, as a communication operator, need to know this issue, because we want to 
> use VPP as high-loaded NAT instead of iptables.

In RFC7598 and friends we decided not to support IPv4 options at all.

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