Subject: RE: MD identifiers ? (was Re: [mobile-ip] Why not tunnel instead of RTH2 and HAO?)

From: "Ed Remmell" <[email-masked]>
Date: Wed, 16 Apr 2003 09:30:39 -0700

Greg -

> Sorry that after such a long email, my responses will be short.

I can see you have thoroughly processed my verbose information and have
replied with thoughtful responses, that's all I could have asked for. I
apologize if my responses tended to become flippant before - L2 triggers
just seems like the obvious solution to me.

> I agree that L2 movement detection is possible, but
> from my viewpoint, it is not desirable.
> Modification of L2 for movement detection
> puts MIPv6 movement at the mercy of drivers.
> Also, for each L2 protocol this means that the
> MD support must be coded, even if there is a
> consistent API for this information going to the MN.

Good points.

When you do optimization, IMO you need to resort to low-level mechanisms.

I seem to remember that HMIP is a good way to speed up handovers.

> I'm happy for there to be a minimal interaction
> with L2 which may provide a hint of movement.
>
> I think that the design of MIPv6 networks is such
> that techniques which work on a constrained set of
> wireless technologies will not be valid for general
> MIPv6 movement detection.
>
> I prefer to use ND/RD/NUD to perform movement detection
> since these are available on all MIPv6 MNs.
> If the L3 messages can contain unambiguous information
> about movement, then that obviates the need for NUD
> (which is a performance gain).

NUD should still be implemented as a fallback. Any replacement you define
should still confirm bi-directional reachability. Being able to hear a
current default router isn't enough.

Perhaps you are thinking that the primary CoA that the MN uses may have a
prefix advertised by a router that the MN can hear but not successfully send
to, and that the MN is actually sending through a different router which
doesn't advertise that prefix. First of all, because of ingress filtering
this solution will not work in the general case. Also, it violates basic
rules applying to network topology - a MN should not be using a primary CoA
to send packets though a router when that router doesn't recognize the
prefix of that CoA as being on-link. Probably most importantly, it becomes
difficult for the MN to tell when prefixes become off-link, and can easily
lead to the problems that I reported in MIPv6 issue #170 "sloppiness about
overlapping coverage areas". I suspect from what you wrote in your previous
email:

> I think that MD is primarily interested in tracking of
> CoA validity first (for packet reception) and
> second default router choice (for packet transmission).

that having the MN simultaneously use 2 different default routers on
different "links" in the handover case is exactly what you intend to
propose. I don't think this is anything new: the MIPv6 base specification
already supports a similar mechanism by having the MN continue to support
receiving packets on the old primary CoA (for some period of time) after
updating its bindings with the new CoA - I fully support that approach, but
sloppiness w/ regards to default router selection and prefix usage I do not
support. You say that CoA validity is important for packet reception - well,
w/ regards to ingress filtering considerations, it is also important w/
regards to packet transmission. Are you proposing that MIPv6-aware routers
that implement support for your MD optimizations disable ingress filtering?
I don't think that will fly.

> Still, I think that if we can control the ambiguity at the network
> layer
>
> > ??? No, it is still useful even in that case. Part of listening
> for beacons
> > is also verifying that they were sent by your current default
> router. So, if
> > you receive beacons from a different router, that doesn't count
> to verify
> > that you can still hear your current default router.
>
> I see what you mean, but we're still waiting for 2 packets
> to be lost.  I would prefer to detect movement with a
> single received RA.

But if the beacons are sent fast enough...

> We're not actually talking about L2 movement, since that
> doesn't count for MIPv6.
>
> We're talking about L3 movement.
> You can have many L2 moves without having any L3 movement.

Yes, but when you do a L3 move, you have also done a L2 move. A L2 movement
indication can cause the MN to enter the NUD PROBE state and immediately
start probing the current default router to confirm bi-directional
reachability. I agree that isn't incredibly fast (i.e. in the case where the
current default router has become unreachable).

It is also possible that a L2 trigger could indicate L3 movement, if the
network ID information is available at the link-layer and/or MAC layer (it
is in the case of CDPD).

> Moving between sets of links with a common set of L3
> identifiers, and another set which doesn't is what counts.
>
> L2 systems should not have to worry about which L3 topology
> they are configured in.   L3 systems should be concerned.
>
> I'm sorry to disagree with you on this, but I think it is
> vital to MIPv6.

"link" is a link-layer concept which belongs in L2, not in L3.

> Personally, I think that the ND hacks on the home link
> are regrettable.
> Professionally, I believe that if implementing return home
> function requires me to do it, I will (but I'm not looking at
> that today).

I'm trying to avoid implementing them myself. It seems like when I
deregister with the HA when I return home, if I use a link-local scope
address as the source address of the BU (and include the Home Address
destination option) and then also whenever I register a binding I specify
L=0 (so the HA never defends my derived link-local scope address), that I
can avoid these hacks entirely. Yes, I'm aware that I'm ignoring the
specification requirements that apply to the use of the L-bit in the BU; it
takes a lot to push me that far to where I will willingly not implement a
MUST (or even a SHOULD) requirement, and generally I would agree that this
is not professional but sometimes the experts aren't right.

