BGP Question - how do work around pigheaded ISPs

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.

-----BEGIN PGP SIGNED MESSAGE-----

The question seems (in my opinion) to be whether registries are delegating
netblocks that can be further subdivided, or not.

That is, some ISPs hold that if a registry has allocated /16s in some
space, those allocations should not be subdivided by the allocatees. If a
registry is allocating /19s minimum in some other space, then the
allocatees cannot and should not split that space and advertise longer
prefixes.

In practice, how have corporate divestitures been handled by the
registries? Have organizations with portable netblocks been able to split
them up and get new allocations from the registries, following the
corporate reorganizations?

Surely someone on this list has worked through such an event. How did it go?

Never mind corporate changes, why should an allocatee not subdivide their space
among their operating units or sites?

To answer your specific question, all of the ones I have seen, the space has been
divided on ARIN allocation boundaries.

Roy Engehausen

Bill Nickless wrote:

The question seems (in my opinion) to be whether registries are delegating
netblocks that can be further subdivided, or not.

That is, some ISPs hold that if a registry has allocated /16s in some
space, those allocations should not be subdivided by the allocatees. If a
registry is allocating /19s minimum in some other space, then the
allocatees cannot and should not split that space and advertise longer
prefixes.

All of this talk has me wondering about our network. It's much smaller
than most of yours and according to the CIDR report, the only thing it
says we should aggregate is a single /24 out of the /19. It is being
announced for testing purposes and by the end of the week, the testing
will be over and it will no longer be announced.

My question however is along the lines of splitting the /19 up by swipping
it out to BGP speaking customers who are announcing /24's, /23's, /22's,
etc. The announcement needs to be made by them (from my understanding --
which may be wrong) for their multi-homing diversity to work.

If I add an aggregate statement to our config, is it going to aggregate
those /24's, etc that our BGP speaking clients are announcing to us into
our main /19 announcement?

This is something that I've been thinking about for a while and want to
sure we're doing the technically sound thing.

In practice, how have corporate divestitures been handled by the
registries? Have organizations with portable netblocks been able to split
them up and get new allocations from the registries, following the
corporate reorganizations?

It is my understanding (again, perhaps flawed) that legacy allocations
were settlement-free but, if an organization has say a legacy B, is only
using a /18 of it and wants to do the right thing and return the B in
exchange for an /18 in CIDR space, they now get to pay for the /18 just
because they wanted to do the right thing. I know if we had legacy space
we'd hang on to it for financial reasons if none other.

Someone correct me if I'm wrong on this.

> The question seems (in my opinion) to be whether registries are delegating
> netblocks that can be further subdivided, or not.
>
> That is, some ISPs hold that if a registry has allocated /16s in some
> space, those allocations should not be subdivided by the allocatees. If a
> registry is allocating /19s minimum in some other space, then the
> allocatees cannot and should not split that space and advertise longer
> prefixes.

All of this talk has me wondering about our network. It's much smaller
than most of yours and according to the CIDR report, the only thing it
says we should aggregate is a single /24 out of the /19. It is being
announced for testing purposes and by the end of the week, the testing
will be over and it will no longer be announced.

My question however is along the lines of splitting the /19 up by swipping
it out to BGP speaking customers who are announcing /24's, /23's, /22's,
etc. The announcement needs to be made by them (from my understanding --
which may be wrong) for their multi-homing diversity to work.

If I add an aggregate statement to our config, is it going to aggregate
those /24's, etc that our BGP speaking clients are announcing to us into
our main /19 announcement?

This is something that I've been thinking about for a while and want to
sure we're doing the technically sound thing.

There are two kinds of aggregates. Regular, normal aggregates, and summary
aggregates. Normal aggregates are announced in addition to any smaller
blocks that make up the aggregate. At least one smaller block inside the
aggregate is required to be present for the announcing router to announce
the aggregate (i.e. an activating route). Summary aggregates work in a
similar manner, but they surpress all advertisement of routes that are
included within the aggregate - they are subsumed. Both types of
aggregates should flag routes with the Atomic Aggregate attribute, to
indicate that there is the possibility of some routing information having
been lost. Be VERY careful with summary aggregates - if a customer is
sending prepends, you will lose that information at your border to your
peers and upstreams. Customers don't like that.

It is possibly to selective surpress subordinate routes belonging to an
aggregate on some router platforms.

> In practice, how have corporate divestitures been handled by the
> registries? Have organizations with portable netblocks been able to split
> them up and get new allocations from the registries, following the
> corporate reorganizations?

It is my understanding (again, perhaps flawed) that legacy allocations
were settlement-free but, if an organization has say a legacy B, is only
using a /18 of it and wants to do the right thing and return the B in
exchange for an /18 in CIDR space, they now get to pay for the /18 just
because they wanted to do the right thing. I know if we had legacy space
we'd hang on to it for financial reasons if none other.

If this were a just and sensible world, we would allow IP addresses to be
treated like property. Folks with big, wasted, /8s could sell them to
those who could or would use them. Because it would cost money to sit on
unused space, no one would. We would get much better
utilization. Considering the relativly large number of IPv4 addresses in
play, the price would be reasonable, especially once folks sold their
legacy space off.

Someone correct me if I'm wrong on this.

---
John Fraizer
EnterZone, Inc

Daniel Golding NetRail,Inc.
"Better to light a candle than to curse the darkness"