Subject: RE: on the point of mobility & multihoming

From: <[email-masked]>
Date: Thu, 4 Mar 2004 09:30:55 +0200

Msataka-san,

> They have certain similarity that if we are going to solve mobility
> issue in a way different from MIPv6, which is hopeless, minor details
> of M6 design will be affected.

My opinion, for what it's worth, is that we're not out to solve the
mobility issue in Multi6. I don't think we want to advertise that
we will work on mobility, as mobility has out of scope.  If we are
clever, the solution for multihoming will be useful for mobility.
However, I would not like multi6 to get a storm of drafts about
mobility when we are chartered to solve multihoming.

> But, that's all.
> 
> Connection is a transport or application dependent concept, timing
> of which is transport or applicaiton dependent.

Agreed.
 
> OTOH, timing of mobility is governed by movemenet speed of mobile
> hosts and service area of access routers.

Agreed.

> > I second Dave's comment that trying to solve two
> > things at once can be never-ending.
> 
> When I tried it last time, it took about half a year to design,
> implement and install in the field. But as I think the
> design was too much mobility centric, I have modified it,
> part of which is the current 8plus8 proposal.

I don't doubt that you have solved this already, but do you think
having a rash of mobility drafts claming to solve multihoming would
be useful?  

> > Could we restrict ourselves to multihoming,
> > but perhaps the authors of the proposals add a section on 
> Mobility Considerations,
> > so we don't run into incompatiple solutions?
> 
> As long as proposals keep the IP layer connectionless, which is
> of course, even MIPv6 will work automatically (though with all
> the defects) that there is not much to worry about.
> 
> Lear already wrote in his draft
> 
> : 2.1.2.1 Does your solution address mobility?
> :
> :    If so, how are rendezvous handled?  Can your solution handle both
> :    locators changing at the same time?  If so, please explain. Should
> :    it?  If not, how will your solution interact with MOBILEIP-V6 [3]
> :    (MIPv6)
> 
> Is it enough?

It might be, but Dave's comments got me thinking about several other things,
so let me think a bit more to decide if my thoughts are baked or not.

John

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 04 Mar 2004 16:56:10 +0900

John;

> mobility when we are chartered to solve multihoming.

I fully agree with you.

Proposals from those who half understand the relationships
will be really annoying.

Thus, in my proposal, details of possible mobility solution is
dropped, though minimal explanation on why a bit is reserved is
given.

							Masataka Ohta

---

From: "Kanchei Loa" <[email-masked]>
Date: Thu, 4 Mar 2004 16:16:11 -0700

> dropped, though minimal explanation on why a bit is reserved is

In my opinion, you just hit an important issue of multi6 architecture, which
this WG is supposed to work on first. If we take Dave Croker's scenario
(suggested by Geoff Huston) and generalize it, the problem space is the same
as depicted in Geoff's slide (page 3) of "An Architectural View of Multi6
proposals" except that the solid line (wired fixed connection) between the
exit route and ISP is replace by dotted lines (wireless dynamic
connections).

In this architecture, mobility is just a special case of "dynamic ad hoc
multihoming", which has timing restriction on updates and discovery. (You
don't have to call it mobility if that is more IETF political correct). In
Dave's scenario, from IP network's point of view, there is no difference
between a laptop sitting on a bench switching among ISPs because of
interference and a laptop sitting in a car that is moving back and forth
among ISPs.

Should multi6 architecture encompass wireless connections between the exit
router and IPS? Or, Dave Croker's scenario is too far away in the future to
be included in multi6 architecture, which has been focusing on traditional
IP multihoming with fixed connections only? It is up to the WG to decide.
But the architecture document should spell out the rational choice. The
"uncomfortable" wireless issues won't goes away if we just choose to ignore
them or call it something else.

