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
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
easi
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,
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 solut
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,
-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 scen
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
&g
2.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
>> *
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
gt; 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:* T
-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: [v
> 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 iptab
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?
We, as a communication operator, need to know this issue, because we want to
use VPP as high-loaded NAT instead of iptables.
Thanks!
--
Yours sincerely,
Denis
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 ma
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
s.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
> *
] 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
mailto:otr...@employees.org>> wrote:
Soheil,
Others my correct me, but as far as I know IPv4 options
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 forwa
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
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
fiel
21 matches
Mail list logo
