nanog mailing list archives

Re: BGP Question - how do work around pigheaded ISPs


From: Stephen Griffin <stephen.griffin () rcn com>
Date: Mon, 12 Feb 2001 19:06:02 -0500 (EST)


In the referenced message, Stephen Sprunk said:
Thus spake "Stephen Griffin" <stephen.griffin () rcn com>
These companies, conversely, don't care about the costs that _every
other BGP speaker in the default-free zone_ has to incur as a direct
result of their actions. Who is expected to bear the cost, the one or
the many?

There is a cost associated with each AS connecting to the Net; if you
want your customers to have access to every AS, you will accept all
_reasonable_ advertisements.  One prefix per AS is certainly more
reasonable than common practice -- just look at The Cidr Report.

Again, what is reasonable? What makes a /32 less reasonable than a /24?
Upon what basis do you define what is reasonable. I've shown my basis:
when an entity announces the prefix they have been assigned, and filters
are constructed based on registry allocation boundaries, there is no loss
of visibility. It is only when an entity does not announce their allocated
block, that there is a loss of visibility.

That ISP is less likely to have any successful litigation against it
through sticking to their policy. Converse to your argument, ISP
helpdesks could point their customers to call the company's helpdesk
for failure to properly announce their address space.

Define "properly."

Announced as the allocated block.

The companies in question are different legal entities, operating in
different countries, with no common ISPs, and no direction connection to
each other.  By definition, they are two different AS's with two
different prefixes and two different routing policies.  There is no
valid way for these two companies to collectively announce a single
route.

This is contrary to my interpetation of Dani's statement. The companies
were sub-divisions of a single entity. They are only different because
the single entity has chosen to make them different. There have been
several means by which people have suggested. I, myself, suggested
the use of GRE (or some other basis for a tunnel) to logically connect
the networks together.

If the two entities are entirely unconnected, then showing legal proof
of same should be sufficient for receiving an allocation from ARIN
(pending adherence to their allocation guidelines).

As the routing table size continues to increase, the number of
entities
who filter will increase, especially those who could better spend the
upgrade costs on direct revenue generation.

History has shown the reverse to be true.

Who that filters is no longer doing so now? Who in here would rather
spend money on a new router to hold the routing table rather than a
new router to increase customer capacity? If everyone had a limitless
supply of capital, and router vendors could scale their implementations
infinitely, I, personally, wouldn't care if everyone deaggregated down
to the /32 level.

While it may never happen in my lifetime, full-scale IPv6 deployment
will undoubtedly make filtering an absolute requirement.

Anyone who doesn't already filter extensively is an AS7007 waiting to
happen.

Ok, so you obviously agree with the premise of filtering, so what is
"reasonable" in your eyes? More importantly, on what basis have you
made the determination?

Now we've moved from the hypothetical to the nasty. I think the
community is better served with an open and frank discussion on
prefix filters, what is reasonable, and technical solutions to the
issues
or non-issues cited.

Citing "technical reasons" for excessive filtering but allowing
exceptions for your own customers is clearly hypocritical.  It's either
a technical problem or it's not.  Consistency is the issue, not the
theoretical limits of the routing system.

Perhaps it is the issue for you. Consistency is also the issue for me,
as well, but what I seek is consistency as to what announcement size is
considered reasonable. If we all agreed on that, and filtered on it, then
it doesn't matter who is hypocritical... which is the beauty of it
all.

S



Current thread: