Subject: RE: [mobile-ip] Re: closing issue #297 (erik's and steven's techn ical comments on base)

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Tue, 22 Apr 2003 15:42:38 +0200

Jari, 

Nice summary. A couple of comments below:

  >          3a) The text confusingly claims this provides
  >              symmetric reachability (it does not provide
  >              it).
  >          3b) The mechanism works only for the default
  >              router, and hence can't really prove
  >              even one-way reachability if there are
  >              multiple routers.
  >          3c) Lack of payload traffic is not a proof
  >              of a lack of reachability; maybe there
  >              just was no traffic.
  >          3d) Tracking the RAs is sufficient, no need
  >              for tracking other packets.
  >          3e) How can we track packets with link-layer
  >              source address being the default router,
  >              if the default router happens to use
  >              multiple interface cards?
  >          3f) This is a real issue, but we need to
  >              solve it in a general way for IPv6.
  > 
  > How do we move forward? I think we can easily agree on
  > how to fix Erik's problems 1 and 2. In problem 1, the
  > text in Section 2 should be reformulated to "IPv6 Neighbor
  > Unreachability Detection assures...". In problem 2, we
  > can change the first bullet item from Section 1 into
  > "Handling links with unidirectional connectivity or
  > partial reachability, such as hosts hidden from only
  > some of the routers on the link."

=> FWIW, I think problem 2 should not be addressed
in the spec at all. 

  > Problem 3 is trickier. As Ed noted, showing one-way
  > reachability is valuable at the times the mobile node
  > is not sending anything. IF you can show that the
  > router can reach you, then there's no need for the mobile
  > node to send any packets e.g. in NUD. 

=> Yes.

Still, we'll have
  > to deal with 3a-3f. Here are the possibilities:
  > 
  > Judging from the various e-mails that have been sent,
  > I think we agree with Erik that we should keep at least the
  > tracking of RAs and advertisement lifetimes. The question
  > is what else should be kept, and how to respond to 3a-3f.
  > 
  >    Solution 1. Just keep track of RAs + NUD when necessary.
  >    Solution 2. Keep track of RAs, and also track
  >                all packets with the link-layer
  >                source = default router. Do NUD when
  >                necessary.
  >    Solution 3. As above, but make put the interface
  >                in promiscious mode.

=> All of the above is implementation dependent. I always
thought that the movement detection sections were only 
discussing different ways of solving a hard problem that
can only be solved in an optimal manner on a per-link-layer
basis. We don't need to mandate anything in this domain IMO, 
except of course listening to RAs. The rest can be mentioned
as examples of possible solutions.

  >          3b) Yes, we didn't fix this problem but as
  >              described above we can explain this in
  >              Section 1. Lets solve this in an orthogonal
  >              way somewhere else.

=> Yes

  >          3d) Tracking RAs produces around ~100 ms delay
  >              for detecting possible movement if you assume
  >              at most one RA may be lost. If you track
  >              other traffic on the link, you can detect
  >              a possible move earlier. 

=> Hmmm. Dunno if this would be a reliable way of doing it, 
but anyway...side comment

  > 
  >          3f) I don't have a good answer to this. Maybe
  >              the answer depends on how well MIPv6 behaves
  >              without this tracking. I'm pretty sure that
  >              without RA tracking its unusable. But we're
  >              not discussing that. If it performs reasonably
  >              well, then we can take the time to do a general
  >              solution for IPv6. If the performance is really
  >              bad in terms of typical MIPv6 applications,
  >              then I'd rather have a solution in the current
  >              spec.

=> All the studies I saw (did not include RO) but clearly
indicate that the performance depends on:
1. Frequency of RAs
2. Distance to the HA

There is more recent work that includes RO, but I haven't
read it yet. Nevertheless, it's clear that the RA frequency
is the major factor here in the absence of link layer specific
optimisations. 

Hesham