RE: on the point of mobility & multihoming

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

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

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

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

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