mailing list archives
Re: shim6 @ NANOG (forwarded note from John Payne)
From: Iljitsch van Beijnum <iljitsch () muada com>
Date: Tue, 28 Feb 2006 20:04:02 +0100
On 28-feb-2006, at 16:34, Todd Vierling wrote:
A B Y
C C C D Y
All else being equal, X will choose the path over A to reach Y.
There's plenty of route mangler technologies out there that provide
overriding BGP information to borders that trumps path length.
is often not as equal as you seem to expect.
It's time to wake up and smell the intelligent routing trend. The
usefulness of prepending is rapidly dwindling. Don't try to push
it as a
future-compatible solution; it is not. Prepending is not a tool;
it is a
hack that has outlived its usefulness.
In my experience, if anything, AS path prepending is TOO effictive:
just one prepend can make a 60/40 split that you're trying to get to
50/50 into 25/75 instead. So I agree that it's not as useful as it
used to be, but I blamed this on the flattening of the AS
interconnection hierarchy. But maybe it's the routing/TE boxes that
Another capability that would be hard to replicate with shim6 is
Now, selective announcement is something completely different --
still a historical hack for lack of better mechanisms in BGP.
route isn't there at all, it won't be selected in today's world.
Right. That would be hard to accomplish with shim6.
But also consider this:
- C does not advertise the prefix for Y, but it does have the next
superprefix for Y (and C is "transit", so the superprefix must be
- X's link to A dies.
So X will still try to push packets over C to reach Y, and per the
of the superprefix on C, that route should[!] be valid.
This kind of thing is, as far as I can see, pretty much impossible to
replicate in shim6. Mind you, even if we end up with PI in IPv6, it's
unlikely that you get to do this with IPv6 because the address space
and the provider aggregates are so large, that deagregating becomes a
hazard rather than a nuisance. Deaggregating a /32 into /48 makes for
upto 65536 additional routes, which is a third of the current IPv4
routing table (and several dozen times the current IPv6 routing
table). So I think most people will use strict prefix length filters
to avoid this. At least, after it has happened for the first time.
Don't think this will forever be a rare circumstance, either. The
mangling technologies I mentioned above are now starting to offer the
ability for traffic to go out a "transit" neighbor so long as some
containing prefix is advertised (even if it's not the most specific).
Traffic engineering is happening on both ends of the BGP mesh
you should present any proposed solution in that context.
I'm not too worried about what happens on both ends: since both ends
implement the shim protocol and the two ends communicate with each
other, we can build in whatever is required. The challenges are:
- getting site wide policies into the individual hosts or apply side
wide policies in middleboxes in a secure way
- come up with a reasonable way to have information "in the middle"
taken into account
And we have to figure out which capabilities must be present as a
mandatory part of the specification on day one, and which can be
optional and/or added later. (Ideally, all TE is kept outside of the
base spec because modularity makes everything easier, but some stuff
is only useful if it's everywhere so it either has to be mandatory or
forget it, and other stuff is so important that we need it from day