Antti,
Thanks for your detailed explanation. This is exactly the kind of
answer I was waiting for.
What I find regrettable about the current MIPv6 development process,
is that many things seem to happen behind the scene. Most of the
patches and discussion about litigious points are not posted to the
mipl-devel ML. And when an announcement like the UMIP one is made, it
is hard to understand what the real situation is, what features the
patch brings and what is the history behind it.
Benjamin
Antti Tuominen wrote:
On Mon, 2006-04-03 at 17:36 +0200, Benjamin Thery wrote:
Hello,
Hello Benjamin,
Before anyone gets upset about this mail, I'll say I'm not trying to
offend anyone or question anyones abilities. Rather, I'd like to see
this as a start for a discussion with broader audience.
Following your announcement about UMIP, I have a bunch of questions to
ask.
The first one is very simple: Will USAGI be the maintainer MIPv6 for
Linux in the future? This is not very clear to me in your announcement.
No.
(I understood from previous messages that Antti and Ville from HUT are
no longer actively working on MIPL and NEPL projects, as they now have
other priorities.)
Nobody is paying us to do MIPL or NEPL stuff at the moment. That does
not mean we are giving up any responsibilities, it just means we can't
do that much on our working hours. Nothing special from most other OSS
projects.
The tarballs you advertised seem older than the latest release of MIPL
(2.0.1 released in February). I'd like to know exactly on which
version of MIPL is UMIP based on?
It seems to be a snapshot from Dec 14th 2005. I'd suppose the kernel is
from the same day.
You also mentioned a very interesting point which is the merge into
the mainline kernel of MIPv6. It would be great to see this happen
soon. Can you provide us with some more information? Has the work for
integration already begun? Can we help is some ways?
There has been talk about first integrating all the non-MIPv6 specific
stuff like the policy routing. Since most changes to IPv6 code go
through Hideaki Yoshifuji (of USAGI), we (at HUT) have always considered
the right avenue to the mainline go through USAGI. We have never gotten
a clear indication at what point integration to mainline or even to
USAGI kernels might be happening.
We would like to see MIPv6 stuff integrated as soon as possible. That
would help us enourmously, as well as make things easier for people
wanting to test or distributions wanting to include Mobile IPv6 support.
Thank you a lot for all your answers.
I know you didn't mean me to answer, but I did anyway. There has been
plenty of confusion already about USAGI/MIPL relation, so I would like
to clear things up a bit.
HUT and USAGI started collaboration on Mobile IPv6 in about 2003, so
there wouldn't be two separate implementations. At that time HUT had
already been working on MIPv6 from 1999 (MIPv6 draft 8, kernel version
2.3.59 or something).
At some point USAGI started to show up at interops with a patched MIPL
they called UMIP. We had to explain to other people time and time
again, that MIPL and UMIP are not different implementations, but UMIP
just has patches that were either not submitted to us, or were rejected
by us. There were more than plenty of misunderstandings between HUT and
USAGI groups which hindered the co-operation.
One of the main reasons for rejecting a patch from USAGI was usually
that they read TAHI tests as the final and undisputed truth. When
offered with a bulky patch changing something here something there not
really sure what or why, just so you could pass one TAHI test, even if
the test didn't make sense in the first place, we of course turned it
down, and told then to talk to TAHI guys instead.
You have a nice example of this on your TAHI test analysis page: "The
question is: Is it conform if the MN restarts a Home Registration with
the HA that failed to acknowledge its previous Home Registration
session?" Everyone agree that if DHAAD Reply only has one HA, that
should be tried. If it doesn't reply you can try again, but at some
point you have to give up, and try DHAAD again. TAHI test again replies
with just one HA on the reply, itself. Obviously, if it responds to
DHAAD Request, we assume it is reachable. Other implementors usually
just shrugged their shoulders and said "so what.. everyone knows that
test doesn't work so just ignore it". So, as far as I understand it,
and what I've gathered by talking to other people, there is nothing
wrong with the above behaviour wrt. RFC3775.
Another thing is that sometimes when TAHI test machine isn't powerful
enough, it fails a test just because it can't keep up with the other
end. TAHI guys told this themselves. So rather than doing elaborate
modifications to our implementation while we interoperate successfully
with most, if not all, other implementation, we would very much like to
talk with TAHI guys or better yet have USAGI people talk to TAHI guys
since both TAHI and USAGI are part of the bigger WIDE project, and speak
the same language.
The best possible scenario for us would be to get remaining TAHI tests
fixed (either by us or TAHI, depending) and the kernel support
integrated ASAP to mainline. This would allow us to redirect all
resources we have to further development of the user space daemon. This
would also make a clear cut division of responsibilities. Anything that
needs to be fixed in the kernel goes through USAGI, and anything else
through us.
Regards,
Antti
--
B e n j a m i n T h e r y - BULL/DT/Open Software R&D
http://www.bull.com
_______________________________________________
mipl mailing list
[email protected]
http://www.mobile-ipv6.org/cgi-bin/mailman/listinfo/mipl
