Re: on the point of mobility & multihoming

[Brian E Carpenter <brc@zurich.ibm.com>]

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:
> 
> > > 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