Subject: [RRG] Mobility considerations in proposal evaluation

From: Randall Atkinson <[email-masked]>
Date: Thu, 21 Feb 2008 07:04:36 -0800

Earlier Scott Briwm wrote:
% Therefore we cannot put specific mobility requirements on our routing
% and addressing architecture.  We can, however, look at what mobility
% capabilities a particular approach *excludes* and have opinions about that.

Au contraire, I thnk it would be entirely reasonable and proper for the RG
to consider the mobility capabilities provided by each proposal here in the
course of evaluating the sundry proposals.

This RG might have chosen to limit its consideration to architectures,
and to exclude consideration of specific protocol proposals.  The RG
did not make that choice.  In that case, this discussion might be different
than it is (in various ways).

However, this RG is actually considering recommending none, one,
or more protocol proposals to the IETF.  As the RG is already well
below architecture and well into protocol-specific issues (I think Dino's
quote a while back was "We skipped research and are in engineering"),
it seems entirely reasonable to evaluate the sundry proposals based
on the actual mobility capabilities that the proposal provides, enables,
and/or disallows.

Had the RG limited itself to architecture, one  might well reach a different
conclusion, but the RG is deeply into engineering at this point (so that ship
has sailed long since :-).

Bottom Line:
    I disagree that the only legitimate question is
    whether a particular approach excludes mobility.

Cheers,

Ran
[email-masked]

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: Tony Li <[email-masked]>
Date: Tue, 26 Feb 2008 00:52:32 -0800

> on the actual mobility capabilities that the proposal provides,  

Note that this was not our intent and I, for one, continue to try to  
drag us back to research, albeit kicking and screaming...

Tony

---

From: "William Herrin" <[email-masked]>
Date: Tue, 26 Feb 2008 12:02:16 -0500

>  drag us back to research, albeit kicking and screaming...

Tony,

Out of curiosity, which part of the problem space do you think would
benefit the most from additional basic science before turning it over
to an engineering effort?

Regards,
Bill Herrin

-- 
William D. Herrin [email-masked] [email-masked]
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Tony Li <[email-masked]>
Date: Tue, 26 Feb 2008 09:34:45 -0800

> to an engineering effort?

Bill,

I believe that there are significant chunks of the solution space  
outside of the pure routing architecture area that are worth  
exploring.  The input that we've seen from Mark Handley suggests that  
we've been thinking very much inside of our box and that there are  
alternatives.

Even within the routing area, I don't believe that we've fully  
explored the solution space in either the mapping area or in the  
actual relaying mechanism.

On the relaying front today, we have encapsulation and translation.   
What else is there?

On the mapping area, we have push systems and pull systems.  Both  
have substantial drawbacks.  Are there better hybrids?  Are there  
alternatives?

I'd certainly welcome convincing arguments that we've done a decent  
job in considering either of these solution spaces.

Tony

---

From: "William Herrin" <[email-masked]>
Date: Wed, 27 Feb 2008 13:45:08 -0500

>  we've been thinking very much inside of our box and that there are

Hi Tony,

Lets step outside the box for a moment. Suppose we organize our
network by hostname instead of by network address? We don't want to
lose any of the hostname's functionality when we do this; the hostname
should still be a logical organization outside the scope of the
network location. So we aren't going to route by hostname; we'll still
have some sort of address under the hood. What would that imply for
the routing and addressing system?

Lets do two things to the network address:

1. Let's make it strictly ephemeral. It can change at any time, even
in the middle of communications. Only the hostname is sure to stay the
same.

2. Each machine gets multiple addresses, at least one for each
upstream. This means that the routers need to propagate addressing
information downwards so that each client picks up a reasonable set of
addresses.

Since these addresses are ephemeral and the machine is expected to
manage multiple addresses, they need only be carved from each
provider's PA space. What's more, direct allocations from the
authorities can be reserved for only those providers are have more
than a couple upstreams themselves. So, you get near the optimal
hierarchical aggregation of address space.

Now each of the top-level transit AS's needs an address block which it
has to propagate much like BGP does now, but when that address block
needs to expand it can automatically get a larger one from the
addressing authority and then expire and return the old smaller one.
Subsets of that address block propagate downward to anyone who isn't
big enough to have more than half a dozen upstreams or big peers. This
is a fully automated process. When more addresses are needed, the
request bubbles up, the new larger block is sent down and the prior
block is expired, all over the course of a few minutes. The same thing
happens between the top tier providers and the address authority.

The biggest challenge with this model is that routing largely becomes
a client-side responsibility. The two communicating endpoints have to
select and migrate between various currently-assigned addresses. This
will require some sort of formal routing policy language that can be
pushed down so that they know which routes their advised to use.

