Subject: Re: [mobile-ip] [Announce] Link Identifier draft.

From: Greg Daley <[email-masked]>
Date: Mon, 02 Jun 2003 09:27:02 +1000

Hi Ed,

Ed Remmell wrote:
> Brett -
> 
> Personally, I think this new option is a bad idea, since it gives little
> extra payback for an increase both in complexity and administrative support.
> I don't understand why the MN needs to be aware of multiple routers when it
> is away from home, it can just use a single current default router
> advertising a global prefix to configure its primary care-of address. This
> is simpler, since it is easier to track reachability (both from the router,
> as well as bi-directional reachability) of a single router. When the MN
> moves from that router to a different router, it most likely needs to select
> a new primary CoA and perform a L3 handover, unless the new router
> advertises the same global prefix.
> 
> The R-bit option (global scope router address) works perfectly fine in this
> case to disambiguate between routers, assuming duplication of link-local
> scope addresses if the routers are on different links.

If two routers on the same link advertise R bits,
(possibly with different prefixes, as is allowed by RFC-2461),
how do you know if the current router is still available?

--> You have to check, or guess.

In movement detection it is not the fact that there are multiple
routers on a link which means that this check has to be done, it
is the possibility of this being the case.

This means that movement cannot be detected reliably by receiving
a single new RA, unless there is some topology restriction (single
router only) or there is additional information in the new RA.

With a LinkID, the MN knows immediately if its current router is
on the same link, or if movement has occurred, without signalling to
the old AR.  I know this is _very_ simple to achieve in the MN.

> 
> In section 9.1 you say:
> "   This document describes a mechanism by which reception of an RA is
>    used by nodes to de-configure the current default router (and associ-
>    ated on-link addresses associated with this router).  Additionally,
>    in many environments, movement detection is used as an instigator for
>    configuration signaling."
> 
> I'd say in response that whenever the MN switches to a new current default
> router when operating away from home, this is likely an indicator that it
> has switched to a new link (not always, but it is safe to assume so - note
> that MIPL defaults to using eager cell switching for movement detection, and
> this algorithm does not work well when there are multiple routers on the
> link, so I think for your typical MIPv6 deployment scenario, given the
> popularity of embedded Linux, you will only have a single default router on
> any given link), in which case it should purge all dynamically discovered
> entries (including Neighbor Cache entries, on-link prefixes, etc.) from its
> routing tree or the equivalent.

This goes back into 'likely' indicators, upon
reception of RAs from routers we haven't seen.
Additionally, it is not safe to assume that
networks will be configured well, nor that they
conform to a single router per link.  This is
unlikely to be a deployment in any serious
ISP's network.

Topology restriction is not an attractive alternative
(certainly not because of a single implementation).

LinkID's specify a strong mechanism for determining
movement.  There is no guesswork.

Greg

---

From: Brett Pentland <[email-masked]>
Date: Mon, 02 Jun 2003 09:41:01 +1000

Hi Ed,

Thanks for taking the time to have a look.

I think Greg covered the details.  I just wanted to reiterate that the 
purpose of LinkID is simply to allow an MN to rapidly determine whether 
a received RA advertising a different set of prefixes to the current 
default router actually represents an advertisement from a new link or 
just from another router on the same link.

Cheers,
Brett.

-- 
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Brett Pentland                         [email-masked]
  CTIE - Centre for Telecommunications and Information Engineering
  Department  of  Electrical  and   Computer  Systems  Engineering
  Monash University, VIC, 3800,                          Australia
  Phone : +61 3 9905-5245                    Fax : +61 3 9905-5358
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---

From: "Ed Remmell" <[email-masked]>
Date: Wed, 11 Jun 2003 09:19:58 -0700

