Subject: [mobile-ip] some more comments on draft 20 (pre)

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Jan 2003 12:20:05 -0800

section 11.5.1

> With some types of networks, indications about link-layer mobility
>    might be obtained from lower-layer protocol or device driver software
>    within the mobile node.  However, all link-layer mobility indications
>    from lower layers do not necessarily indicate a movement of the
>    mobile node to a new link, such that the mobile node would need to
>    switch to a new default router and primary care-of address.  For
>    example, movement of a mobile node from one cell to another in many
>    wireless LANs can be made transparent to the IP level through use of
>    a link-layer "roaming" protocol, as long as the different wireless
>    LAN cells all operate as part of the same IP link with the same
>    subnet prefix.  Upon lower-layer indication of link-layer mobility,
>    the mobile node MAY send Router Solicitations to determine if
>    additional on-link subnet prefixes are available on its new link.

shouldnt the MAY be a SHOULD? when the MN associates with a new 
AP it can never be sure if the new AP belongs to the same IP 
subnet or to a new IP subnet. so it should immediately send out 
a router solicitation to figure this out.

section 11.7.4

>    When a mobile node receives a packet containing a Binding Refresh
>    Request message and there already exists a Binding Update List entry
>    for the source of the Binding Refresh Request, it MAY start a return
>    routability procedure. 

why isnt this a SHOULD? if the CN is in MN's binding update
list, it means that the CN currently has a binding cache
entry for the MN and is requesting the MN to send a new
binding update. why shouldnt the MN immediately try to send
a BU?

section 12 and 13

should we have a smaller value for MAX_BINDACK_TIMEOUT? even
if the current HA is not responding, the MN does not try 
another HA on the home link for MAX_BINDACK_TIMEOUT seconds. 
it is currently 256 seconds.

should we rename INITIAL_BINDACK_TIMEOUT to BINDACK_TIMEOUT 
since we already have a FirstBindingBindAckTimeout?

Vijay

---

From: Greg Daley <[email-masked]>
Date: Wed, 15 Jan 2003 09:27:57 +1100

Hi Vijay,

a comment on the text for section 11.5.1.

When the Routers' RA intervals are very small (draft
pre-20 values), then the MN will not get any benefit
from sending an RS, if the Router obeys the RFC2461
RS Response Delay (0-500ms) before sending an RA.

The MN will receive a multicast RA within 70ms,
this is less than 1/3 of the expected delay for the RS
Response.  Therefore, in this sending an RS, the only
thing the MN achieves is to increase traffic on the
network.

Using FastRA and Samsung's FastRD (RA Caching APs)
the situation is very different (although RA Caching
requires no RS).  These systems can achieve full MIPv6
handovers (w/o DAD) in the time where RA beaconing
provides movement detection.

Of course these optimizations aren't even WG items, so
there's really no reason why the MN SHOULD send RS's
with the current MIPv6 base spec.

MAY is sufficient.

Greg D.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 15 Jan 2003 00:58:55 +0200

> a router solicitation to figure this out.

Agreed. Changed.

> binding update. why shouldnt the MN immediately try to send

I think the reason is that we may have a potentially forged
BRR. The MN might employ some heuristics to figure out when
it actually wants to start recreating bindings at a CN and when
not. Anyways, that's fine as long as we don't have a MUST.

Changed to a SHOULD.

> it is currently 256 seconds.

Yes. What's more reasonable? Is 32 seconds more reasonable?
That would be five retransmissions, and probably somewhat
beyond the largest expected latency over the Internet.

> since we already have a FirstBindingBindAckTimeout?

There's actually two variants of 'initial' -- the very first
before you have a registration, and the first transmission of
a binding update on a later movement. Anyway, there are several
INITIAL_* constants. But I changed the configuration variable to
InitialBindackTimeoutFirstReg, to align it better with the rest.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Jan 2003 15:07:38 -0800

Greg,

OTOH, we will all look stupid tomorrow when the routers 
can infact send out RAs immediately (if 
draft-mkhalil-ipv6-fastra-02.txt is adopted by IPv6 WG) 
and Mobile IPv6 RFC says the MN MAY send out a RS as soon
it gets a L2 trigger. :-)

we need to have that SHOULD today.

one more thing, I will not be using frequent router 
advertisments for movement detection if my link layer 
supports L2 triggers, or if my link layer is very
bandwidth constrained.

the 0-500 ms delay that RFC 2461 recommends is still 
better than nothing. the MN should atleast send a
router solicitation immediately.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 14 Jan 2003 15:19:04 -0800

> beyond the largest expected latency over the Internet.

I guess yes. 32 seconds sounds good. maybe there was a reason
for 256 seconds. anybody knows?

> InitialBindackTimeoutFirstReg, to align it better with the rest.

okay.

Vijay

---

From: Greg Daley <[email-masked]>
Date: Thu, 16 Jan 2003 09:49:51 +1100

Hi Vijay,

FastRA is something I'm interested in too,
but this optimization doesn't work unless the
source address of the RS is a link-local unicast
address.

Since we've received indication that we're possibly on
a new link, shouldn't we do some form of DAD
(possibly optimistically?) before sending RS packets
on the link (their source link-layer address option
could overwrite an existing neighbour cache entry)?

If the MN sends a router solicitation from the unspecified
address, there's no problem. There's also no FastRA though.

I just don't want to see people discarding DAD so they
can get Fast Router Advertisements. I'm not sure it would
get past the ADs for one.

If the draft says SHOULD I'd suggest something like:

"...Upon lower-layer indication of link-layer mobility,
     the mobile node SHOULD send Router Solicitations to
     determine if additional on-link subnet prefixes are
     available on its new link.  The MN SHOULD also mark
     its link-local address as tentative, and follow standard
     Duplicate Address Detection procedures\cite{rfc2462}."

