Re: Alternatives to source address rewriting (was RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00)

[masataka ohta <mohta@necom830.hpcl.titech.ac.jp>]

Erik;

> I recall reading a draft and slides which proposed using something like RIPv2
> to distribute all the external routes from all the edges to the internal
> routers and hosts (draft-ohta-e2e-multihoming).
>
> Two issues with that aspect of that proposal: 
> 1. Folks seem to be want to put IP connectivity in smaller and smaller devices.
>    Thus even though a laptop with a few hundered meg of memory can easily
> handle
>    the full routing table, it isn't obvious to me that it is a good thing
>    assuming that all hosts that want to benefit from site multihoming will
>    want to store the full routing table.

Smaller device? Read the draft. It says:

  But, with smaller full routing table and larger scale of integration,
  there is no reason not to have full routing table on every end
  system.

That is, my draft takes care of those who don't have much knowledge
on trend of integration scale. But, I can't help those who don't
read it. Smaller and smaller devices are having more and more memory.

In addition, the draft says:

  One may still be allowed, though discouraged, to have local
  configuration with dumb end systems and an intelligent proxy. But,
  such configuration should be implemented with a protocol for purely
  local use without damaging the global protocol.

that people who don't accept the trend of integration are also
taken care of.

Do read the draft.

> 2. Efficiency/timeliness; when a different exit path should taken from
>    a site for a given prefix/address this needs to be communicated rapidly
>    and efficiently so that packets can use the new path.
>    Sending all updates to the Internet routing table to all hosts is one way
>    to convey this, but this means that updates to prefixes which nobody in
>    the site care about might be communicated to hundereds of routers and 
>    thousands of hosts.

But it is non issue

  with smaller full routing table and larger scale of integration,

and faster network speed.

>    And when a single or a few hosts indeed are interested
>    in that update, it will potentially take some time to propagate, especially
>    with a distance vector protocol as the distribution mechanism.

A route can be used only after it is processed by the routing system.

So, it all depends on the routing protocol used.

Those who use RIPv2++ on networks with complex loop topology
will suffer a lot of delay.

Those who use OSPF (not OSPF++ but OSPF as is as it has fields to
carry information required for source address selection) on the
topology won't see much delay.

>    A possible alternative is a packet driven approach at the border router
>    where the arrival of a packet causes a signal back to the host.
>    This signal could be either a source locator rewrite (which will return
>    to the host in packets coming from the peer) or some new ICMP error
>    directly to the host.

For the discouraged case, I prefer using an intelligent proxy server
to choose a source address for a dumb end system.

> It would be good if the WG could explore the tradeoffs in this part of
> the multihoming puzzle.

Before doing that, do you know how much memory can be put on a typical
chip? Do you know how much memory is consumed for typical code for
TCP/IP stack? Do you know how much memory is consumed for a typical
routing table entry?

These are the basic figures for constructive discussion.

							Masataka Ohta