RE: two perspectives on "site" multihoming

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

> > Dave Crocker wrote:

> > 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.
>
> Kurt Erik Lindqvist wrote:

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

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