If this is implied elsewhere, I have no concerns.

Greg D.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 15 Jan 2003 15:12:45 -0800

> source address of the RS is a link-local unicast

ofcourse.

> get past the ADs for one.

I never suggested discarding DAD. the router solicitation
is sent only after MN does DAD for its link local address
on the new link. I just wanted a SHOULD so that MN always
sends out router solicitation when it gets an L2 trigger 
and not wait for an unsolicited router advertisment.

>      Duplicate Address Detection procedures\cite{rfc2462}."

this is fine with me.

Vijay

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 16 Jan 2003 01:02:05 +0100

Cool! Looks like this closes issue 210.

-gabriel

-- 
Gabriel Montenegro (Sun Microsystems Laboratories, Europe)
180, Avenue de l'Europe          Email: [email-masked]
ZIRST de Montbonnot              Mobile: +33 673 99 56 62
38334 Saint Ismier CEDEX, France
Office: +33 476 18 80 45 (sun internal: x38045)
Fax:    +33 476 18 88 88

---

From: Greg Daley <[email-masked]>
Date: Thu, 16 Jan 2003 11:05:47 +1100

Hi Vijay,

 > and not wait for an unsolicited router advertisment.

The trap was for unwary players (not yourself).
I know our first cut at this didn't do DAD on link-local
after link-up triggers.

Greg

---

From: Francis Dupont <[email-masked]>
Date: Thu, 16 Jan 2003 17:49:08 +0100

on the new link.

=> why not send the RS from the unspecified address? This is
already done by many IPv6 implementations because this is in
parallel with DAD...

Regards

[email-masked]

PS: IMHO a MAY is enough.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 16 Jan 2003 10:08:30 -0800

Francis Dupont wrote:
> 
>  In your previous mail you wrote:
> 

good idea. you dont have to wait for DAD on link local to 
complete before sending the router solicitation.

> PS: IMHO a MAY is enough.

the section was about what the MN should do when there L2 
triggers available. as soon the MN gets an L2-up trigger
it has to figure out immediately if it is in the same
IP subnet or it has moved to a new subnet. the only way it
can figure this out is by receiving a router advertisment.
if the link is bandwidth constrained, there are not going
to be frequent router advertisements. so it has send a
router solicitation immediately. this is so obvious.

MAY makes no sense here. it has to figure out immediately 
if it is still on the same IP subnet and if its default 
router has changed.

Vijay

---

From: Greg Daley <[email-masked]>
Date: Fri, 17 Jan 2003 09:15:19 +1100

Hi Francis and Vijay.

The discussion about whether a SHOULD or a MAY
is necessary hinged upon the possibility of
receiving a response from the router in short
time (possibly to prepare for FastRA?).

When a host sends an RS from the unspecified
address the response may ONLY be a multicast RA.
The rules which govern scheduling multicast RAs
are even stricter than that for unicast RAs.

If a multicast RA is requested the most the request
can to is reschedule at:

(last Multicast RA time + MinRtrAdvInterval )

Which will not be useful on the link types already
discussed, since Multicast RAs are not being scheduled
frequently.

There is no problem with sending the RS with
unspecified address, but it can only shorten
this interval to the minimum configured on the
router.

In this case, fast movement detection is not really
achived (and nothing is really done to prepare for
FastRA adoption). Realistically, the text could be
MAY.  Please note that the text which I proposed
allows this to happen (when LinkLocal Address is
tentative, the MN will send from the unspecified
address).

Using Optimistic DAD procedures allows the MN to
also mark the address optimistic as well as tentative,
which allows sending from the Link-Local address
while this flag is set.

This cannot be specified in the MIPv6 base draft,
so I don't know why it's so important to handle now.

Greg.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 19 Jan 2003 15:08:58 +0100

=> I disagree. The MAY gives some choices to the implementor
which is not the case of a SHOULD. There should be some cases
where the SHOULD is overkilling so I don't recommend it.

=> the difference is in the rate limitation.

   
=> no, this is for unsolicited RAs. For solicited RAs
the rule is to add a random delay between 0 and MAX_RA_DELAY_TIME
plus the rate limitation at MIN_DELAY_BETWEEN_RAS (RFC 2461 6.2.6)
The end of your message assumes unsolicited RAs...

Regards

---

From: Greg Daley <[email-masked]>
Date: Mon, 20 Jan 2003 09:40:48 +1100

Hi Francis,

I misread some of the solicited multicast RA
specification.

Certainly then, sending an unspecified address RS
is a good way of receiving the RA, if the
MIN_DELAY_BETWEEN_RAS is set relatively low
(as low as 0.03 s in D20).

Also, it looks like FastRA will work with solicited
Multicast RA (as well as unicast), as the counters
are based on last sent Unsolicited RA.
Though there may be some text patched to make this
explicit (several statements which don't distinguish
between solicited and unsolicited multicast RA).

I'm sorry to have caused confusion,

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Jan 2003 06:28:15 +0100 (CET)

> binding update. why shouldnt the MN immediately try to send

Because the MN might not want to extend the lifetime of the binding.
The MN might have decided, based on local heuristics of your choice,
that the observed traffic to/from the CN no longer warrants using RO
(and sending BUs each time the MN moves) or the MN might need to save
space in its binding update list.
For these reasons MN should be free to deregister with a CN at any time
and also ignore a BRR.

> not. Anyways, that's fine as long as we don't have a MUST.

That to. But I think a SHOULD is too strong her for the
same reason that it isn't a SHOULD to immediately initiate a BU procedure
when the MN sends a packet or creates a connection to a new CN.

These pieces are local implementation matters in the MN.

  Erik