PA Assignment questions
Address Policy Working Group, I'm working for a company who decided to become a LIR as we have a requirement for Large amounts of IP Space. We are not assigning IP Space to our customers as all the IP Space is used for our own infrastructure. We have been provided with a PA Allocation, however we are having issues getting PA Assignments approved by RIPE NCC. We applied for PA Assignments in /24 blocks so that we could multi-home using BGP from all of our production sites and some of our more critical offices These sites don't have a shared Network connecting them (except for the Internet) We are using the "allowas-in" command so that we don't need an AS Number from each non-connected site. (As the RIPE NCC wouldn't approve our application for multiple AS Numbers) The request of PA Assignments is getting rejected because 1. We can't aggregate the IP Space (RIPE NCC wants us to advertise our entire PA Space and not break it into smaller networks as we require) 2. The IP Space required in some of the sites is less than a /24 (However we need /24 networks as our Transit providers filter IP Space smaller than /24) The suggestion from RIPE NCC was to apply for smaller Assignments from the PA Space and to take each of them from a separate /24 range, and to create a /24 route object for each separate /24 Space, or to apply for PI Space for each location as PI Space was more in-line with what we are trying to achieve. While this will work, I have an issue with RIPE NCC providing a work around, and I believe the policy should allow for a LIR to use the PA Allocation in the best manner to conserve IP Space and to not have "Available" networks in PA Space which can never be assigned and to not waste PI space by not allowing a LIR use the Allocated PA Space for its own Infrastructure. Thanks Keith Keith Nolan Director of Network and IT Operations, EMEA Premiere Global Services Tel: +353 (0) 23 88 32103 Mob: +353 (0) 86 919 8149 Fax: +353 (0) 23 88 36101
Hi, Nolan, Keith schrieb: [...]
The suggestion from RIPE NCC was to apply for smaller Assignments from the PA Space and to take each of them from a separate /24 range, and to create a /24 route object for each separate /24 Space, or to apply for PI Space for each location as PI Space was more in-line with what we are trying to achieve.
While this will work, I have an issue with RIPE NCC providing a work around, and I believe the policy should allow for a LIR to use the PA Allocation in the best manner to conserve IP Space and to not have “Available” networks in PA Space which can never be assigned and to not waste PI space by not allowing a LIR use the Allocated PA Space for its own Infrastructure.
sorry, i don't really understand where the problem with RIPEs suggestions is? Does it matter if /25 of a /24 is assigned or the whole /24 for conservation purposes?! If you don't need the full /24, it's wasted in any way? Or did i get you wrong? And please, sorry, PA == Provider AGGREGATED. If you don't aggregate, you will run into problems like LIR Allocation Size filters in some places anyways. You just set this up the wrong way. Seems like you designed something without understanding all the implications? Also, PI or PA is only a policy thing, what's the waste in using PI over PA? Nothing, a PI /24 is a /24 like a PA /24 is ... Again, sorry, i don't understand your problem. RIPEs suggestion is perfectly valid. Using PI instead of PA will even safe you the hassle with connectivity issues you will get announcing /24s out of a PA block with minimun allocation size like /21 - you will get filtered by some networks. Get your design right might be the best solution (no offencement!). What you want to do is actually the workaround, not RIPEs solution. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
On 16 Jul 2009, at 12:01, Sascha Lenz wrote:
And please, sorry, PA == Provider AGGREGATED.
just a minor point, it is Provider AGGREGATABLE, not AGGREGATED. It describes a possibility not a fact. If I understand the original mail correctly, the requester was trying to do the right thing, that is, after following the "become an LIR" mantra and gettting the address space as requested, the LIR is now being told they can't assign the addresses they got and must instead get more address space in order to split it (?!?!?!). If this is so (I am not sure it is, it is just how I read the mail) it seems to be counterintuitive to say the least, counterproductive towards conservation if correctly interpreted. Joao
I don't have an issue with the answer RIPE NCC provided to me, as it allows me to achieve my required Network design and was following RIPE Policy. On the RIPE.net page there is a statement about why you may want to become a LIR "If your organisation needs a large amount of IPv4, IPv6 and AS Numbers, routable blocks of address space and/or makes assignments to End Users or customers" This statement describes my company, therefore we became a LIR. When you become a LIR a PA Allocation is provided automatically. The issue I have is as a LIR I have a PA Allocation, the Allocation has enough IP Space to allow me implement my design, however I'm being suggested to use PI Space instead of the PA Space due to the type of design I'm using, and this will cause some of my PA Space to be wasted and is counter to the policy of IP Space conservation. The workaround which RIPE NCC provided (create /25 or /26 inetnum's but have them all in separate /24 networks and create a /24 route object) will work within the assignments they have already approved, so I can move forward. However I think this workaround shouldn't be required and since I need /24 networks for routing, I should be allowed to create inetnum's for the /24 networks. And as this is a policy wg, I believed it was a good place to ask this type of question. Thanks Keith
The other issue with suggesting that we use PI Space instead of PA Space where we will not be in a position to aggregate is the PI Assignment which would be approved would be less than a /24 (as we don't need 128 addresses for Multi-homed BGP Peering), therefore wouldn't be routable on the Internet (Policy proposal 2006-05 refers to this issue and suggests the smallest PI Space should be /24) So the only way to implement Multi-Home BGP Routing from Multiple locations which don't need a full /24 network is to become a LIR and create smaller /25 or /26 inetnum's with larger /24 route objects from your PA Space. And since this is a workaround, just like a company stretching the truth about their IP requirements when applying for a PI Space to get a full /24, surely a LIR should be allowed to create inetnum's for a /24 when they also need to create a /24 route object. Keith -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Nolan, Keith Sent: 16 July 2009 11:41 To: João Damas; Sascha Lenz Cc: address-policy-wg@ripe.net Subject: RE: [address-policy-wg] PA Assignment questions I don't have an issue with the answer RIPE NCC provided to me, as it allows me to achieve my required Network design and was following RIPE Policy. On the RIPE.net page there is a statement about why you may want to become a LIR "If your organisation needs a large amount of IPv4, IPv6 and AS Numbers, routable blocks of address space and/or makes assignments to End Users or customers" This statement describes my company, therefore we became a LIR. When you become a LIR a PA Allocation is provided automatically. The issue I have is as a LIR I have a PA Allocation, the Allocation has enough IP Space to allow me implement my design, however I'm being suggested to use PI Space instead of the PA Space due to the type of design I'm using, and this will cause some of my PA Space to be wasted and is counter to the policy of IP Space conservation. The workaround which RIPE NCC provided (create /25 or /26 inetnum's but have them all in separate /24 networks and create a /24 route object) will work within the assignments they have already approved, so I can move forward. However I think this workaround shouldn't be required and since I need /24 networks for routing, I should be allowed to create inetnum's for the /24 networks. And as this is a policy wg, I believed it was a good place to ask this type of question. Thanks Keith
Nolan, Keith schrieb:
The other issue with suggesting that we use PI Space instead of PA Space where we will not be in a position to aggregate is the PI Assignment which would be approved would be less than a /24 (as we don't need 128 addresses for Multi-homed BGP Peering), therefore wouldn't be routable on the Internet (Policy proposal 2006-05 refers to this issue and suggests the smallest PI Space should be /24)
So the only way to implement Multi-Home BGP Routing from Multiple locations which don't need a full /24 network is to become a LIR and create smaller /25 or /26 inetnum's with larger /24 route objects from your PA Space. And since this is a workaround, just like a company stretching the truth about their IP requirements when applying for a PI Space to get a full /24, surely a LIR should be allowed to create inetnum's for a /24 when they also need to create a /24 route object. [...]
please have a look at http://www.ripe.net/ripe/policies/proposals/2006-05.html and the discussions on the ap-wg list (i think) about it in the mailinglist archive if you don't read the list on a regular basis. It's partially about your problem here. It is indeed considered a problem by some other people, too. Although the current thinking by most involved in the policy process seems to be that it's weired that you need PI space and your own routing policy for two or three boxes (or so) in the first place. In any ways, it's probably still a design problem. Why did you design a network with multiple locations and no connection between them as a normal network architect would do? It's probably none of our business here how you design your network, but that is considered a fail anyways :-) If you really have independent locations, you need independent ressources, multiple LIRs probably or multiple PI Assignments. It's a really bad habbit to slit up PA Allocations and might not work out for you in all cases, you need workarounds like Tunnels between the locations and a site announcing the aggregate so you don't run into the PA Filters ... and so on ... But again, i don't really see the problem, i'm afraid. Probably some other people on the list can. P.S.: Don't think too much about address conservation. It's overrated, we have IPv6 now :-) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
participants (3)
-
João Damas -
Nolan, Keith -
Sascha Lenz