Chris -
I agree with you that the overhead created by a host-based solution
needs to be carefully looked at. Yet I don't think that high overhead
is inevitable for host-based solutions. As you say, it depends on
protocol design. Take, e.g., the overhead that is needed for
connectivity verification: Whereas host-based solutions cannot
aggregate explicit probing messages as efficiently as network-based
solutions, host-based solutions can potentially use implicit probing
more efficiently than network-based solutions because hosts have session
state that may include useful connectivity information. So the
overhead-efficiency of a host-based solution depends to a significant
extent on how effectively the solution exploits such session state.
Also, keep in mind that there may be some boundaries in administration
to be aware of with respect to hosts and network traffic. (network
admin
people manage traffic, system-admin folks manage hosts, in someplaces
this is a challenge)
Isn't that a challenge only if the host configurations needs to be
coordinated with the network configuration? A good protocol design
would IMO avoid such a dependency between the hosts and the network.
nat66 or nat(anything) is a little scary in that it implies (to me)
the
injection of lots of state into the 'network' (at least some points in
the network) and thus introducing large amounts of complexity and
troubleshooting complications. [...]
Note that NAT66 (as well as Six/One Router Unilateral mode) is stateless
because it uses one-to-one address mappings. It does need to be
configured with the pair of internal and external routing prefixes, but
there is no per-session state. Hence I consider these solutions in fact
quite feasible. Sure, their lack of transparency is a disadvantage. But
this is a phenomenon that is being dealt with already today.
Sure... my point really was that there seem to be equal reasons for
each, and ratholing on just one seems counter productive in the long
term.
Yes. We are definitely on the same page here.
One strategy to permit the network to scale in the face of 'more
addresses' or 'more networks' or 'more multihomers' is great. Another
strategy to be used for smaller-scale multihoming like
home-network-based multihoming (cell, wifi, broadband-cable) also
seems
like a good thing.
Yes, good point. And again this implies that RRG should not focus on
finding a one-size-fits-all solution. RRG should rather develop a
"solution toolbox", including both host-based and network-based tools,
so that different causes for the routing scalability problem can be
addressed separately, and hence in general more effectively.
- Christian
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg
