Re: 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. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.
On Sun, 2 Jun 1996, Stan Barber wrote:
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 wrote:
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.
Specifically RIPE are allocating /19s as their default allocation window to local-IRs. They don't charge per block but they charge a yearly fee for being a local-IR. Sprint in its wisdom is filtering those in 195/8 (great theory, but a bit problematic in practice when it can't agree with one of the larger registries on what size to filter) with the result there are now likely to be 50% more adverts (i.e. 2x/19 and an additional /18 - /19 still necessary to get ANS to work as you can't put a /18 route object in the database).
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?....
AFAIK Yes. But it would be great if not (I wasn't at NANOG so missed the announcement). Alex Bligh Xara Networks
"Alex.Bligh" <amb@xara.net> writes:
Specifically RIPE are allocating /19s as their default allocation window to local-IRs. They don't charge per block but they charge a yearly fee for being a local-IR.
Nice to read something correct for a change. Thanks! ;-(
Sprint in its wisdom is filtering those in 195/8 (great theory, but a bit problematic in practice when it can't agree with one of the larger registries on what size to filter)
I happen to agree and Sprint happens to have changed their policy to one that happens to be compatible with the NCC's allocation policy in the meantime.
with the result there are now likely to be 50% more adverts (i.e. 2x/19 and an additional /18 - /19 still necessary to get ANS to work as you can't put a /18 route object in the database).
Yes you can! If you have a /18 allocation you should announce it as such and put a /18 route object in the database. Can you be more specific on why it did not work for you? Daniel
Daniel Karrenberg <Daniel.Karrenberg@ripe.net> wrote:
with the result there are now likely to be 50% more adverts (i.e. 2x/19 and an additional /18 - /19 still necessary to get ANS to work as you can't put a /18 route object in the database).
Yes you can! If you have a /18 allocation you should announce it as such and put a /18 route object in the database. Can you be more specific on why it did not work for you?
Sorry I wasn't clear. If you have a /19 allocated in the RIPE database then for obvious reasons you have to put a /19 route (not a /18) route in the RIPE database. To get ANS to accept this you have to announce a /19 route for this. This got filtered by Sprint. Before Sprint's (much welcomed - thanks Sean) change of heart, you could get around this if you were the lower /19 in the block by also making a /18 advert. As the other half of the /18 was unused normally, this makes no difference to anyone except those in the /19 suddenly get Sprint connectivity. Actually it was likely to be of benefit to any future holder of the upper half of the /18 as that would have been the only way they would have gained Sprint connectivity (effectively the holder of the lower half gives them partial transit to the point where the upper /19 advert hits the /18 route to Sprint). This possibly slightly naughty but oh-so-tempting hack would have meant that European local IRs were likely to announce a /18 and a lower /19, and an upper /19 rather than just two /19s. So Sprint would see one /18 and get suboptimal routing, everyone else would see 3 adverts rather than 2. Hope that makes sense. Anyway, all sorted out now Sprint have changed their policy. Glad the world has seen sense (i.e. RIPE and Sprint have agreed on the same size - whether it was /18 or /19 didn't matter to me, just as long as it was consistent). Alex Bligh Xara Networks
"Alex.Bligh" <amb@Xara.Net> writes: Sorry I wasn't clear. If you have a /19 allocated in the RIPE database then for obvious reasons you have to put a /19 route (not a /18) route in the RIPE database. To get ANS to accept this you have to announce a /19 route for this. This got filtered by Sprint.
OK so far.
Before Sprint's (much welcomed - thanks Sean) change of heart, you could get around this if you were the lower /19 in the block by also making a /18 advert. As the other half of the /18 was unused normally, this makes no difference to anyone except those in the /19 suddenly get Sprint connectivity.
Since this means announcing routes to address space not allocated to you it is dubiuous to say the least.
Actually it was likely to be of benefit to any future holder of the upper half of the /18 as that would have been the only way they would have gained Sprint connectivity (effectively the holder of the lower half gives them partial transit to the point where the upper /19 advert hits the /18 route to Sprint). This possibly slightly naughty but oh-so-tempting hack would have meant that European local IRs were likely to announce a /18 and a lower /19, and an upper /19 rather than just two /19s. So Sprint would see one /18 and get suboptimal routing, everyone else would see 3 adverts rather than 2.
Hope that makes sense.
Technically I understand what you are saying. Whether "it makes sense" is another matter.
Anyway, all sorted out now Sprint have changed their policy. Glad the world has seen sense (i.e. RIPE and Sprint have agreed on the same size - whether it was /18 or /19 didn't matter to me, just as long as it was consistent).
Yes indeed. Daniel
In message <199606030827.JAA06158@diamond.xara.net>, "Alex.Bligh" writes:
Michael Dillon wrote:
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.
Specifically RIPE are allocating /19s as their default allocation window to local-IRs. They don't charge per block but they charge a yearly fee for being a local-IR. Sprint in its wisdom is filtering those in 195/8 (great theory, but a bit problematic in practice when it can't agree with one of the larger registries on what size to filter) with the result there are now likely to be 50% more adverts (i.e. 2x/19 and an additional /18 - /19 still necessary to get ANS to work as you can't put a /18 route object in the database).
Since when can't you put a /18 in the database? It sounds like what you are saying is you will be advertising 2 /19s plus advertising a /18 that you won't be registering just to get the traffic to come out of Sprint. You can certainly register a /18 and the whole world would much rather you advertised just the /18 and and not the /19s. This sounds to me like some people don't know or care who the other /19 belongs to and are just announcing the /18 for Sprint's sake. The two /19s would be announced regardless of anything ANS does or regardless of any registry issues. Is this the case? Curtis
It sounds like what you are saying is you will be advertising 2 /19s plus advertising a /18 that you won't be registering just to get the traffic to come out of Sprint.
You can certainly register a /18 and the whole world would much rather you advertised just the /18 and and not the /19s.
This sounds to me like some people don't know or care who the other /19 belongs to and are just announcing the /18 for Sprint's sake. The two /19s would be announced regardless of anything ANS does or regardless of any registry issues. Is this the case?
See my later mail. Of course it would be irresponsible to do this without consent of the owner of the upper half of the /18, however most (all that I've seen) of the /19s RIPE are currently assigning from 195 have been lower /19s with the upper half not used, so they can grow. Please don't take what I wrote as a criticism of ANS - I've never had any problem with ANS filtering as it's entirely predictable and worked precisely in parallel with the registries, and the ANS NOC is admirably helpful in sorting out any filtering problems. I was describing a marginally unpleasant workaround to an otherwise intractable (sp?) problem (RIPE and Sprint not agreeing on minimum block size) - and AFAIK the only way to get /19s routed to Sprint when the other half isn't in use in many cases (yes, I know about proxy aggregation etc.). I'd be the first to say it isn't nice, but fortunately it's now (or will soon be) unnecessary. My point was the fact RIPE and Sprint *didn't* agree would actually encourage hacks like this and in some cases increase the number of routes carried. Alex Bligh Xara Networks
Michael Dillon <michael@memra.com> writes: On Sun, 2 Jun 1996, Stan Barber wrote:
... 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
On Mon, 3 Jun 1996, Daniel Karrenberg wrote:
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
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.
No quarrel with that either, except for the bit about high fees. RIPE NCC tariffs are quite moderate. With the help of market buoyancy, they've been able to reduce them significantly year on year. This year, most of the ISPs receiving service from the RIPE NCC pay a charge of 1500 ecu (about $1800). The scale of charges are agreed each September by the ISPs themselves as a committee of NCC contributors. Mike Norris
participants (6)
-
Alex.Bligh -
Curtis Villamizar -
Daniel Karrenberg -
Michael Dillon -
Mike Norris -
sob＠academ.com