------------
Kanchei Loa
[email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 05 Mar 2004 16:24:44 +0900

Kanchei Loa wrote:

> this WG is supposed to work on first.

I'm afraid you miss my points.

> If we take Dave Croker's scenario
> proposals"

Dave and Geoff completely misunderstand the relationships
between M6 and MIP.

Worse, they don't recognize that shim layer approaches are
making the the IP layer connection oriented by let it maintain
states of connections.

Geoff's presentation is nothing more than rhetorical combinations
of layers without analyzing architectural implications.

Ignore their documents.

						Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Mar 2004 10:11:10 +0100

Masataka,

> making the the IP layer connection oriented by let it maintain

Please do not over-simplify and please do not personalize this
discussion. We all understand, I assume, that site
multihoming implies state. The exact nature of the state, and how
it is maintained and deleted, depends on the layer (or wedge)
that maintains it. 

The architectural analysis is not supposed to *define* the solution,
i.e. choose a particular model for the multihoming state. It is
supposed to analyze the options available and the arguments for and
against them. 
 
> of layers without analyzing architectural implications.

Please do not insult our colleague. This was a first presentation
and we know that a lot more work remains.

> Ignore their documents.

Please do not make such rude statements on this mailing list. 

Regards
   Brian Carpenter
   co-chair

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 05 Mar 2004 10:25:50 +0100

below...

> them or call it something else.

Actually, it isn't up to the WG to decide. We are chartered to deal with
_site multihoming_. That is definitely a different problem space from host
multihoming in the form of ISP roaming.

(Also, I don't see what wireless has to do with it. If I sit in front of two
Ethernet plugs leading to two ISPs, and move my connector from one to the other
every two minutes, the problem is the same - but it is *not* site multihoming.)

   Brian

   Brian

---

From: Geoff Huston <[email-masked]>
Date: Fri, 05 Mar 2004 20:43:23 +1100

> > exit route and ISP is replace by dotted lines (wireless dynamic

I did stress in my presentation to the wg that slide 3 was misleading in a
number of  ways.

There may be multiple parties to the communication, and they may be
simultaneous or spread over time. The "site exit" router may not know
its role with respect to a particular host in some environments.
Also, Erik Nordmark pointed out that  there may be more than one site exit
router in the path.

My point was that while the diagram assisted with describing the space,
it was a diagram that included some assumptions that are not going
to hold in all cases.

    regards,

    Geoff

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 06 Mar 2004 20:50:07 +0900

Brian E Carpenter;

> discussion.

You over-simplify and personalize the discussion. Don't to that.

The over-simplification, for example, is to just say "state"
even though the text you quoted says "states of connecitons".

It is interprested as an intentional rude behaviour, regadless
of whether you said "please" several times.

> We all understand, I assume, that site
> multihoming implies state.

You are lying of the worst lie to state the half truth.

The proper statement on state is that "multihoming for connection
implies states of connections".

> The architectural analysis is not supposed to *define* the solution,

Thank you for acknowledging you are doing nothing other than
abstract nonsense on impossible options.

> Please do not insult our colleague.

It is a proper critic on a presentation of someone who you
yourself choose.

If the quality of document or presentation from the person you
yourself choose, it is perfectly OK to say the document or
the presentation is poor with reasons such as "hetorical
combinations of layers without analyzing architectural
implications".

> Please do not make such rude statements on this mailing list.

You are rude.

You give any technical point, save for the half truth above.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 06 Mar 2004 21:13:02 +0900

> I did stress in my presentation to the wg that slide 3 was misleading in a

One of a mistake, among many, of your presentation was to
say too much about mobility even though there is little
architectural relationship between mobility and multihoming.

It is one of a reason why your presentation should be ignored.

An even worse mistake is that you consider some layer can magically
solve the problem, which is the *ARCHITECATURAL* reasoing for *NAT*.

For proper solutions, all the layers above IP must be involved,
which was the first step of the architectural analysis.

By insisting on sigle layers and pretending not to make any decision,
you drop the core architectural point to consider multiple layers
in a single solution.

Thus, your presentation is no step of moving forward.

					Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 07 Mar 2004 14:08:24 +0100

Kenchei,

I really think you miss my points.

Firstly, this is not the MANET WG, and we are clearly chartered by
the IESG to work on site multihoming in its classical sense, where
if we come down to basics, the main goal is to prevent a BGP explosion.

Secondly, there is nothing academic about observing that it is irrelevant
whether physical links go up and down due to trucks blocking a wireless signal
or due to random wires being disconnected. We are looking for a solution that
doesn't care why the physical signal fails.

  Brian

Kanchei Loa wrote:
> > Brian E Carpenter wrote:
> Now I know where the problem is. In Dave's scenario, the Personal Area
> Network (PAN) surrounding him in the park is the "site", which consists of
> laptop, PDA, game console, headphone, MP3 player, digital camera, and dual
> mode handset (UMTS and 802.11b). The exit routers are laptop with 802.11g,
> and handset with UMTS and 802.11b. Later, Dave's friend Geoff, sitting next
> him on the same bench, join him to work on multi6 drafts. So, Dave's PAN and
> Geoff's PAN are forming a new "site" with 4 exit routers (Dave's
> laptop(802.11g), handset (UMTS, 802.11b), and Geoff's laptop (802.11a) and
> handset  (WCDMA and 802.11g). This new "site" should be able to take full
> advantage of 4 redundant wireless ISP connections, even the interference
> might knock out one or two ISP from time to time.
> 
> If you consider above expanded scenario of a "site multioming" is too
> "non-traditional", then let's try a traditional one. An branch office in
> downtown has 4 exit routers to 5 ISP. Router a connects to ISP A through
> wired cable modem (cost $55 per month) as primary Internet link. Router b
> connects to ISP B through 802.16 wireless link (cost $60 per month) on the
> roof top dish as backup Internet link. Router c connects to  ISP C through
> 802.11a corporate backbone (cost $100 per month) in adjacent building as
> corporate resources access and backup Internet link. Router d connects to
> local community networks (cost $50 per month), which are served by two
> 802.11b providers ISP Da and ISP Db. This branch office is setup to support
> their business in local community. So, router d is as important as other
> exit routers. When the weather is bad or other RF factors, traffic driving
> by disconnects constantly changes branch office's preferred access point.
> 
> My point is that wireless exit connection to ISP is not an invisible wired
> connection. It injects "ad hoc" factor into both traditional and
> non-traditional site multihoming. That is definitely NOT a different problem
> space from _site multihoming_ we are chartered to deal with unless you
> exclude wireless in the charter. The host multihoming with "ISP roaming" is
> just a special case of site multihoming where exit router and host are on
> the same machine.
> 
> > Ethernet plugs leading to two ISPs, and move my connector from
> > one to the other every two minutes, the problem is the same - but it is
> *not* site
> > multihoming.)
> >
> >    Brian
> 
> The "wireless" make  "ad hoc site multihoming" a practical engineering
> problem for any Internet community who follows IETF's lead. Your example of
> plug-and-unplug Ethernet belongs to academic research not IETF.  In above
> scenario if all connection to ISPs are wired links, it won't make any sense
> to create a multihoming protocol by this WG to deal with the situation that
> a administrator plug-and-unplug Ethernet connector of exit routers at will
> every two minutes. However, "wireless" causes the same plug-and-unplug
> scenario a practical engineering problem we have to deal with. My opinion,
> for what it's worth, is that  the arguments of ad hoc multihoming should be
> thrown out if the consensus is that wireless is not in WG's equation.
> 
> In 1992 Dave Clark said "We reject kings, presidents, and voting. We believe
> in rough consensus and running code". In my opinion, majority of the IPv6
> running codes are going to be deployed on wireless networks.
> 
> -----------------
> Kanchei Loa
> [email-masked]

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM

---

From: "Kanchei Loa" <[email-masked]>
Date: Fri, 5 Mar 2004 19:22:21 -0700

[ post by non-subscriber.  with the massive amount of spam, it is easy to
miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

*not* site

-----------------
Kanchei Loa
[email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 08 Mar 2004 08:37:57 +0900

Kanchei Loa;

> Router d connects to

You are applying 802.11b technology wrongly, then.

If the branch office is setup to support their business in local
community, 802.11b link of router d is as important as and should
be as stable as other links of other exit routers.

If a link to an ISP constantly disconects, two links to the ISP
constantly disconnect that the ISP is useless.

Or, you can still use the ISP with the quality for less serious
purposes, which has nothing to do with M6.

> The "wireless" make  "ad hoc site multihoming" a practical engineering

Neither "wireless" nor "ad hoc" means "unreliable" nor "unstable".

							Masataka Ohta

---

From: "Kanchei Loa" <[email-masked]>
Date: Sun, 7 Mar 2004 17:47:24 -0700

> if we come down to basics, the main goal is to prevent a BGP explosion.

Actually, we are in agreement here regarding "the main goal is to prevent a
BGP explosion" for this WG.
But I should clarify that Dave Croker's scenario is not a MANET problem as
you assumed. The combined Dave's and Geoff's Personal Area Network is at
link layer (like L2 bridging). From IP routing point of view it is a single
IP subnet with 4 exit routers to 4 ISPs. There is no IP MANET running
anywhere. However, if there is no BGP running between exit router and ISP,
then it has nothing to do with BGP explosion.

Is multi6 only deal with the architecture where BGP is running between exit
router and ISP ?

> or due to random wires being disconnected. We are looking for a
> solution that doesn't care why the physical signal fails.
>
>   Brian

Agree. We are looking for a solution that doesn't care why the physical
signal fails and the frequency of failing.

In my branch office scenario BGP is running between exit routers and ISPs.
Does this scenario fit multi6 WG charter ?
If the answer is "no", I will rest my case. But please clarify your
definition of "site multihoming in its classical sense" and why my branch
office scenario doesn't fit your definition.

If the answer is "yes", then we are back to the original debate of this
thread.
Multiaddress mulithoming and mobility solutions must incorporate the same
mechanisms:
1. multiplexing in the presence of more than one address pair
2. adding/removing addresses
3.  failover
4.  rendezvous
There is no difference between multihoming and mobility.

In my branch office scenario "traffic driving by disconnects constantly
changes branch office's preferred access point". The physical signal between
exit router and ISP could fail due to (1) plug-and-unplug connectors (wired
connection) (2) weather or other RF factors (wireless connection) (3)
changing distance (mobility). The solution for multihoming designed for (1)
and (2) should solve (3) as well. From IP multihoming point of view,  why
the signal fails is irrelevant to the solution. "We are looking for a
solution that doesn't care why the physical signal fails".

My point, for what it worth, is that we should kill two birds in one stone
because there is only one bird if you get closer and exam it carefully. Both
coming architecture and operation documents should make it clear that
mobility is not an add-on feature for multihoming, such that we could
categorize and evaluation solutions/recommendations accordingly.

Note: How do we word it is another story. MIP has been given IP mobility a
bad name, which is usually related to complex signaling and awkward
tunneling schemes. May be we just call it dynamic multihoming instead of
mobility.

--------------
Kanchei Loa
[email-masked]

>
> Kanchei Loa wrote:
> >
> > > > In my opinion, you just hit an important issue of multi6
> architecture,
> > which
> > > > (suggested by Geoff Huston) and generalize it, the problem
> space is the
> > same
> > > > proposals" except that the solid line (wired fixed
> connection) between
> > the
> > > > don't have to call it mobility if that is more IETF
> political correct).
> > In
> > > > Should multi6 architecture encompass wireless connections
> between the
> > exit
> > > > router and IPS? Or, Dave Croker's scenario is too far away
> in the future
> > to
> > > (Also, I don't see what wireless has to do with it. If I sit
> in  front of
> > two

---

From: dhcnotice <[email-masked]>
Date: Mon, 8 Mar 2004 14:26:57 -0800

Brian,

BEC> Firstly, this is not the MANET WG, and we are clearly chartered by
BEC> the IESG to work on site multihoming in its classical sense, where
BEC> if we come down to basics, the main goal is to prevent a BGP explosion.

There are two different strategic ways to approach site multi-homing.

One is at the site-level, of course. Hence the focus is on network-level
mechanisms. An example would be a network-agile method of addressing
while holding the host portion constant, and then filling in the correct
network portion at the exit router.  Presumably this would leave the
host untouched.

The other approach is at the host-level, where the exit router is
essentially unaware of the mechanism -- return filtering issues
notwithstanding. The model has the host do all the work and can, in
fact, leave the exit router unchanged. So, the host is address-agile.

It is worth noting that this approach has the option of being
implemented at the site level, largely transparent to the host, for easy
adoption by sites. Or it can be adopted at the host level, for easy
adoption by those hosts, without having to recruit site administration
to the effort.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: "Kanchei Loa" <[email-masked]>
Date: Mon, 8 Mar 2004 17:03:22 -0700

There are many factors (technical and non-technical) affecting the decision
to select a specific link layer  for ISP connections. The performance of all
wireless technologies varies with time and space, which is the nature of the
beast.
Brian Carpenter said "We are looking for a solution that doesn't care why
the physical signal fails". I agree with him

-----------------
Kanchei Loa
[email-masked]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Masataka Ohta
> Sent: Sunday, March 07, 2004 4:38 PM
> To: Kanchei Loa
> Cc: Brian E Carpenter; [email-masked]
> Subject: Re: on the point of mobility & multihoming
>
>
> Kanchei Loa;
>
> > Router d connects to

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Mar 2004 13:33:11 +0900

Kanchei Loa;

> wireless technologies varies with time and space, which is the nature of the

There is nothing wireless specific.

Try to use 100 base T with 500m UTP-3 cables and 10 dumb hubs
cascaded.

							Masataka Ohta

---

From: "Kanchei Loa" <[email-masked]>
Date: Mon, 8 Mar 2004 23:20:01 -0700

> Try to use 100 base T with 500m UTP-3 cables and 10 dumb hubs

Well, a connection between exit router and ISP using "100 base T with 500m
UTP-3 cables and 10 dumb hubs" is out of the specification of IEEE standard.
The user won't expect M6 solution would work on an out-of-spec connection
nor should this WG. But the same user would expect M6 solution maintains
reasonable performance (or degrade gracefully) with his "within-spec"
wireless link to ISP independent of the weather condition.

However, there is a possibility that a M6 solution working on the wireless
connection might patch the "100 base T with 500m UTP-3 cables and 10 dumb
hubs" problem (although the link layer might have shut down the interface
already before the IP layer have the chance to take care of it).

--------------
Kanchei Loa
[email-masked]

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 9 Mar 2004 08:57:58 +0100

Dave,

> adoption by those hosts, without having to recruit site administration

I think your second scenario (without a modified exit router) is a 
mobile node. More or less. And I wouldn't describe that as site 
multihoming. There is a scaling component from a administrative point 
of view involved. IMHO the first scenario and a scenario where there is 
interaction between the hosts and the site-exit routers, are site 
multihoming.

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Mar 2004 17:45:56 +0900

Kanchei;

> wireless link to ISP independent of the weather condition.

What, do you mean, "within-spec" of, say, 11b.

With some definition of "within-spec", what performance
is expected by the standard?

To answer the questions, quote the standard, please.

						Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Mar 2004 09:42:59 +0100

Kanchei Loa wrote:

(Note: some of Kanchei's posts have been delayed by a mailing list
issue... apologies if this seems out of sequence.)

> then it has nothing to do with BGP explosion.

Correct; it's effectively a small network (what we've often referred to as
a dentist's office network) which happens to be connected as a subscriber
to several ISPs. But we do expect [RFC 3177] it to have a /48 or /64 prefix 
from each of those ISPs, and it is indeed to keep those out of the DFZ that we
need a multi6 solution. (Yes, this is elementary, but it does no harm to
recall the elementary problem from time to time.)

> Is multi6 only deal with the architecture where BGP is running between exit

No... if we did that, we would not solve the problem.

My point is really that walk-in-the-park example doesn't (in my view)
change the problem space (at least not the problem space that I believe
we are working on).

> Does this scenario fit multi6 WG charter ?

Yes... but as indicated above, a scenario without BGP fits also.

> There is no difference between multihoming and mobility.

I'm afraid I don't think that follows, but I would rather argue the
point when Geoff has written up a first version of the architectural
analysis. However, to scratch the surface of the argument, there
is one physical difference - in the site multihoming case I don't see
that there is a rendezvous issue. The set of connections that may be used 
is defined and configured in advance, whereas in mobility it is unknown 
in advance and requires discovery, rendezvous and AAA mechanisms.

> tunneling schemes. May be we just call it dynamic multihoming instead of

It may be that by *adding* a discovery, rendezvous and AAA package to
the multi6 solution, we will get a new mobility mechanism. We should
certainly keep that in mind in the architecture discussion
   
   Brian

---

From: Dave Crocker <[email-masked]>
Date: Tue, 9 Mar 2004 08:39:13 -0800

Brian,

BEC> My point is really that walk-in-the-park example doesn't (in my view)
BEC> change the problem space (at least not the problem space that I believe
BEC> we are working on).
...
>> signal fails and the frequency of failing.
...
>> Multiaddress mulithoming and mobility solutions must incorporate the same
...
BEC> is one physical difference - in the site multihoming case I don't see
BEC> that there is a rendezvous issue. The set of connections that may be used 
BEC> is defined and configured in advance, whereas in mobility it is unknown 
BEC> in advance and requires discovery, rendezvous and AAA mechanisms.

Multhihoming configuration changes over time, as does the availability
of configured connections to the Internet.  These changes in
reachability are presumed to happen more slowly that with a mobile
scenario, but the the other technical characteristics are pretty much
the same.  (We could quibble about full-scale outages, with no valid
address, but otherwise it is multiple addresses, changing over time.)

"In advance" does not apply to an existing connection when a multihome
access is changed during the connection.

The multihoming scenario that is probably driving folk's sense of
difference between multihoming and mobility is: a) little or no change
to the configuration, b) no need to apply the changes to existing
connections.