I've thought about this some more...
I guess I'm OK with it. I see how it makes it easier to take something
like MIPL w/ few kernel hacks and make it aware of link movement, so
that it can reliably do eager cell switching regardless of whether or
not there are multiple routers on a given link.
I was a little resistant about moving L2-specific information (link ID)
up to L3 (RA beacons), but the more I think about it, it is reasonable -
although it does require more network administration/configuration to
deploy correctly.
When I implemented a CDPD mobile node, there were similar advertisements
sent by the cellular base stations to the mobile nodes which contained
information such as local cell ID, etc., and the mobile node could use
that information to determine link movement. That was all accomplished
under L3. But, pushing this small piece of extra L2 info (link ID) up to
L3 seems to make sense to me now.

Thanks.
- Ed

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Brett Pentland
> Sent: Sunday, June 01, 2003 4:41 PM
> To: [email-masked]
> Cc: Ed Remmell; [email-masked]; JinHyeock Choi
> Subject: Re: [mobile-ip] [Announce] Link Identifier draft.
> 
> 
> Hi Ed,
> 
> >> Personally, I think this new option is a bad idea, since it gives 
> >> little extra payback for an increase both in complexity and 
> >> administrative support. I don't understand why the MN needs to be 
> >> aware of multiple routers when it
> >> advertising a global prefix to configure its primary 
> care-of address. 
> >> This
> >> is simpler, since it is easier to track reachability (both 
> from the 
> >> router,
> >> moves from that router to a different router, it most 
> likely needs to 
> >> select
> >> The R-bit option (global scope router address) works 
> perfectly fine 
> >> in
> >> this
> > (possibly with different prefixes, as is allowed by 
> RFC-2461), how do 
> > you know if the current router is still available?
> > 
> > routers on a link which means that this check has to be done, it is 
> > the possibility of this being the case.
> > 
> > This means that movement cannot be detected reliably by receiving a 
> > single new RA, unless there is some topology restriction (single 
> > With a LinkID, the MN knows immediately if its current router is on 
> > the same link, or if movement has occurred, without 
> signalling to the 
> > old AR.  I know this is _very_ simple to achieve in the MN.
> > 
> >>
> >> In section 9.1 you say:
> >> has switched to a new link (not always, but it is safe to 
> assume so - 
> >> note
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.486 / Virus Database: 284 - Release Date: 5/29/2003
>  
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.486 / Virus Database: 284 - Release Date: 5/29/2003

---

From: Brett Pentland <[email-masked]>
Date: Thu, 12 Jun 2003 16:30:06 +1000

Hi Ed,

> although it does require more network administration/configuration to

I'm not quite sure that I'm clear on the administration/configuration 
you're referring to.  Our intention was to define a mechanism by which 
routers could automatically agree on a consistent identifier for the 
link in question, so the configuration is basically just turning it on. 
  The main administration task is then just deciding which networks it 
is appropriate to use LinkID on.

> L3 seems to make sense to me now.
And although it represents an L2 concept (the link) it is assigned and 
used by the L3, independant of the particular L2 it is running on (as 
long as it supports the multicast required for IPv6 router discovery).

> - Ed
Thanks for your thoughts.
Brett.

>>>>as well as bi-directional reachability) of a single 
>>
>>router. When the MN
>>
>>>>case to disambiguate between routers, assuming duplication 
>>
>>of link-local
>>
>>>>"   This document describes a mechanism by which reception 
>>
>>of an RA is
>>
>>>>   used by nodes to de-configure the current default 
>>
>>router (and associ-
>>
>>>>   ated on-link addresses associated with this router).  
>>
>>Additionally,
>>
>>>>   in many environments, movement detection is used as an 
>>
>>instigator for
>>
>>>>router when operating away from home, this is likely an 
>>
>>indicator that it
>>
>>>>this algorithm does not work well when there are multiple 
>>
>>routers on the
>>
>>>>link, so I think for your typical MIPv6 deployment 
>>
>>scenario, given the
>>
>>>>any given link), in which case it should purge all 
>>
>>dynamically discovered
>>
>>(certainly not 
>>>because of a single implementation).
>>>

---

From: "Ed Remmell" <[email-masked]>
Date: Thu, 12 Jun 2003 09:21:57 -0700

> is appropriate to use LinkID on.

Ahh, sorry I didn't read the draft in detail before to see the
auto-configuration part. I assumed the link ID was manually
configured/administered.

- Ed

---