Subject: Re: [Seamoby] Comments on the requirements draft

From: "Govind Krishnamurthi" <[email-masked]>
Date: Mon, 25 Mar 2002 17:23:29 -0500

> > > > >If the latter were not so, the MN could just use standard Router
> > > > >Discovery on the interface and there would be no need for CAR
> > >discovery.
> >
> > [Govind] Again, this is possible, essentially what you are saying here
> > is explained in Example 2. But the fact is that if there are many such
> > APs then the process in Example 2 is expensive both in time as well
> > as bandwidth efficiency as well as power as pointed in my earlier
>mail.
> > [snip]
> >
>
>I don't understand this. If the MN's power is up for it getting a
>beacon, it presumably brought the interface up that far because it wants
>to use it. What's the bandwidth and power consideration?
>
>The harder case is how the MN finds out that it should bring up the
>interface in the first place.

[Govind]  Yes, it wants to use it. But it does not to waste power on CAR 
discovery and choosing among a plethora of beacons. Exactly my point.
If the MN is going to use it to connect to a beacon, get RtAdv, get 
capabilities etc and then reject it because it does not fit its profile
isn't there a wastage of bandwidth and power?

>
> > >CAR discovery is completely irrelevent if the MN brings up the
> > >interface. Neighbor Discovery is fine for discovering routers - the
>MN
> > >solicits router adverts, the routers send them. What's the problem?
> > >
> > >The only reason for CAR discovery is so that the MN doesn't need to
> > >bring up the interface to discover what's available. The sooner we
>can
> > >agree on that, the sooner we can get to the hard questions, like how
>to
> > >do it.
> >
> > [Govind] I disagree. Again please see my previous answers.
> > I agree completely that we need
> > to get to the actual protocol designing process soon. But I don't
> > agree with your premise in the previous paragraph at all.
> >
>
>Please explain.
>
>You seem to think the problem lies in finding an AR when the MN has
>already brought up an interface. I'm saying that that problem is already
>solved by IPv6 router discovery.
>
>I think the problem lies in the MN finding out that there is another
>wireless technology available, so that it can bring up the interface far
>enough to get the beacon.

[Govind] I think the main miscommunication here is that you say when
this interface is up it is connected to an AP and thats it. In my world,
when the interface is up it is scanning for possible APs and trying to
decide which one to connect to, but not actually connected to one. I agree 
that once L2 layer connectivity is established you can use standard router 
discovery. No argument there. But the only point I'm tryng to make rather 
unsuccessfully here so far is that the correct way to go MAY not be to 
accept the first L2 connection. However, if your
earlier point is true that only one WLAN AP can be found then we don't
have an argument as I agree CAR discovery is not of much use there, except 
probably to indicate to the MN that sticking with the other interface is 
better, in the event that the new AR does not have the
requisite capabilities.
>
>That and doing reverse address translation for router/access point L2
>identifiers to IP addresses.

Regards,
Govind.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Mar 2002 09:48:48 -0800

Govind,

Let's not deep dive on how the MN uses L2 beacon information. This is
fundamentally out of our control, it is an L2 issue.

I think the primary disagreement we have is over whether a complex
protocol is needed to communicate the MN's interface state to the AR so
it can use the CAR information to decide whether to perform an
intertechnology handover, or whether the CAR information should be sent
to the MN and let it decide. I don't see an advantage to the former that
is on the order of the complexity it would introduce into the protocol.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Mar 2002 09:48:48 -0800

Govind,

            jak