Stop.

The most critical problem with all this is that we'd have to rip out
and replace the guts of the Internet to attempt it. Like with IPv6,
this system would have to operate dual-stack for a decade. Like with
IPv6 there would be billions of dollars of extra cost with little or
no benefit until deployment was ubiquitous enough that we could start
withdrawing the current IP system from use.

If you have a notion for an out-of-the-box approach that doesn't
suffer from this problem, I'm all ears. I note that we just went
through a decade's worth of research on IPv6 and didn't find one. For
better or for worse, IPv4 bounds the box we're stuck with.

>  On the relaying front today, we have encapsulation and translation.

Good question. We've known about encapsulation and translation in the
IP world for at least 15 years now in various applications like GRE
and NAT. There's not a lot of mystery about how they work or what the
pitfalls are.

There are also various incarnations of loose source routing which
we've discussed.

Is there anything else? Do you have an inkling what it might look
like? I'd hate for history to look back and say we suffered a failure
of imagination but it's also possible that there isn't a fourth avenue
to explore that's achievable from where we are today.

>  have substantial drawbacks.  Are there better hybrids?  Are there

Better hybrids is an engineering question. Ain't nothin' but a theory
until we build a few prototypes and try them out.

Alternatives? Information theory has some useful things to say about
information flow but the last I heard there are really only five ways
to get information:

1. You're told (unsolicited).
2. You seek and find out (solicited).
3. You're born with it (instinctual).
4. You extrapolate it from information you already have (deduction).
5. Divine inspiration.

Push and pull correspond to the first two. If someone has a lead on
routing protocols that work using the last three, I'm all ears.

Perhaps the Angelic Routing Protocol where at each router the packet
briefly stops and prays for guidance. Loss only occurs when packets of
insufficient faith are tempted down the wrong path. Verily I tell
thee, all DFZ scalability problems can be solved with with ARP.

Regards,
Bill Herrin

---

From: Brian Dickson <[email-masked]>
Date: Wed, 27 Feb 2008 18:37:44 -0500

> routing protocols that work using the last three, I'm all ears.
Not so much routing protocols, but forwarding mechanisms.

Note that this depends on some signaling on reachability, either 
explicitly flooded,
e.g. as a new SAFI carried by BGP, or reactively produced, e.g. ICMP 
unreachables.

4. Extrapolate.

Use addressing (for dual-homing) which encodes *both* uplink addresses, 
and facilitates easily swapping which of two addresses to use.

This effectively embeds the Identity *in* the Location.

Given: PA assignment A, and PA assignment B, each of length <= 64.

Build: Addresses A + (bits) + B + (bits), and B + (bits) + A + (bits). 
Make both "real" (either with 1:1 NAT on CPE router(s), or as actual 
interface addresses on hosts).

There are effectively 2xN bits of host addressing, for every N bits of 
prefix space delegated from the PA blocks.

If a /56 is given by A, and a /56 is given by B, there are 8+8 = 16 
total bits for mapping/assigning to hosts/subnets. (1:1 NAT is left as 
an exercise for the reader.)

So, a home user would be able to support 65K dual-homed, globally routed 
and reachable "EID" addresses.
And a site given a /48, would have 32 bits of host space available - the 
amount of space in IPv4. (!!)
I think that both of the above should suffice for the vast majority of 
sites that don't qualify for or want PI space.

How does it work?

If either the host under A's interface, or all of prefix A, is 
unreachable, flip top and bottom 64-bit component (or do a look-up based 
on the bottom 64-bit component).

Cool observation: The intersection between Interface Identifiers built 
using EUI-64 (which begin with OUI-24 values), and the Unicast address 
space's top 64 bits is: nil, nada, nothing.
2000::/3 (truncated at 24 bits), is a range that does not appear at all 
in OUI-24.
This means that there is no ambiguity or overlap between autoconfigured 
interface identifiers, and prefix-based dual-homed addressing of this sort.

So, if we presume that swapping the top and bottom 64-bits of a 128 bit 
address (in a fixed location) is as easy to do as 1:1 NAT in hardware, 
there is a good chance that most current hardware should be able to 
perform this in the fast path.

The addition of an unreachable SAFI in BGP for more-specifics from PA 
blocks is an important optimization.

Note also, that the swapping of top/bottom 64-bit values is something 
that could be done by the IP stack itself, in response to ICMPv6 
messages, after vetting the sanity of the bottom half as a destination 
address.

I'm not sure if this is clear enough; perhaps I should write it up as an 
actual I-D, and/or present this at Philedelphia.

Brian Dickson

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 28 Feb 2008 14:57:10 +0100

On 27 feb 2008, at 19:45, William Herrin wrote:

