Sprint's route filters and Europe

Michael, I guess I missed this when it was originally posted, but if you
could put some attribution around it, it would be more helpful.

Sorry, I should have clarified. It's something I haulled off of an ISP
discussion list and it appears that some of RIPE's activities may be
butting heads with Sprint's route filtering policies. Specifically, RIPE
is charging a fee to ISP's to get large blocks of IP addresses to allocate
to their customers and yet these blocks are smaller than what Sprint will
route.

I intentionally left out the attribution in case the individual concerned
was simply wrong due to not having done enough research.

I was kind of hoping that someone would pipe up and say that the
operations folks and the IP registres are now working closer and
coordinating their activities. Am I dreaming?....

Michael Dillon ISP & Internet Consulting
Memra Software Inc. Fax: +1-604-546-3049
http://www.memra.com E-mail: michael@memra.com

Michael Dillon <michael@memra.com> writes:

  >
  > ... appears that some of RIPE's activities may be
  > butting heads with Sprint's route filtering policies.

As I have said in this forum before the address allocation policies RIPE
uses are in line with IANA's policies, RFC1466 and the current draft of
RFC1466's successor. The policies are published and regularly discussed
with ISPs in the appropriate fora such as RIPE meetings, NANOG, IETF etc.

The current policy is that the size of the *first* allocation to any new
local registry (ISP) is /19. Of course we will *place* such allocation
such that the possibility for future aggregation is maximised.

These policies are not subject to change based on routing policies set
by a single ISP or a small number of ISPs. Otherwise a single ISP would
in fact be setting the policies. Of course rough consenus among ISPs is
an entirely different matter; however this is not apparent on the
prefix length filtering issue.

  > Specifically, RIPE
  > is charging a fee to ISP's to get large blocks of IP addresses to allocate
  > to their customers

We charge *everyone* for registration services. That is how it should
be. There is no reason why governments (read: taxpayers) should be
footing the bill.

  > and yet these blocks are smaller than what Sprint will
  > route.

*used to be* smaller. At NANOG Sprint announced that their filters will
be /19. This should be implemented "in the next couple of weeks". Also
most of the RIPE NCC's allocations are out of 193/8 and 194/8 which were
never filtered by Sprint.

  > I was kind of hoping that someone would pipe up and say that the
  > operations folks and the IP registres are now working closer and
  > coordinating their activities. Am I dreaming?....

We are working quite closely together indeed.
But sometimes there is no rough consensus.

Daniel
RIPE NCC Manager

  > Specifically, RIPE
  > is charging a fee to ISP's to get large blocks of IP addresses to allocate
  > to their customers

We charge *everyone* for registration services. That is how it should
be. There is no reason why governments (read: taxpayers) should be
footing the bill.

No quarrel with that, but the folks who pay those high fees kind of
expected that they were guaranteed to work on the global Internet. As you
pointed out, there really *IS* some co-operation between registries and
NSP's and the filtering isue really *IS* becoming more sane, i.e.
co-ordinated with registry activities. This is good news.

We are working quite closely together indeed.
But sometimes there is no rough consensus.

As long as the lines of communication are kept open rough consensus
usually finds a way to form itself even if not in the way people might
have first imagined it would form.

I started this thread because a European ISP could not find out from
either Sprint or his own upstream NSP or RIPE, why were these routes being
blocked and what could he do to unblock them. This points out to me that
there may still be some room for improvement in opening up avanues of
communication.

Thank you.

Michael Dillon ISP & Internet Consulting
Memra Software Inc. Fax: +1-604-546-3049
http://www.memra.com E-mail: michael@memra.com

Michael Dillon <michael@memra.com> writes:

  >
  > No quarrel with that, but the folks who pay those high fees kind of
  > expected that they were guaranteed to work on the global Internet.

Our documentation clearly tells them that this may be a wrong expectation
and also tells them where to complain. Now if people would read
documentation the world would be a better place .... ;-(

  > I started this thread because a European ISP could not find out from
  > either Sprint or his own upstream NSP or RIPE, why were these routes being
  > blocked and what could he do to unblock them.

I am quite sure we point everyone with routing problems in the direction
of the ISP concerned. I realise that some find this not too helpful,
but what else can we do?

  > This points out to me that
  > there may still be some room for improvement in opening up avanues of
  > communication.

Concrete suggestions are always welcome.

Daniel