Hi Tony,
In:
Re: Fundamental objections to a host-based scalable
routing solution
http://www.irtf.org/pipermail/rrg/2008-November/000266.html
You wrote, quoting Eric Fleischman:
>| My personal belief is that I'd like us to converge soon on a
>| routing-only solution. I think that it is time to begin to wrap
>| the theoretical discussions up and proceed to modeling and
>| simulation and limited deployment experimentation. Failing
>| that, I would like to better understand why the RRG community
>| hasn't yet converged on the desirability of map-and-encaps as a
>| desirable RRG vector.
>
> There is a portion of the community (significant, IMHO) that feels
> that there are significant drawbacks to the map-&-encap strategy.
> While I can't claim to represent all of them or even a significant
> breadth of their opinions, there are some issues that have been
> raised.
>
> - Map-&-encap doesn't solve the problem where it truly occurs: at
> the host. The convolution of locator and identifier happens
> precisely because the transport layer has reused the address as
> part of the connection identifier. Until we change this, we're
> simply band-aiding around the problem. And band-aids really
> aren't the way to create a lasting architecture. Please note that
> this also implies that routing-only solutions aren't the correct
> direction.
I understand your last sentence means that souping up BGP to cope
with arbitrary numbers of PI addresses would not be the correct solution.
I think there are at least two interpretations of this ID / LOC question.
1 - The routing system forwards packets according to a LOC
address.
Due to outages in links between ISPs and multihomed end-user
networks, (TE too?) and due to choices of different ISPs etc,
the physical location of an end-user network's connection to
the core changes from time to time.
Therefore, to keep a session going, the LOC sometimes has
to change for packets in a given session.
With current protocols, host stacks and applications, hosts
use the ID address as an ID for other hosts, and for
themselves, and create sessions based entirely upon this
ID address.
So far, no problem.
The problem is that the routing system and the hosts both
use the one thing for both purposes - the "IP address".
Therefore, since we can't or don't want to change the
routing system, we should change the protocols, host
stacks and applications so that hosts and their sessions
are identified by some ID thing which is separate from
what the routing system uses (a LOC) for forwarding
packets.
2 - At present, Internet protocols use a single thing - the
IP address - for identifying hosts, for establishing and
continuing sessions and for forwarding packets.
While we could change hosts as described above, there
are objections to this on grounds of extra traffic, extra
complexity, extra dependence on fast, reliable carriage of
this extra traffic etc.
So we could say that the problem is in the hosts as noted
above, and also in the slow, costly, unreliable links they
operate over which make it impractical to solve the problem
by changing host stacks and applications so they separate ID
and LOC.
Restating this: We could say the problem is that hosts don't
all have arbitrary CPU and RAM resources, and that they don't
all have the fast, 100% reliable, global, communications
needed to implement host-based multihoming, such as with an
effective ID / LOC split implemented in the stack, with all
applications using a hostname based API.
Instead, we say the problem is in the routing system which
can't cope with the very large numbers of separately
advertised prefixes and the changes to where packets addressed
to each prefix should be forwarded to, which result from the
current use of IP address for both LOC and ID purposes.
Therefore, since we think pushing the solution to the hosts
has serious problems, we resolve to revamp the routing system
in the DFZ, and in ISPs, to the end-user networks' CE routers,
to cope with the current usage of IP addresses.
One way to do this is for the routing system to dynamically
generate and attach a LOC to all packets being sent to end-user
networks, and then to forward the packets to those networks
based on this LOC, rather than the IP address.
This is the approach of the core-edge separation schemes:
LISP, APT, Ivip, TRRP and Six/One Router.
I like the second view. I support the existing division of labour
between:
1 - Hosts and all but the CE routers in end-user networks.
(Thanks Noel for prompting me to add these routers.)
2 - The routing system: the DFZ, the ISP's network, the PE
routers of the ISP and the CE routers of the end-user
networks they connect to.
I think the routing system should rise to the occasion, give hosts
and most of the end-user network what they have already - stable IP
addresses - and handle mulithoming, TE and portability within the
core of the network, with some involvement of the end-user network's
CE routers.
I will respond to your critiques of map-encap in a separate message.
- Robin
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