> have some sort of address under the hood.

In theory, we have that. But people still care way too much about  
addresses to change them whenever the routing system needs them to be  
changed. Most important reason for this is firewalls. When filtering,  
you really need to have something to filter on in every packet. Which  
means you filter on the address, not on the hostname, because the  
hostname isn't in the packet.

> in the middle of communications. Only the hostname is sure to stay the

Been there, done that: shim6, MIP.

People simply refuse to let go of their (provider independent)  
addresses. We could of course declare the problem solved and if people  
don't want to use the solution, that's their choice but not our  
problem. Especially not for those of us making a living from selling  
bigger and bigger boxes.

But I guess we're not doing that otherwise we wouldn't be having this  
discussion.

> this system would have to operate dual-stack for a decade.

Replacing a lot of stuff doesn't automatically mean it has to take a  
decade. The reason that IPv6 is so difficult is because EVERYTHING  
touches IP addresses, and you need to update the entire chain before  
you can use the new type of addresses, including applications, which  
have eternal life. Only a million or so boxes do inter-domain routing,  
and I've never heard of anyone using 10 year old software on those  
boxes in production.

> For better or for worse, IPv4 bounds the box we're stuck with.

The endgame for IPv4 is about to start. No point wasting time on IPv4- 
specific solutions.

> to explore that's achievable from where we are today.

Maybe this would be a good point to start up the biannual geographic  
routing discussion again.

> 2. You seek and find out (solicited).

What about: the holder of the information tells a third party, the  
party needing the information asks the third party = a rendezvous point.

Note that you can't see and find out routing information from the  
source, because you need to know how to talk to the source to do that,  
and the routing information is exactly what lets you do that.

Of course this can be solved with an overlay network a la ALT but I  
see a number of downsides there.

> insufficient faith are tempted down the wrong path.

:-)

> Verily I tell

Sure, right after we solve the inter-domain broadcast scalability  
problem.

---

From: "William Herrin" <[email-masked]>
Date: Thu, 28 Feb 2008 09:29:44 -0500

>  The endgame for IPv4 is about to start. No point wasting time on IPv4-

Iljitsch,

That's a remarkably persistent rumor but I asked my ISP and they set
me straight: for all the chatter there are more sightings of sasquatch
and the abominable snowman than there are of IPv6.

While I say that half-facetiously, it's really only half. IPv4 will be
with us for the foreseeable future. Focusing our efforts on IPv6 would
amount to counting our chickens before the hen finishes laying the
eggs.

Regards,
Bill Herrin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 28 Feb 2008 16:18:27 +0100

> and the abominable snowman than there are of IPv6.

O really?

# tcpdump -p -c 100 -w /tmp/dumpfile port 53
# tcpdump -r /tmp/dumpfile ip6 | wc -l
reading from file /tmp/dumpfile, link-type EN10MB (Ethernet)
       10
# tcpdump -r /tmp/dumpfile ip | wc -l
reading from file /tmp/dumpfile, link-type EN10MB (Ethernet)
       90

So 10% of the DNS packets to/from my server are IPv6.

> amount to counting our chickens before the hen finishes laying the

Please read carefully. What I'm saying is that a solution that only  
works for IPv4 is a bad idea. And what you're saying is that a  
solution that only works for IPv6 is a bad idea. Before I go and  
disagree with that, please note that this leaves on the table all  
solutions that work with both IPv6 AND IPv4.

The average size of the address blocks the RIRs give out was 30320  
addresses for IPv4 in 2007 (down from 35765 in 2005). Let's round this  
down to /18. There are currently 1099.4 million addresses left, that's  
67k additional prefixes before we're out of IPv4 space. Or, a  
different calculation: we'll be out of IPv4 space in 5 years, global  
routing table growth is about 16% per year, 250k*1.16^5 ~= 500k. You  
can buy routers NOW that can (or at least claim to) handle 2 million.  
IPv4 will run out of addresses much faster than it will run out of  
routing slots.

IPv4 is a little over 25 years old now. This suggests that we'll have  
to live with IPv6 for several decades after we've made the transition,  
which gives us ample time to run into trouble with the routing table  
size.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Feb 2008 15:18:19 +1300

On 2008-02-29 03:29, William Herrin wrote:
> with us for the foreseeable future. 

That's not in dispute. The "end game" is that there won't be any new v4
address blocks to play with three years from now, which makes the notion
of a backwards-compatible loc-id split within the v4 address space
"courageous" to say the least...

> Focusing our efforts on IPv6 would

...whereas IPv6 gives us ample opportunity to use existing rgeistries
to support a namespace split, and to deploy a hybrid solution that
uses IPv6 address space to support the IPv4 legacy indefinitely.

    Brian