RE: on the point of mobility & multihoming

["Kanchei Loa" <loa@ieee.org>]

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
loa@ieee.org

> -----Original Message-----
> From: Brian E Carpenter [mailto:brc@zurich.ibm.com]
> Sent: Tuesday, March 09, 2004 1:43 AM
> To: Kanchei Loa
> Cc: multi6@ops.ietf.org
> Subject: Re: on the point of mobility & multihoming
>
>
> Kanchei Loa wrote:
>
> (Note: some of Kanchei's posts have been delayed by a mailing list
> issue... apologies if this seems out of sequence.)
>
> >
> > > Brian E Carpenter wrote:
> >
> > > 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.
> > >
> >
> > 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.
>
> 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
> > router and ISP ?
>
> 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).
>
> > > 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
> >
> > 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 ?
>
> Yes... but as indicated above, a scenario without BGP fits also.
>
> > 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.
>
> 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.
>
> > 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.
>
> 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
>
>
> > >
> > > Kanchei Loa wrote:
> > > >
> > > > > > 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.
> > > >
> > > > > Brian E Carpenter wrote:
> > > >
> > > > > 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.
> > > > >
> > > >
> > > > 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.
> > > >
> > > > > (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
> > > >
> > > > 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
> > > > loa@ieee.org
> > >
> > > --
> > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > > Brian E Carpenter
> > > Distinguished Engineer, Internet Standards & Technology, IBM
> > >
> > >
>
> --
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Brian E Carpenter
> Distinguished Engineer, Internet Standards & Technology, IBM
>
>
>