Re: Shim6, was: Re: filtering /48 is going to be necessary

[William Herrin <bill () herrin us>]

2012/3/16 Masataka Ohta <mohta () necom830 hpcl titech ac jp>:
> William Herrin wrote:
> > > As LS requires less intelligence than DV, it converges faster.
> >
> > I do believe that's the first time I've heard anybody suggest that a
> > link state routing protocol requires "less intelligence" than a
> > distance vector protocol.
>
> I mean "intelligence as intermediate systems".
>
> DV is a distributed computation by intelligent intermediate
> systems, whereas, with LS, intermediate systems just flood
> and computation is by each end.

That's basically wrong.

Both systems perform computation on each router. Link State performs
much more complex computation to arrive at its export to the
forwarding information base. In fact, Distance Vector's calculation is
downright trivial in comparison.

The difference is that Link State shares the original knowledge, which
it can do before recomputing its own tables. Distance Vector
recomputes its own state first and then shares each router's state
with the neighbors rather than sharing the original knowledge. The
result is that the knowledge propagates faster with Link State and
each router recomputes only once for each change. In some cases,
distance vector will have to recompute several times before the system
settles into a new stable state, delaying the process even further.


> > > Here is an exercise for you insisting on DNS, an intermediate
> > > system.
> > >
> > >      What if DNS servers, including root ones, are mobile?
> >
> > DNS' basic bootstrapping issues don't change, nor do the solutions.
> >
> > The resovlers find the roots via a set of static well-known layer 3
> > address
>
> You failed to deny MH know layer 3 address of its private HA.

Here's a tip for effective written communication: the first time in
any document that you use an abbreviation that isn't well known, spell
it out.


> It's waste of resource for MH have well known IP address of
> root servers and domain names of its private DNS server and
> security keys for dynamic update only to avoid to know IP
> address of its private HA.

There's no reason for the Mobile Host to know the IP addresses of the
root servers. Like any other host, including MH in your plan, it
already knows its domain name and the IP addresses of its private DNS
servers. That leaves only the security key.

So, by your own accounting I swap knowledge of a topology-independent
element (the security key) for a topology-dependent element (an IP
address) which may change any time you adjust your home agent's
required-to-be-landed network with all of today's vagaries around the
renumbering problem.


> > For that matter, how do you solve the problem with your home agent
> > approach? Is it even capable of having multiple home agents active for
> > each node? How do you keep them in sync?
>
> I actually designed and implemented such a system. Multiple
> home agents each may have multiple addresses.
>
> If some address of HA does not work, MH tries other addresses
> of HA.
>
> If some HA can not communicate with MH, CH may try to use other
> HA.
>
> There is nothing mobility specific. Mobile protocols are
> modified just as other protocols are modified for multiple
> addresses.
>
> In practice, however, handling multiple addresses is not
> very useful because selection of the best working address
> is time consuming unless hosts have default free routing
> tables.

In your home agent architecture, it doesn't matter if they can have
multiple addresses. It matters if they can have the same address.
Otherwise you're pushing off the generalized continuity of operations
problem. One which my DNS add/drop approach handles seamlessly and at
a granularity of the individual services on the mobile host.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin () dirtside com  bill () herrin us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004