[Olsr-dev] Fwd: [PATCH net] ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not match
Wed Aug 14 09:00:00 CEST 2013
The magic word for kernel patches is 'regression'.
Prove that it worked in an earlier kernel but not in the current.
That will _guarantee_ that the patch will be merged into the current
kernel and into all stable releases.
On 14/08/13 08:55, Teco Boot wrote:
> For those who have interest in IPv6 and multi-homing.
> Today, we have the improved SmartGateway. This works for IPv4 and might work for IPv6.
> For IPv6, the tunnel is not needed if we use routing based on destination *and* source address. There is work in progress, mainly for ZOSPF for Homenets. Juliusz and Matthieu have something in Babel. It is based on the upcoming IETF Source Address Dependent Routing (SADR) standard. Important for multi-path (e.g. MPTCP).
> I suggest to use the elegant IPv6_SUBTREES implementation in SmartGateway, for IPv6 traffic. This work would go into olsrd2.
> Volunteers for making some progress?
> How can we speed up having the IPv6_SUBTREES patch in stable?
> Begin doorgestuurd bericht:
>> Van: Teco Boot <(spam-protected)>
>> Onderwerp: Antw.: [PATCH net] ipv6: don't stop backtracking in fib6_lookup_1 if subtree does not match
>> Datum: 14 augustus 2013 08:40:46 CEST
>> Aan: David Miller <(spam-protected)>
>> Kopie: (spam-protected), (spam-protected), David Lamparter <(spam-protected)>, Lorenzo Colitti <(spam-protected)>, Dave Taht <(spam-protected)>, Ole Troan <(spam-protected)>
>> Thanks for status update.
>> For the record: yes, source address dependent routing has my interest. I'm not feeling lonely at all.
>> There is a draft for this: http://tools.ietf.org/html/draft-troan-homenet-sadr-00
>> Most (if not all) Linux implementations use the IP RULES hack to implement.
>> Lorenzo Colitti heard from David Lamparter the: "Linux IPv6 source routing code (the mythical CONFIG_IPV6_SUBTREES?) to work on 3.8": http://www.ietf.org/mail-archive/web/homenet/current/msg02964.html
>> Few follow-ups were posted, also by David: http://www.ietf.org/mail-archive/web/homenet/current/msg02966.html
>> This triggered me using that code. But it was broken !!! Discussed this with Matthieu Boutier and Juliusz Chroboczek, they faced same problem and therefore also used the IP RULES hack in their implementation. http://www.ietf.org/id/draft-boutier-homenet-source-specific-routing-00.txt
>> So I reported the bug. David Lamparter worked on a fix, Hannes completed it. So far so good.
>> Also, Dave Taht reported the issue and made us aware on lots of patches making the IP RULES hack less painful.
>> FYI, I tested the patch from Hannes on current Ubuntu with 126.96.36.199. Due to other "fixes" this kernel is broken. Bad to make this available to Ubuntu users. So yes, I understand fixes must be tested before getting into stable. Therefore I double-checked this IPV6_SUBTREES fix.
>> Now we have to decide what to do. Wait to get the fix in the wild for some time and continue with the IP RULES hack, implemented in today's experimental SADR implementations. Or start using the more elegant IPV6_SUBTREES method. I vote for the latter. I cannot see a reason for delay. Current situation is bad enough.
>> What can I do to make progress? Spam Linus?
>> Thanks, Teco
>> Op 13 aug. 2013, om 10:15 heeft David Miller <(spam-protected)> het volgende geschreven:
>>> From: Teco Boot <(spam-protected)>
>>> Date: Tue, 13 Aug 2013 10:02:08 +0200
>>>> It is an important element in my work for v6 multi-homed networks
>>>> (IETF Homenet WG).
>>> You are one person. -stable inclusion is decided based how important the
>>> fix is to everyone in both good (fixes a bug) and bad (might cause a
>>> regression) terms.
>>> So "this is important for my work" is never a good reason for a patch
>>> to be included into -stable.
>>> To convince us, you're going to have to present an argument that
>>> exists outside the very limited scope of your own self-interests.
>>> And "other people might/will use my important work in the future"
>>> is not sufficient either.
More information about the Olsr-dev