This is a useful set of constraints, but it is important to recognize
the way they change the problem space.

BEC> It may be that by *adding* a discovery, rendezvous and AAA package to
BEC> the multi6 solution, we will get a new mobility mechanism. We should
BEC> certainly keep that in mind in the architecture discussion
   
yup.

d/

---

From: "Kanchei Loa" <[email-masked]>
Date: Tue, 9 Mar 2004 10:34:21 -0700

> To answer the questions, quote the standard, please.

Quote from IEEE 802.11 1999 edition
----------

5.1.1 How wireless LAN systems are different

Wireless networks have fundamental characteristics that make them
significantly different from traditional
wired LANs. Some countries impose specific requirements for radio equipment
in addition to those specified in this standard.

5.1.1.1 Destination address does not equal destination location

In wired LANs, an address is equivalent to a physical location. This is
implicitly assumed in the design of
wired LANs. In IEEE 802.11, the addressable unit is a station (STA). The STA
is a message destination, but not (in general) a fixed location.

5.1.1.2 The media impact the design

The physical layers used in IEEE 802.11 are fundamentally different from
wired media. Thus IEEE 802.11 PHYs
a) Use a medium that has neither absolute nor readily observable boundaries
outside of which stations with conformant PHY transceivers are known to be
unable to receive network frames.
b) Are unprotected from outside signals.
c) Communicate over a medium significantly less reliable than wired PHYs.
d) Have dynamic topologies.
e) Lack full connectivity, and therefore the assumption normally made that
every STA can hear every other STA is invalid (i.e., STAs may be "hidden"
from each other).
f) Have time-varying and asymmetric propagation properties.