> One thing which is important is that most operating systems
> which have MIPv6 already have IPv6 function.  Therefore the
> number of specialist concepts which are needed in these
> systems should be kept to a minimum.

Well, then there are also the IKE hacks...

> In MIPv6 is the IPSec and Tunneling may be affected, but we
> try to not modify them too much, since they are known to
> work in IPv6.   Construction of MD state (as virtual links,
> or as link tracking, etc) should be as simple as possible,
> so that it doesn't require re-implementation of concepts on
> existing implementations, if possible.
>
> For example, I'm not going to write in a draft  that MIPv6
> uses 'Tunnel Interfaces' even if MIPL does.  This is a
> suggestion of implementation rather than a protocol
> specification.  Such suggestions are worth avoiding.

I'd say that sometimes an example/prototype implementation is a good
guideline for implementors, even if it doesn't correspond exactly to the
IPv6 stacks that are currently available.

Design artifacts (which much of the content of RFCs is) are allowed to touch
on implementation details. If they didn't, then they risk being unclear and
confusing to implementors, which is worse.

Also, I wasn't proposing that my design information be incorporated into any
RFC. The actual requirements I added to the spec per MIPv6 issue #170
"sloppiness about overlapping coverage areas" are actually very high-level
and do not assume any particular implementation.

> >>At this stage I agree that NUD is the right tool to check that
> >>you are (still?) connected to a router.  JinHyeock has pointed
> >>this out to me recently.
> >
> >
> > Thank you. And that uses ND probing. I'm glad I could change
> your mind ;-)
> > Actually, I changed JinHyeock's mind first I believe ;-)
> >
>
> Maybe, but NUD is still ambiguous in some cases  ;)

> > YES! But then when they aren't available, you are stuck with
> MIPv6 generic
> > default movement detection (i.e. NUD) which is slow. So, if you
> want faster
> > MD, you must have L2 triggers. I see no problem with that, I
> don't know why
> > you have a problem with that.
> >
>
> I think we can do better with no additional cost.
> That's all.

Perhaps you are right. I have an open mind.

> > ND probing is prohibitive? I think not.
> >
> It is prohibitive since ND probing only
> completes quickly in the case that the old AR
> is present.  In the common case, it is slow.

Yes, you are right. I agree with you on this point now.

> This is the critical issue.
>
> > End result:
> > You never get a change to register a new primary CoA, because you keep
> > switching current default routers too quickly. Therefore, applications
> > running on the MN experience a total loss of network
> connectivity. That's
> > pretty harmful, in fact this is awful.
> >
>
> I'm not thinking about today's RAs. They do not
> do the job.   It is possible that they can be made
> better, with a simple addition of information.
>
> I think that this is the time to start getting drafts
> prepared so we can discuss more concrete ideas.

Thanks.
- Ed

---

From: Greg Daley <[email-masked]>
Date: Thu, 17 Apr 2003 14:55:01 +1000

> current default router isn't enough.

This is definitely agreed.
Currently, either NUD or RS is needed for bidirectional
confirmation.  Reception of a solicited RA (Unicast??)
confirms this for a previously unseen AR.
It makes sense to use NUD for known routers though.

> overlapping coverage areas". I suspect from what you wrote in your previous

Actually, I'm not thinking that.

> I don't think that will fly.

No I'm not.

> But if the beacons are sent fast enough...
We'll still have problems with scheduling timeouts in some
cases (some systems' schedulers only have 10ms accuracy).

With current minimum MaxRtrAdvInterval values: the
detection of movement occurs 140ms after the last RA
was sent on the previous link.

Best case: the RA was transmitted almost 70ms before the
handover, so we only have 70ms to wait until movement
detection, after disconnecting from the old router.
Much of this could be during L2 handover.

I think that this may have some potential, although
it is hard to compare this with other methods when without
getting into L2 handover duration specifics.

> network ID information is available at the link-layer and/or MAC layer (it

Paul's illustration with 802.11 messages is certainly an
illustration of how this may be achieved in L2. Certainly
other technologies such as CDPD have made effective use of
similar ideas in the past.

I may just be prejudiced against other protocol layers though.
After all, I didn't really get MPLS when IP tunneling
was a valid option...

Still I'd like to see at least one 'L3 only' proposal, and
maybe a system like Paul's which implicitly provides
link identification by providing an IPv6 global prefix
on each link.

If people are convinced that L2 methods beat L3, I'm sure that
MD will be L2 controlled in the future.

> Well, then there are also the IKE hacks...

Don't remind me: I've got to get our HMIPv6 to draft 7. :)

> and do not assume any particular implementation.

I agree that there needs to be clarity and that implementation
often provides this.  I might need to see your ideas
in a different context to get a clearer idea of the advantages
as well as the ramifications of the virtual link concept, though.

It's sometimes very hard to see another viewpoint when I've been
focussing on one idea for a while.

> Yes, you are right. I agree with you on this point now.

I agree though that L2 mechanisms have a validity in
making this movement unambiguous.

Additionally, if we can get to a point where we can
find out what each others' main proposals are, then it
will definitely be a lot easier to understand each point
of view.

This may wait for a couple of weeks while some people are
away, and drafts are written.

Greg.