Subject: RARE user and assistance email list
List archive
- From: "" <>
- To: "Ackermann, Michael" <>, "" <>, mc36 <>
- Cc: Tommaso Pecorella <>, Dhruv Dhody <>, "Mohit P. Tahiliani" <>
- Subject: Re: [RARE-users] [freertr] FreeRtr and Hop-By-Hop header
- Date: Mon, 1 Aug 2022 12:17:17 +0000 (UTC)
- List-id: <freertr.groups.io>
- Mailing-list: list ; contact
Csaba,
Are these PINGs something that comes with FreeRtr? Can your PINGs also do Destination Option header?
Also, can you send me packet traces whenever you do stuff? (I think in pcaps so it helps me!)
We are working to set up directories and an organization structure where we can put all the testing results from various people. I will be back to you with that.
Thanks,
Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360
Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360
On Monday, August 1, 2022 at 01:41:09 AM PDT, mc36 <> wrote:
my bad, i forgot to put the ipv6 knob from the pings.... btw it changed nothing...
br,
cs
rtr1.c4e#ping www.geant.org repeat 111 alert 123 ipv6
2022-08-01 10:33:30
resolving www.geant.org for ipv6 ok!
pinging 2001:798:3::132, src="2001:738::3000:c4e1," vrf=inet, cnt=111, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=123, sweep=false, multi=false
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
result=100.0%, recv/sent/lost/err=111/111/0/0, took 1863, min/avg/max/dev rtt=16/16.6/18/0.2, ttl 58/58.0/58/0.0, tos 0/0.0/0/0.0
rtr1.c4e#
rtr1.c4e#ping www.geant.org repeat 111 ipv6
2022-08-01 10:33:31
resolving www.geant.org for ipv6 ok!
pinging 2001:798:3::132, src="2001:738::3000:c4e1," vrf=inet, cnt=111, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=-1, sweep=false, multi=false
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
result=100.0%, recv/sent/lost/err=111/111/0/0, took 351, min/avg/max/dev rtt=2/2.9/7/1.3, ttl 62/62.0/62/0.0, tos 0/0.0/0/0.0
rtr1.c4e#
rtr1.c4e#ping www.niif.hu repeat 111 alert 123 ipv6
2022-08-01 10:36:47
resolving www.niif.hu for ipv6 ok!
pinging 2001:738:0:420::b, src="2001:738::3000:c4e1," vrf=inet, cnt=111, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=123, sweep=false, multi=false
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
result=100.0%, recv/sent/lost/err=111/111/0/0, took 281, min/avg/max/dev rtt=2/2.3/4/0.2, ttl 60/60.0/60/0.0, tos 0/0.0/0/0.0
rtr1.c4e#
rtr1.c4e#ping www.niif.hu repeat 111 ipv6
2022-08-01 10:36:48
resolving www.niif.hu for ipv6 ok!
pinging 2001:738:0:420::b, src="2001:738::3000:c4e1," vrf=inet, cnt=111, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=-1, sweep=false, multi=false
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
result=100.0%, recv/sent/lost/err=111/111/0/0, took 103, min/avg/max/dev rtt=0/0.7/2/0.2, ttl 60/60.0/60/0.0, tos 0/0.0/0/0.0
rtr1.c4e#
On 8/1/22 10:28, mc36 wrote:
> hi,
>
> as said before, the stuff is out, everyone could test with it after installing freerouter...
>
> as discussed beforehand, there is a penalty on the packets using alter/hbh option, as they go the lc-rp-lc path, as per rfc...
>
> see below two pings, executed from niif/kifu, the local nren, right to the geant.org website...
> they were executed at the same time from the same box, the difference is that one uses the hbh...
> the other difference is the total time needed to complete the same amount of work: 2.3s vs 1.8s,
> and obviously, the measured rtt: 20ms vs 16ms...
>
> an othet ping, this one stayed within the nren shows more interesting patterns: the exception
> traffic is seems to be rate limited... we're a mixed cisco shop made of almost all of their stuff:
> asr9k, asr1k, ncs5k, nexus7k, nexus9k... the difference between the two paths is that which kind
> of cisco boxes are involved... i'll set up some measurement points within the nren to see how
> different boxes of theirs handle the hbh option...
>
> br,
> cs
>
> rtr1.c4e#ping www.geant.org repeat 111 alert 123
> 2022-08-01 10:15:50
> resolving www.geant.org for ipv4 ok!
> pinging 83.97.93.30, src="195.111.97.201," vrf=inet, cnt=111, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=123, sweep=false, multi=false
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> result=100.0%, recv/sent/lost/err=111/111/0/0, took 2333, min/avg/max/dev rtt=18/20.9/45/22.7, ttl 60/60.0/60/0.0, tos 0/0.0/0/0.0
> rtr1.c4e#
>
> rtr1.c4e#ping www.geant.org repeat 111
> 2022-08-01 10:15:49
> resolving www.geant.org for ipv4 ok!
> pinging 83.97.93.30, src="195.111.97.201," vrf=inet, cnt=111, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=-1, sweep=false, multi=false
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> result=100.0%, recv/sent/lost/err=111/111/0/0, took 1851, min/avg/max/dev rtt=16/16.5/21/0.4, ttl 60/60.0/60/0.0, tos 0/0.0/0/0.0
> rtr1.c4e#
>
>
>
>
>
>
> rtr1.c4e#ping www.niif.hu repeat 111
> 2022-08-01 10:19:55
> resolving www.niif.hu for ipv4 ok!
> pinging 193.225.14.25, src="195.111.97.201," vrf=inet, cnt=111, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=-1, sweep=false, multi=false
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> result=100.0%, recv/sent/lost/err=111/111/0/0, took 102, min/avg/max/dev rtt=0/0.7/1/0.1, ttl 63/63.0/63/0.0, tos 0/0.0/0/0.0
> rtr1.c4e#
>
> rtr1.c4e#ping www.niif.hu repeat 111 alert 123
> 2022-08-01 10:19:54
> resolving www.niif.hu for ipv4 ok!
> pinging 193.225.14.25, src="195.111.97.201," vrf=inet, cnt=111, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=123, sweep=false, multi=false
> !!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!
> result=95.4%, recv/sent/lost/err=106/111/5/0, took 5224, min/avg/max/dev rtt=1/1.9/6/0.3, ttl 63/63.0/63/0.0, tos 0/0.0/0/0.0
> rtr1.c4e#
>
>
>
>
>
>
>
>
> rtr1.c4e#ping www.niif.hu repeat 111 alert 123 timeout 111
> 2022-08-01 10:21:33
> resolving www.niif.hu for ipv4 ok!
> pinging 193.225.14.25, src="195.111.97.201," vrf=inet, cnt=111, len=64, df=false, tim=111, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=123, sweep=false, multi=false
> !!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!.!!!!!!.!!!!!!!!!!!!!!.!!!!!!!!!!!!!.!!!!!.!!!!!!!!.!!!!!!!!!!!!!!!!!!!.
> result=92.7%, recv/sent/lost/err=103/111/8/0, took 1097, min/avg/max/dev rtt=1/1.8/3/0.1, ttl 63/63.0/63/0.0, tos 0/0.0/0/0.0
> rtr1.c4e#
>
> rtr1.c4e#ping www.niif.hu repeat 111 alert 123 timeout 111 delay 555
> 2022-08-01 10:22:05
> resolving www.niif.hu for ipv4 ok!
> pinging 193.225.14.25, src="195.111.97.201," vrf=inet, cnt=111, len=64, df=false, tim=111, gap=555, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=123, sweep=false, multi=false
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> result=100.0%, recv/sent/lost/err=111/111/0/0, took 61895, min/avg/max/dev rtt=1/2.2/13/1.9, ttl 63/63.0/63/0.0, tos 0/0.0/0/0.0
> rtr1.c4e#
>
>
>
>
>
>
>
> On 7/31/22 21:30, Ackermann, Michael wrote:
>>
>> First sorry to hear about your flight. Hope you are close to or even home now! The airline better have bought you dinner and paid for a hotel!!!
>>
>> I have many pcaps. Trying to do as much as I can this weekend, as Monday and likely all of next week will likely be tough for me. How dare I take a week off .
>>
>> When we talk on Monday I will describe the various testing I have done and the traces I have. You will likely not be interested in all of them. And many are problems with
>> setting up test environments and test scenarios, that showed even more issues with IPV6. But the bottom line continues to be that EHs are getting through.
>>
>> I would like to be involved in the FreeRTR testing. You probably know what I say next . My issue is increasingly getting to be time. So once again let s talk about
>> what I could possibly contribute, in all the areas we have discussed the passed week or so, and prioritize. I hope you know I want to do it ALL, but have to be realistic or I
>> end up being a problem or slowing things down.
>>
>> In any event, a lot of great, positive and productive initiatives ! Very exciting!!!!
>>
>> Thanks
>>
>> Mike
>>
>> *From:* Nalini J Elkins <>
>> *Sent:* Sunday, July 31, 2022 10:04 AM
>> *To:* ; Nalini J Elkins <>;
>> *Cc:* Ackermann, Michael <>; Tommaso Pecorella <>; Dhruv Dhody <>; Mohit P. Tahiliani <>
>> *Subject:* Re: [freertr] FreeRtr and Hop-By-Hop header
>>
>> [External email]
>>
>> Csaba,
>>
>> (Adding Dhruv and Mohit. They are our main contacts in India for our work.)
>>
>> First, I am still not home yet. My flight was cancelled so I had to spend the night at a stopover! Hopefully, I get home today! Then, I can work quietly.
>>
>> We are setting up an email list. Will invite you to join. I think I will start an email thread / group to just test just router functions. I will write up what I am thinking
>> and then we can test the same thing on multiple platforms. (FreeRtr, Cisco, Juniper, for example).
>>
>> Please also send me pcaps of your testing / ping. We can create a repository. Also, let's create a "tools" section so we have PING (w/HBH), etc. Procedures on how to do
>> Telnet with HBH.
>>
>> Also, if we get Linux servers at various locations, can you guys help with setting up FreeRtr on them? I think once we understand the configuration, we can easily clone (and
>> modify routing table / etc as needed). Mike, maybe you are best to coordinate this. Do you have time? Dhruv, is there someone in India who can help?
>>
>> Thanks,
>>
>> Nalini Elkins
>> CEO and Founder
>> Inside Products, Inc.
>> www.insidethestack.com <http://www.insidethestack.com>
>> (831) 659-8360
>>
>> On Saturday, July 30, 2022 at 02:42:23 PM PDT, mc36 < <mailto:>> wrote:
>>
>> and one explicit one:
>>
>> mchome#lookup reverse 62.240.163.10
>> resolving ptr 10.163.240.62.IN-ADDR.ARPA
>> 10.163.240.62.in-addr.arpa ptr internetcz.cust.net.upc.cz
>>
>> mchome#ping 62.240.163.10 vrf inet2
>> pinging 62.240.163.10, src="null," vrf=inet2, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=-1, sweep=false, multi=false
>> !!!!!
>> result=100.0%, recv/sent/lost/err=5/5/0/0, took 71, min/avg/max/dev rtt=13/13.8/14/0.1, ttl 237/237/237/0.0, tos 0/0.0/0/0.0
>> mchome#ping 62.240.163.10 vrf inet2 alert 1
>> pinging 62.240.163.10, src="null," vrf=inet2, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=1, sweep=false, multi=false
>> .....
>> result=0.0%, recv/sent/lost/err=0/5/5/0, took 5002, min/avg/max/dev rtt=10000/0.0/0/0.0, ttl 256/0.0/0/0.0, tos 256/0.0/0/0.0
>> mchome#
>>
>>
>> On 7/30/22 23:40, mc36 wrote:
>>> well, seemingly my local isp blocks all such my packets so i cannot do to much for now....
>>> but the stuff will be out by the tomorrow autoupgrade in some boxes in the local nren,
>>> where from i can test if further... interesting afterall... seemingly ipv4 is not better,
>>> some isps propagate the alert option, some dont... but in that case, at least my packets
>>> exceed my uplink isp border boxes... :)
>>>
>>>
>>> mchome#traceroute nop.hu vrf inet2 lookup ipv4
>>> resolving nop.hu for ipv4 ok!
>>> tracing 81.2.241.46, src="null," vrf=inet2, prt=0/33440, tim=1000, tos=0, flow=0, len=64
>>> via 0.0.0.0/0 0/2 dialer1 10.0.0.1 00:13:48
>>> 1 null time=1000
>>> 2 null time=1000
>>> 3 null time=1000
>>> 4 null time=1000
>>> 5 null time=1000
>>> 6 null time=1000
>>> 7 null time=1000
>>> 8 4.69.161.122 time=4, name=ae2.3204.ear1.Budapest1.level3.net
>>> 9 null time=1000
>>> 10 null time=1000
>>> 11 null time=1000
>>> 12 null time=1000
>>> 13 185.188.186.30 time=24, mpls=89, name=cz-prg01a-rc1-vla2121.net.vodafone.cz
>>> 14 185.188.187.88 time=12, mpls=982, name=cz-pra-pop115-rb1-vla2119.net.vodafone.cz
>>> 15 null time=1000
>>> 16 62.240.163.10 time=13, name=internetcz.cust.net.upc.cz
>>> 17 null time=1000
>>> 18 null time=1000
>>> 19 81.2.241.46 time=15, name=www.nop.hu
>>> mchome#
>>> mchome#ping 4.69.161.122 vrf inet2 alert 1234
>>> pinging 4.69.161.122, src="null," vrf=inet2, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=1234, sweep=false, multi=false
>>> !!!!!
>>> result=100.0%, recv/sent/lost/err=5/5/0/0, took 81, min/avg/max/dev rtt=12/16.2/23/14.9, ttl 55/55.0/55/0.0, tos 0/0.0/0/0.0
>>> mchome#ping 185.188.186.30 vrf inet2 alert 1234
>>> pinging 185.188.186.30, src="null," vrf=inet2, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=1234, sweep=false, multi=false
>>> .....
>>> result=0.0%, recv/sent/lost/err=0/5/5/0, took 5002, min/avg/max/dev rtt=10000/0.0/0/0.0, ttl 256/0.0/0/0.0, tos 256/0.0/0/0.0
>>> mchome#
>>>
>>>
>>>
>>> On 7/30/22 22:34, mc36 wrote:
>>>> and it works.... btw, these packets did not get out of my net, as expected... :)
>>>> but in wireshark, they look pretty, see attached.... :)
>>>> br,
>>>> cs
>>>>
>>>> resolving www for ipv6 ok!
>>>> pinging 2001:db8:1101::10, src="2001:db8:1101::227:227," vrf=v1, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=123, sweep=false, multi=false
>>>> !!!!!
>>>> result=100.0%, recv/sent/lost/err=5/5/0/0, took 7, min/avg/max/dev rtt=1/1.4/2/0.2, ttl 255/255/255/0.0, tos 0/0.0/0/0.0
>>>> sid#ping www alert 123 ipv4
>>>> resolving www for ipv4 ok!
>>>> pinging 10.10.10.10, src="10.10.10.227," vrf=v1, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=123, sweep=false, multi=false
>>>> !!!!!
>>>> result=100.0%, recv/sent/lost/err=5/5/0/0, took 5, min/avg/max/dev rtt=0/0.8/1/0.1, ttl 255/255/255/0.0, tos 0/0.0/0/0.0
>>>> sid#
>>>>
>>>>
>>>> sid#ping mp.ls
>>>> resolving mp.ls for ipv6 ok!
>>>> pinging 2001:15e8:110:92e::cc1e:c0de, src="2001:db8:1101::227:227," vrf=v1, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=-1, sweep=false,
>>>> multi=false
>>>> !!!!!
>>>> result=100.0%, recv/sent/lost/err=5/5/0/0, took 89, min/avg/max/dev rtt=17/17.8/18/0.1, ttl 240/240/240/0.0, tos 0/0.0/0/0.0
>>>> sid#ping mp.ls alert 123
>>>> resolving mp.ls for ipv6 ok!
>>>> pinging 2001:15e8:110:92e::cc1e:c0de, src="2001:db8:1101::227:227," vrf=v1, cnt=5, len=64, df=false, tim=1000, gap=0, ttl=255, tos=0, sgt=0, flow=0, fill=0, alrt=123, sweep=false,
>>>> multi=false
>>>> .....
>>>> result=0.0%, recv/sent/lost/err=0/5/5/0, took 5001, min/avg/max/dev rtt=10000/0.0/0/0.0, ttl 256/0.0/0/0.0, tos 256/0.0/0/0.0
>>>> sid#
>>>>
>>>>
>>>>
>>>>
>>>> On 7/30/22 22:13, mc36 wrote:
>>>>> well, imho all the vendors have the knobs to filter these out in acls, or globally...
>>>>> on fixed/programmable asics, it's on by default because of the limited onchip code space, but they'll tell....
>>>>> but if not, it's up to the operators if they do so... those who issues before with these,
>>>>> imho they've configured it already... but let's see... i'm extending my ping with
>>>>> the capability right now to ease the further testing, and we'll see...
>>>>>
>>>>> sid#ping 1.1.1.1 alert ?
>>>>> <num> - payload data
>>>>>
>>>>> it'll set the packHolder.IPalrt from below patch i did with the tcp to emit the hbh frames...
>>>>> br,
>>>>> cs
>>>>>
>>>>>
>>>>> On 7/30/22 21:43, Nalini J Elkins wrote:
>>>>>> I am on board the flight home. I will check your trace and results tomorrow.
>>>>>>
>>>>>> Btw, we can easily connect with juniper to check with them. We are finding a Cisco contact.
>>>>>>
>>>>>> I am tentatively thinking of setting up freertrs near Mumbai, Seattle and Warsaw to start with as we have servers there. Let me think a bit as to what exactly we want
>>>>>> to do.
>>>>>>
>>>>>> Let s see if they get through first and then think about performance next.
>>>>>>
>>>>>> Thanks so much!
>>>>>> Nalini
>>>>>>
>>>>>>
>>>>>> Sent from Smallbiz Yahoo Mail for iPhone <https://overview.mail.yahoo.com/?.src="iOS" <https://overview.mail.yahoo.com/?.src="iOS>>
>>>>>>
>>>>>> On Saturday, July 30, 2022, 3:12 PM, mc36 < <mailto:>> wrote:
>>>>>>
>>>>>> ohh, and i forgot the results... attaching a telnet session performed between two freerouters,
>>>>>> the one ending with :227 patched with the below very simple things:
>>>>>>
>>>>>> <mailto:> <mailto: <mailto:>>:~$ diff ~/Documents/src/net/freertr/prt/prtTcp.java
>>>>>> /nfs/own/web/src/src/net/freertr/prt/prtTcp.java
>>>>>> 571c571
>>>>>> < pck.IPalrt = 123;
>>>>>> ---
>>>>>> > pck.IPalrt = -1;
>>>>>> 626c626
>>>>>> < pck.IPalrt = 123;
>>>>>> ---
>>>>>> > pck.IPalrt = -1;
>>>>>> <mailto:> <mailto: <mailto:>>:~$
>>>>>>
>>>>>> you can see, that it's a healthy session, nothing strange, wireshark decodes it cleanly...
>>>>>> and, they were several mpls hops away from each other, all the intermediate boxes running
>>>>>> the below mentioned dpdk dataplane... if it was pure ip, the i dont say it would suffer,
>>>>>> because it's a low volume traffic, but be would get rate limited, and forwarded in the
>>>>>> java code instead of the dpdk code....
>>>>>>
>>>>>> br,
>>>>>> cs
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/30/22 20:39, mc36 wrote:
>>>>>> > hi,
>>>>>> > interesting plans... well, i just performed some experiments and seemingly freerouter passes packets correctly with hbh option,
>>>>>> > regardless of it's contents... there is an exception, if, after finding the real layer4 protocol id, if that protocol is
>>>>>> > registered for the receiving interface, then it can do further processing on the packet, if it wants... right now, only the
>>>>>> > below mentioned rsvp and mdl are who do such things, everything else (tcp, udp, etc) passes does not cares at all:
>>>>>> > but, there is a catch: right now we have some dataplanes, a dpdk based ones, an xdp/ebpf based, and the a based for for tofino asic..
>>>>>> > right now, all the dataplane handles these packets as exception packets, that is, after rate limiting, freerouter code will finally
>>>>>> > forward the packets... it have some consequences, most notably the real flow characteristics will significantly differ from the measured
>>>>>> > characteristics... even i can imagine that the real flow could be broken whereas the measured one goes through: for example if the dataplane
>>>>>> > programming fails somehow and an entry missing in one of the tables, but, if playing with the hbh option, it's an early catch and obviously
>>>>>> > does not use most of the output tables... imho the other already, deployed boxes will show similar or worse behaviors...
>>>>>> > regarding your plans to bring up a freerouter network and see it yourself, surely we're more than happy to help you if you have any questions...
>>>>>> > br,
>>>>>> > cs
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On 7/30/22 15:07, Nalini J Elkins wrote:
>> <https://datatracker.ietf.org/doc/html/draft-fear-ippm-mpdm-02%20><https://datatracker.ietf.org/doc/html/draft-fear-ippm-mpdm-02
>>>>>> >>
>>>>>> >> We are doing a deep dive investigation into IPv6 Extension Headers. You may wish to watch our presentation at the IEPG on
>>>>>> Sunday at:
>>>>>> IETF114-IEPG-20220724-1400
>>>>>> >> <https://www.youtube.com/watch?v=Pz6wIu1gaXE <https://www.youtube.com/watch?v=Pz6wIu1gaXE%20><https://www.youtube.com/watch?v=Pz6wIu1gaXE
>> <https://www.youtube.com/watch?v=Pz6wIu1gaXE>>> Basically, our investigation shows that some of
>>>>>> the previous work may
>>>>>> have drawn some inaccurate assumptions as to if extension
>>>>>> >> headers can be used on the public internet. This functionality is critical to the Internet at large.
>>>>>> >>
>>>>>> >> The draft we are currently working on is on an Encrypted Destination Option <https://datatracker.ietf.org/doc/draft-elkins-ippm-encrypted-pdmv2/
>>>>>> <https://datatracker.ietf.org/doc/draft-elkins-ippm-encrypted-pdmv2/ <https://datatracker.ietf.org/doc/draft-elkins-ippm-encrypted-pdmv2/>>>.
>> But, what we want to do is
>>>>>> >> to have FreeRtr support a HBH header. Please see draft HERE < >.
>>>>>> It is an expired draft and I want to make some
>>>>>> changes. But, you will get the idea.
>>>>>> >>
>>>>>> >> What I want to do is to set up a FreeRtr network across the public internet. We have servers already.
>>>>>> Is this work that you would be
>>>>>> interested to participate
>>>>>> in? If
>>>>>> >> so, we would love for you to be co-author on the draft / participant in presentations.
>>>>>> >>
>>>>>> >> Please let me know your thoughts.
>>>>>> >>
>>>>>> >> Thanks,
>>>> >> >>
>>>>>> >> Nalini Elkins
>>>>>> >> CEO and Founder
>>>>>> >> Inside Products, Inc.
>>>>>> >> www.insidethestack.com <http://www.insidethestack.com>
>>>>>> >> (831) 659-8360
>>>>>> >>
>>>>>> >>
>>>>>> >> On Friday, July 29, 2022 at 12:44:31 PM PDT, mc36 < <mailto:> <mailto: <mailto:>>> wrote:
>>>>>> >>
>>>>>> >>
>>>>>> >> hihi,
>>>>>> >> you're welcome, and i thank you for reaching out...
>>>>>> >> i bet you have some specific idea... could you please drop me the draft you're planning for?
>>>>>> >> thanks,
>>>>>> >> cs
>>>>>> >>
>>>>>> >>
>>>>>> >> On 7/29/22 20:23, Nalini J Elkins wrote:
>>>>>> >> > Thanks!
>>>>>> >> >
>>>>>> >> > Let me look and I will be back to you on what we may need.
>>>>>> >> >
>>>>>> >> > I am at ietf and just going home. So it will take me a few days.
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > Sent from Smallbiz Yahoo Mail for iPhone <https://overview.mail.yahoo.com/?.src="iOS"
>>>>>> <https://overview.mail.yahoo.com/?.src="iOS%20><https://overview.mail.yahoo.com/?.src="iOS" <https://overview.mail.yahoo.com/?.src="iOS>
>>>>>> ><https://overview.mail.yahoo.com/?.src="iOS" <https://overview.mail.yahoo.com/?.src="iOS%20><https://overview.mail.yahoo.com/?.src="iOS"
>>>>>> >> >
>>>>>> >> > On Friday, July 29, 2022, 1:49 PM, mc36 < <mailto:> <mailto: <mailto:>> <mailto: <mailto:>
>>>>>> <mailto: <mailto:>>>> wrote:
>>>>>> >> >
>>>>>> >> > hihi,
>>>>>> >> > nice to meet you again!
>>>>>> >> > well, something is there, but it depends what you need exactly...
>>>>>> >> > on receiving, this happens:
>>>>>> >> >
>>>>>> >> > on the sending side, this:
>>>>>> >> >
>>>>>> >> > this is, as is for now, fine for igmp, rsvp over ipv6, and maybe other protocols to do
>>>>>> the trick...
>>>>>> >> > br,
>>>>>> >> > cs
>>>>>> >> >
>>>>>> >> >
>>>>>> >> > On 7/29/22 18:45,
>>>>>> <mailto:> <mailto: <mailto:>>
>> <mailto: <mailto:>
>>>>>> <mailto: <mailto:>>> <mailto:
>>>>>> <mailto:>
>> <mailto: <mailto:>>
>>>>>> >> <mailto: <mailto:> <mailto:
>>>>>> <mailto:>>>> wrote:
>>>>>> >> > > Csaba,
>>>>>> >> > >
>>>>>> >> > > I believe we met at the IETF hackathon in
>>>>>> Vienna. We are working
>>>>>> on IPv6 extension header testing.
>>>>>> >> > >
>>>>>> >> > > I would like to understand the support of IPv6
>>>>>> extension headers in
>>>>>> FreeRtr. Do you have it?
>>>>>> >> > >
>>>>>> >> > > If not, we would like to work with you to add it.
>>>>>> >> > >
>>>>>> >> > > Thanks,
>>>>>> >> > >
>>>>>> >> > > Nalini Elkins
>>>>>> >> > > CEO and Founder
>>>>>> >> > > Inside Products, Inc.
>>>>>> >> > > www.insidethestack.com
>>>>>> <http://www.insidethestack.com>
>>>>>> >> > > (831) 659-8360
>>>>>> >> >
>>>>>> >
>>>>>> >
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>> The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are
>> not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by
>> electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
>>
>> Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
>>
_._,_._,_
Groups.io Links:
You receive all messages sent to this group.
View/Reply Online (#465) | | | Mute This Topic | New Topic
Your Subscription | | Unsubscribe []
_._,_._,_
- Re: [RARE-users] [freertr] FreeRtr and Hop-By-Hop header, Ackermann, Michael via groups.io, 08/02/2022
- Re: [RARE-users] [freertr] FreeRtr and Hop-By-Hop header, mc36, 08/02/2022
- Re: [RARE-users] [freertr] FreeRtr and Hop-By-Hop header, mc36, 08/02/2022
- Re: [RARE-users] [freertr] FreeRtr and Hop-By-Hop header, , 08/02/2022
- Re: [RARE-users] [freertr] FreeRtr and Hop-By-Hop header, mc36, 08/02/2022
- Re: [RARE-users] [freertr] FreeRtr and Hop-By-Hop header, , 08/02/2022
- Re: [RARE-users] [freertr] FreeRtr and Hop-By-Hop header, mc36, 08/02/2022
- Re: [RARE-users] [freertr] FreeRtr and Hop-By-Hop header, mc36, 08/02/2022
Archive powered by MHonArc 2.6.19.