> What about the other large isps? What would it take for you to do
> something? Chris is gracious enough to show up and participate, at
> least even if it does mean he has to wear nomex.
I'm in favor of source address filtering at the edges.
Here we agree, I believe the difference might be that you don't consider
the edge of your network to be the edge. If the edge only encompasses
where "Joe Bob" connects, then we have no belt and suspenders for when
things go wrong. It also allows the largest isps to continue doing
nothing or very little.
I'm opposed to some of the suggestions where to put source address
filters, especially placing them in "non-edge" locations. E.g. requiring
address filters at US border crossings is a *bad* idea, worthy of an
official visit from the bad idea fairy.
What is bad about filtering facing non-customers, if loose rpf is
used? I'm assuming this is what you mean by "border crossings" rather than
Our networks, and our customer bases, are not identical. This is good
and bad. Not to make excuses, the ease with which this can technically be
done depends on your network and type of customer connections. Or more
precisely how you aggregate customer connections.
Is there anywhere you can apply rpf today, while working towards the rest
for tomorrow? I can't speak for everyone, but I like it when people
do what they can.
I don't personally have RPF deployed "everywhere" in the network I run,
but I am deploying it, piece by piece.
"Progress, not perfection" as the saying goes.
IMHO the edge is generally the best place to do source address filtering.
After traffic is aggregated its more difficult. Some folks have already
identified the technical limitations of some types equipment. And with
the market, we're going to be stuck with that equipment for a while. In
hindsight, if every provider and every equipment vendor did it from day 1,
we would be in great shape.
The only equipment I'm heard here which has serious issues related to
feature availability is the 12000 (which was never a particularly good
aggregation device to begin with). RPF works fine on 7200, 7500, and
6500, from my experience. I've not used 12000's for customer aggregation
since they historically haven't been designed for or adequate in that
As such, I can understand providers not being able to apply RPF immediately
on 12000's, at least unless they are acquiring E3 cards for new installs.
Does that mean I can wave my magic wand and fix everything tomorrow? No.
Can I work on standards, vendors and purchasing agents to change this over
time? Yes. Will yelling at me make it happen faster? I doubt it, but I
know you will anyway.
All I asked for in my last message was whether folks were making progress,
and if they weren't to point out the trouble areas so we could all pool
our collective resources to address the stoppage.
This doesn't mean full deployment must occur by tomorrow (I'ld fail), but
that it be something each network is working towards.
However, we never hear "we're working on deploying rpf, but having snags"
but hear instead "rpf won't work for us". The latter always feels
more philosophical than technical, even if there are real technical issues
at play. If there are technical issues, I want to help in getting them
addressed (short of buying folks gear appropriate for customer aggregation,
sorry I don't have money to donate).
So, in this vein, is there gear other than old 12000 linecards that
can't do RPF? Is anyone still using 2500's or 4500's?
What non-hardware reasons are there not to do some flavor of rpf? Is
there a situation where even loose rpf will not work?