Subject: Re: [GROW] Call for GROW WG adoption of grow-overlapping-routes

From: [email-masked] (Noel Chiappa)
Date: Fri, 31 Aug 2012 12:02:38 -0400 (EDT)

{Apologies to the list for the slight derail I started, but it's an
interesting topic, and also one of my hot buttons... :-}

On the actual subject of the document, I too agree it would be good to have a
document which looks in detail at aggregation in destination-vector routing
architectures; there are indeed some interesting 'issues' when you try and
automatically start aggregating more-specifics.

    > From: Warren Kumari <[email-masked]>

    >> Doing traffic engineering by injecting more-specifics into the global
    >> destination-vector routing is a top pick on my list of 'optimal
    >> illustration for hammer-nail syndrome'

    > there are a large number of folk that are currently doing this ..
    > Removing their ability to use this "feature" because it violates ..
    > views of elegance seems, um, impolite at best.

First, 'elegance' isn't abstract - doing things the ugly way has real costs
and disadvantages, and it's those I really care about: 'elegant' is
effectively just a short-hand for all the upsides.

Second, I never advocated taking that mechanism way _unless there was
something else available_; of course we're running an operational system that
a large part of the world's population has come to rely on. But 'we do it
this way because we've always done it this way' is no way to run a railroad.

    > From: Nick Hilliard <[email-masked]>

    > No-one's going to argue that multihoming by multiple prefix
    > announcement isn't a pile of poo. It's just that all that all the
    > alternatives are even worse.

How is using a {location->identity} binding layer worse? (And please read
the next bit before you answer...)

    > All the alternatives are significantly more complicated in a variety of
    > different ways, and all open up many more and many more complicated
    > failure modes.

So, because the newer Unix/Linux file systems are "more complicated in a
variety of different ways", with "more and many more complicated failure
modes" we should go back to the v6 one?

Of course not. The new systems have lots of good properties (including better
scaling); and although they are indeed considerably more complex (with
attendant increase in number of failure modes), they also have stuff added to
try and make them even more robust - one of their features - (albeit at a
cost of even more complexity).

And don't forget that your 'simple' alternative has costs and failure modes
of its own - all those extra routes in the DFZ create problems when tables
overflow, mean longer convergance times after major topology changes, etc,
etc, etc.

Look, simple systems are wonderful. I love (and prefer) simple systems.
However, they often have issues (e.g. don't scale well), and you have to use
something more complex. Deal.

	Noel

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 31 Aug 2012 18:31:12 +0100

> automatically start aggregating more-specifics.

at the RIB layer, yes.  At the rib->fib conversion layer, you can do a lot
more as you're going to end up with an N:M mapping between prefixes (N) and
next-hops (M), so it's relatively easy to delete more specifics if it
happens that they have the same NH as the covering prefix.  Obviously you
can't do this at the RIB layer as easily because you can't afford to lose
the information there.

So the idea is good; it's just being applied to the wrong layer.

Nick