Subject: RE: [Mipshop] RE: Last Call Comments on draft-ietf-mishop-hmipv6- 00.txt

From: Soliman Hesham <[email-masked]>
Date: Thu, 20 Nov 2003 01:08:56 -0500

> > => The basic idea is that a fast moving MN will want
 > > to pick a further MAP. However, since measuring the
 > > speed is link layer dependent we could not say more
 > > than that. The actual value is not that important. The
 > > only requirement is that within the same admin domain,
 > > the interpretation of values is consistent. So when a
 > > MN moves to a new network, new values will not be compared
 > > with old ones.
 > >
 > 
 > Suppose I'm not moving fast, not moving slow. How do I 
 > decide if I should
 > use 40 or 7, in my example where MAPs at 100, 40, 7 and 2 
 > are advertised?

=> There is a default algorithm in the spec that you can
use. The algorithm picks the furthest available MAP by default.

 > And, what's meant by fast? 100 kph could be fast in one 
 > operator's network,
 > whereas 30 might be fast in anothers.

=> fast depends on the link layer/system that you're
using and its coverage area size. To optimise any of 
this stuff people would need to optimise on a per-link
basis. If an implementer can't/don't know how to/ disagree ...etc
they can always stick with the default. The Dist is a tool
that can be used for further optimisations when people
are building systems. 

 > Absent any metric on these numbers and criteria for judging, 
 > this seems like
 > an invitation for an interoperability problem.

=> I don't understand this, there is zero chance of 
interoperability problems here. This is a configuration
issue. What interoperability problem do you see? 

Hesham

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 20 Nov 2003 09:24:20 -0800

> use. The algorithm picks the furthest available MAP by default.

But I can't see any case where anything other than the default would be
picked. Can you give me an example?

> that can be used for further optimisations when people

Yes, that's my point. A mobile moving between networks can't formulate the
right decision criteria in the absence of this kind of information, so it
would always use the default. I suppose one could obtain it with CARD, but
that would require an extension.

> issue. What interoperability problem do you see?

Not that interoperability would fail, but simply that it would not be
possible for an operator to achieve the right partitioning of load because
there is not enough information conveyed by the function. A mobile from one
manufactuerer might have different rules for selecting a MAP than another.

Anyway, I agree with Gab that this preference number should be dropped for
now if it would not be too difficult to include it back in later when it is
better defined. I believe it would be a worthwhile effort to try to figure
out how one could provide a mobile with enough information to achieve a
proper load balancing, perhaps through a CARD extension or something like
that, but that should be done in MOBOPTS.

            jak