Re: Policy Statement on Address Space Allocations
At 6:09 1/29/96, Alex.Bligh wrote:
Currently I have 2 choices as far as I can make out, give them a bit of my /19, break up my nice aggregate and ensure loads of extra announcements (and that probably none of them get routed by anyone applying prefix based filtering), or give them a new /19 all of their own (you've said it, that's the minimum size allocation) which actually solves their problem and mine, but this isn't an option currently available because currently it's one window per local-IR. So they have to go and become a local IR.
If the high /21 of your /19 is not Allocated, you just assign it to them and add ONE announcement of the /21 to supersede with the current /19. If it is not free but is sparsely populated you can move the stuff out to free it up or go to RIPE to get your /19 turned into an /18 (ie: get the /19 right after your current /19 [RIPE did give you the first /19 in a shorter prefix block didn't they?]) in exchange for returning the /21 worth of space [giving you 3 extra /21s worth of space], and divide that 2nd /19 into a /20, and 2 /21s giving them the 2nd /21 (still doing the same 2 announcements as you would if allocated out of your current /19).
At 6:09 1/29/96, Alex.Bligh wrote:
Currently I have 2 choices as far as I can make out, give them a bit of my /19, break up my nice aggregate and ensure loads of extra announcements (and that probably none of them get routed by anyone applying prefix based filtering), or give them a new /19 all of their own (you've
Suppose you have a customer that needs a /22 and they want to go multi-homed. Suppose you give them that /22 out of your /19 or /16 you got from the RIPE NCC. So they announce their /22 to you and to their other provider. But you keep announcing your /19 or /16. So if anybody were to filter the /22 announcement, your customer only suffers partial loss of connectivity, since you are still announcing an aggregate of their announcemnt (your original /19 or /16). Problem fixed. Anything else? ;-)
Currently I have 2 choices as far as I can make out, give them a bit of my /19, break up my nice aggregate and ensure loads of extra announcements (and that probably none of them get routed by anyone applying prefix based filtering), or give them a new /19 all of their own (you've
Suppose you have a customer that needs a /22 and they want to go multi-homed. Suppose you give them that /22 out of your /19 or /16 you got from the RIPE NCC. So they announce their /22 to you and to their other provider. But you keep announcing your /19 or /16. So if anybody were to filter the /22 announcement, your customer only suffers partial loss of connectivity, since you are still announcing an aggregate of their announcemnt (your original /19 or /16).
Problem fixed. Anything else? ;-)
Yes, if you go down, or their line goes down to you, their multi-homing is worthless. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)623-9663 Network Engineer -- Regional/National NSPs (Cisco) dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/~dsiegel/ for an ISP."
"Robert A. Rosenberg" <hal9001@panix.com> wrote:
At 6:09 1/29/96, Alex.Bligh wrote:
Currently I have 2 choices as far as I can make out, give them a bit of my /19, break up my nice aggregate and ensure loads of extra announcements (and that probably none of them get routed by anyone applying prefix based filtering), or give them a new /19 all of their own (you've said it, that's the minimum size allocation) which actually solves their problem and mine, but this isn't an option currently available because currently it's one window per local-IR. So they have to go and become a local IR.
If the high /21 of your /19 is not Allocated, you just assign it to them and add ONE announcement of the /21 to supersede with the current /19. If it is not free but is sparsely populated you can move the stuff out to free it up or go to RIPE to get your /19 turned into an /18 (ie: get the /19 right after your current /19 [RIPE did give you the first /19 in a shorter prefix block didn't they?]) in exchange for returning the /21 worth of space [giving you 3 extra /21s worth of space], and divide that 2nd /19 into a /20, and 2 /21s giving them the 2nd /21 (still doing the same 2 announcements as you would if allocated out of your current /19).
Thankyou for the first constructive workable suggestion had so far. However, this has two problems. a) RIPE fidn't give me the first /19 in a shorted prefix block ( its x.x.160.x and .192.x is used), but no matter, I'll renumber if necessary :-( or persuade them to give me a /18 as well so I can do the above (hopefully). b) The /21 advert may be inbound filtered by a.n.other, which will be fine if it has an AS-Path through me (as the less specific route will work the same way) but won't when that path goes through the other provider with whom they are multi-homed, as the /21 will disappear entirely (3rd parties, i.e. a.n.other's customers will see neither), the /19 will be the only thing that is visible, and I'll just black hole their packets. Anyway this is several times better than the swamp. Oh well. Alex Bligh Xara Networks
People on this list of lists seem to be focussing on squeezing more aggregation out of assignment and routing policy's. But that won't work. The Internet isn't organized in a geographical way nor in a very hierarchical way. There are less than 2000 Autonomous Systems, but more than 30000 routes. That means an average of 15 routes per AS. That's the real problem. And we know how to fix it too: renumber. But whatever happens, the routingtable will continue to grow. Get used to it. At present I can still run full routing with only a Cisco 2514 so the problem is hardly as big as some people (Sprint...) like to tell themselves and the rest of us. We pay those backbone people big money, so either they do their job and quit complaining about their overloaded CPU's, tight memory and other stuff or they find themselves another line of work. I'm getting sick and tired of reading how everybody will bend over backwards to find a way to live with an utterly ridiculous policy of some dinosaur company with a flawed network because they pay their lawyers more than their engineers. Maybe they could get away with that in the good old phonebusiness, but not on the Internet. Iljitsch
participants (5)
-
Alex.Bligh -
Dave Siegel -
Iljitsch van Beijnum -
iljitsch＠daisy.bART.nl -
Robert A. Rosenberg