Re: [RRG] Properties of mapping solutions

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Iljitsch van Beijnum <iljitsch@muada.com>

    > On 9 jan 2008, at 20:05, Tony Li wrote:

    >> Simply pushing a full map to everywhere is going to be expensive

My contention is that neither extreme end of the spectrum is going to be the
right place, but rather some place in the middle - probably with (as you
suggest) a number of different mechanism options, for places with different
usage patterns/requirements.

    >> Pulling has latency issues.

Yes, but a well-designed system can minimize them. I spent a *lot* of time
identifying i) a lot of optimizations for CONS which would speed up
resolution, and then ii) figuring out which subset made sense to include in a
first-pass trial deployment.

    >> For the places that have only a cache, how do you deal with cache
    >> misses? ... Let's have a conceptual discussion and leave out the
    >> mechanisms, please.

Depends on whether you can stand the latency of the miss. If 'yes', wait for
the resolution. If 'no', design a mechanism to deliver (inevitably in a
less-efficient way) packets which do not yet have mappings.

I kind of like the multi-cast thing myself, but if we decide it's important to
handle 'no', I'm prepared to go off and spend a month or two exploring the
'alternate delivery mechanism' space thoroughly, as I did with CONS
optimizations.


    > It may even be bad enough that the transport people are forced to work
    > around dropped TCP SYNs etc.

Sorry, but IMO in the general case that's unworkable. A few large content
sites, maybe. But in general, deployed base wins.

    > If we want reachability when there are cache misses, we essentially have
    > to create a third infrastructure. .. I used to think this was an
    > attractive solution, but now ... I'm having second thoughts.

Why? Was is problems with a specific mechanism, or something about the general
concept?

As to the latter, if we are going to i) have caching, and ii) situations where
we can't wait for a cache fill on a miss, we're going to have to have
*something*. I am optimistic that a lengthy examination will find some
relatively clean options.

    > the potential for DoS attacks on the third infrastructure

Yes, DoS - I wish we could just use the 'drop the miscreants in a pot of
boiling oil' approach... :-( I'm not sure the second infrastrucure
(ITR/ETR/mapping) is fully DoS protected yet, although it has definitely been
something that's been thought about to a certain degree.


    > If we push out the static mapping info (EID prefix -> RLOCs) as well as
    > the dynamic mapping info (which RLOCs are reachable) we're basically
    > reinventing BGP.

First, I like the jargon "reachability" for the second thing; it's not a
mapping per se, but rather further information about a particular mapping.
Second, it's a good point that they need to be considered separately (in terms
of where we want to be on the push/pull spectrum with them), in part because
they have different lifetimes. Third, it's not really BGP, because BGP
computes (effectively) entire paths, which is an *even harder* problem.

    > It's fairly obvious that we can achieve a single order of magnitude
    > better scaling than we have currently for IPv4

IPv6 is not really much better, as I suspect people will be as resistant to
changing IPv6 addresses as they have been for IPv4, and for the same reasons.
(I would put the odds of IPv6 adopting EID's as pretty low - just like TUBA,
they think there's too much deployed base - ironic how they both cripple their
chances of success for that 'reason', but I digress...)

    > by working per-AS rather than per-prefix, but the question is if we can
    > do much better than that, and if not, whether a single order of
    > magnitude is worth the trouble

Well, there's a theory that if we get the mapping right, we can do lots more
with it: for *example* (and I stress this is only an example, as process
migration was for EIDs - too bad I didn't see the provider independence angle
for EIDs back when, but that's architecture for you - you don't always see all
of what good architecture will buy for you), we might be able to do host
mobility.

    > especially as this only addresses the RIB issue and not the FIB issue.

Yes, but to the extent we would now effectively have EIDs, renumbering to make
FIBs smaller becomes a lot more viable.


    > We can also push out the static mapping info but use a pull model for
    > the dynamic info.

Yes to the second, but for both, really, it's a numbers game. E.g. if the
chance of something being used *before* it's updated is really high, push is
better. If the chance is low, pull is better. For another, if the chance
if it *ever* being used is low, go pull, otherwise go push. Etc, etc... It all
depends on the actual patterns.

    > we can probably assume that any RLOC that we choose is reachable and be
    > correct 98% of the time or more, so there is probably no need for a
    > third infrastructure to avoid lost packets on cache misses.

You're talking about cache misses on reachability info here, right? I haven't
heard anyone propose that we need a mechanism to handle that case; the "third
infrastructure" people have talked of is for cache misses on mapping info, I
thought.

    > (Especially considering that a good part of all prefixes isn't
    > multihomed, anyway.)

Good point. If those are down, they are down hard.


    > With some really hard work it's probably possible to make a BGP
    > implementation that runs on loosely coupled parallel processors

Umm, let's just get a mapping system deployed, eh? The path-selection we can
go back and look at as a separate sub-system later.

And yes, they need to be independent enough that we can do it separately; if
they aren't that independent, I think that's a poor architecture.

    > Part of this is that you can make an operational tradeoff between
    > bringing the routing information to where the packets are and bringing
    > the packets to where the routing information is.

Although you have an interesting point there.

	 Noel

--
to unsubscribe send a message to rrg-request@psg.com 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