Because of limitations on wireless PHY ranges, wireless LANs intended to
cover reasonable geographic distances may be built from basic coverage
building blocks.

---------------- end quote --------

The limitations on  802.11b PHY range vary with antenna configuration and
local environment factors, which is the information provided by the ISP to
subscribed users.

I believe we are off-topic here. If you want to discuss what the 802.11b
coverage is under various configurations, we should take it off-line.

------------
Kanchei Loa
[email-masked]

---

From: "Kanchei Loa" <[email-masked]>
Date: Tue, 9 Mar 2004 12:43:44 -0700

Brian,

I still disagree on some of your points regarding the problem space (as
Dave's reply depicted). But I would hold my arguments until Geoff has
written up a first version of the architecture draft (assuming he is going
to address this issue).

Kanchei
---------
Kanchei Loa
[email-masked]

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, March 09, 2004 1:43 AM
> To: Kanchei Loa
> Cc: [email-masked]
> > > > > > as depicted in Geoff's slide (page 3) of "An
> Architectural View of
> > > > Multi6
> > > > > > multihoming", which has timing restriction on updates
> and discovery.
> > > > (You
> > > > > > IP multihoming with fixed connections only? It is up to
> the WG to
> > > > decide.
> > > > > > "uncomfortable" wireless issues won't goes away if we
> just choose to
> > > > ignore

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 9 Mar 2004 20:56:25 +0100

> that there is a rendezvous issue.

I'm not so sure. In mobility, we need to know the current address of 
the correspondent. In multihoming, we need to know which of the 
correspondent's addresses is currently working, and of the working 
addresses, which is preferred. This is not fundamentally different, or 
at least it doesn't have to.

Obviously there are many details that will differ in practice, but 
multiaddressing is multiaddressing regardless of how it's first 
approached. However, I'm not sure if adding all the mobility 
requirements to our list at this time is helpful, the same way I'm not 
convinced rehashing policy and load balancing *now* is helpful. If we 
can come up with a synthesis of what's on the table now that is sound 
both in architecture and security, there should be ample opportunity to 
add the other stuff later. Granted, there is a slight chance we paint 
ourselves in a corner with regards to those issues now, but I'm willing 
to take that risk for the sake of focussing the discussion so we can 
achieve some results.

(And could you guys PLEASE stop repeating each other's postings in 
full? I'm beginning to feel sorry for the poor mailing list archive.)

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 10 Mar 2004 06:39:37 +0900

Kanchei Loa;
 
> cover reasonable geographic distances may be built from basic coverage

So, use it reasonably, just as use 100 base T reasonably.

Or you will suffer, regardless of whatever technology you
might use.

> I believe we are off-topic here.

You are off-topic from the beginning.

							Masataka Ohta

---

From: "Kanchei Loa" <[email-masked]>
Date: Tue, 9 Mar 2004 23:12:59 -0700

> > Dave Crocker wrote:

> Kurt Erik Lindqvist wrote:

> interaction between the hosts and the site-exit routers, are site

Dave's second scenario of host agile solution is a legitimate multihoming
and  "mobile node" at the same time.

Brian Carpenter said " if we come down to basics, the main goal (of this WG)
is to prevent a BGP explosion". He also said "it's (a branch office)
effectively a small network (what we've often referred to as a dentist's
office network) which happens to be connected as a subscriber to several
ISPs. But we do expect [RFC 3177] it to have a /48 or /64 prefix from each
of those ISPs, and it is indeed to keep those out of the DFZ that we need a
multi6 solution".

Imagine this WG defines a host agile multi6 solution, which allows a
"dentist's office network" to connect to multiple ISP with regular IP
connections (no BGP) plus AAA and/or DHCP exchanges. The "scaling component
from a administrative point of view involved" is upgrading software on
hosts, which is small price to pay for a small site with no networking
knowledge (they need to keep OS up-to-date for patches and  security bugs
anyway). These large numbers of small sites are kept out of the DFZ that
helps BGP explosion problem.

If you compare basic mechanisms to achieve host agile multihoming and
mobility, the difference is null. My point is that if  mobility is treated
as a component outside multihoming, the "mobile node" attitude is going to
bias toward network agile solution, which is more deployable at large site,
where network expertise is abundant. Small to medium site would prefer host
agile solution because network administration tasks are kept at minimum or
don't exist at all.

--------------------
Kanchei Loa
[email-masked]

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 10 Mar 2004 08:51:35 +0100

<chair-hat-on>

> coverage is under various configurations, we should take it off-line.

yes :-)

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 10 Mar 2004 08:55:26 +0100

On 2004-03-09, at 20.56, Iljitsch van Beijnum wrote:

> both in architecture and security, there should be ample opportunity 
> to add the other stuff later. Granted, there is a slight chance we 
> paint ourselves in a corner with regards to those issues now, but I'm 
> willing to take that risk for the sake of focussing the discussion so 
> we can achieve some results.
>

While I am sure that we at one point will start to see convergence in 
the requirements for multi6 and mobility, I actually would like to 
leave mobility our for now. The scope of multi6 is wide enough as it 
is. Let's look at this problem first. Once we have a better 
understanding of the impact and of architectural analysis we need to 
get input from a number of sources. Applications and mobility tends to 
be highest on my list.

I am just afraid that if we start mixing mobility in from the 
beginning, we will be in way over our heads...

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 10 Mar 2004 08:59:34 +0100

> agile solution because network administration tasks are kept at 

I am not arguing that we should leave the "mobile aspect" out. I am 
arguing that we need to take one step at a time.

For all I know, we haven't even decided if we are looking for one 
solution, multiple solutions, a flag-day-solution or a phased approach. 
Once we are starting to agree on the various architectural aspects and 
analysis, the threats models and get input from other groups - we can 
answer those questions, as well as what the relationship between 
mobility and multihoming is.

- - kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 10 Mar 2004 09:06:57 +0100

On 10-mrt-04, at 8:55, Kurt Erik Lindqvist wrote:

> I actually would like to
> is. Let's look at this problem first.

> beginning, we will be in way over our heads...

That was what I was trying to say in the part that you quoted.  :-)

But that doesn't mean we should continue to ignore mobility forever as 
there is significant overlap.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 10 Mar 2004 19:59:15 +0900

Kurt;
 
> beginning, we will be in way over our heads...

Which is what Geoff did with his rhetorical presentation
without understanding the implication of mobility for
multihoming, which is partly why Geoff's presentation
is useless and to be ignored.

						Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Mar 2004 15:00:02 +0100

I would like to make it clear that the co-chairs absolutely
disagree with Mr Ohta's comment on Geoff's presentation.
We believe it is very useful, although it is only the start of a 
major effort.

   Brian

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 10 Mar 2004 17:43:33 +0100

I want to second Brian. And I think that Ohta-san is putting words in 
my mouth that I most certainly do not agree with.

- - kurtis -

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 11 Mar 2004 08:15:01 +0900

Brian and Kurt;

>>We believe it is very useful, although it is only the start of a

As both of you are responsible for choosing Geoff as the
presenter and wasted our time, it is not surprising that you
don't admit your faults and react even against words in Kurt's
own mouth.

However, with no technical content, your reactions are
no constructive.

Just admit the technical fact that Geoff's presentation was
technically poor and misdirected, for which both of you
are guilty.

							Masataka Ohta

---

From: David Kessens <[email-masked]>
Date: Thu, 18 Mar 2004 20:54:25 -0800

Ohta-san,

> technically poor and misdirected, for which both of you

The multi6 working group is trying to tackle a very hard problem. The
differences between the proposals are huge. Despite all this, we have
had very good discussions without any personal attacks except for
yours.

Due to the diversity of opinions, it is inevitable that there are
occasional disagreements. It's ok to disagree. It is not ok to
verbally assault the person that you disagree with. It is not
necessary to repeat your opinion over and over again in a very
aggressive manner while it is clear that there is no significant
support for your opinion.

Your attacks on the chairpeople, Geoff and many other contributors to
this working group are inappropriate and should stop.

I think that the whole working group and the chairpeople are doing a
great job. We know that you have interesting ideas, please help the
group by contributing to the working group in a civil manner so that
the working group can focus on the problems that need to be solved.

Thanks,

David Kessens
---