On Mon, Nov 10, 2008 at 11:30 AM, Christian Vogt
<[EMAIL PROTECTED]> wrote:
> http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-oriented-stack.pdf

Hi Christian,

I read your paper on the flight to MN. I understand this to be like
strategy B variant B1a
(http://bill.herrin.us/network/rrgarchitectures.html) except that the
GUID is alphanumeric.

Some thoughts:

1. The connection oriented protocol is probably the easiest problem
for strategy-B systems. If push came to shove, SCTP would probably
work though I think we can do better. If you want a challenge, try to
figure out how the connectionless protocol will work. Expecting the
app developer to figure out error correction was reasonable for UDP.
Expecting the app dev to figure out complex reconnection via multiple
source and destination locators is probably a bit much. We'll need a
way to address this in the UDP-replacement itself while keeping it a
lightweight, fundamentally connectionless protocol.

We'll probably want acks built in this time so that layer-4 has a
built-in expectation of packet returns to key the locator-changes off
of. Maybe some sort of "ack now/ack later" bit so that the the
destination stack knows whether the app needs an immediate ack or can
wait a little while and receive a collection of them.

2. I suggest a different approach to legacy app support: have the new
layer 4 treat the old-API IP address as a reformatted name in the new
system. The app may think its talking to 1.2.3.4 but its really
talking to 4.3.2.1.compatibility.net. Then equipment basically keeps
the last IP address they had in the form of a name when IPv4 finally
goes away.

3. Have you considered the differences with variant B1b? If you split
GUID and SID in addition to splitting LOC, then the origin can start
anonymous and the upgrade to a named source if the connection proves
long-lived. The anonymous origin may be limited to a single LOC until
it upgrades with something like a TCP optoin, but that keeps the
protocol light-weight for the short-lived connections.

4. For layer 3 in strategy B I think we'll always want to do
source-dependent routing. In other words, all routes will have both a
source and destination prefix. In the core the source prefixes will
mostly have a zero length but as you get towards the edge the upstream
routes (like the default route) will match the ISP prefix for the
given locator. That makes sure that the multiple LOCs for each host
route out through the correct ISP. As a side benefit, LOC spoofing
gets harder: if a host originates a packet with a false source
address, it'll die at the first router which doesn't have a route for
that source.

Food for thought.

Regards,
Bill Herrin


-- 
William D. Herrin ................ [EMAIL PROTECTED]  [EMAIL PROTECTED]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg

Reply via email to