Re: New AS request in another country

I just realized I left part of the original message unaddressed.
Can LIR xx.foo request a new allocation and a new ASN for use by the new daughter?
For IP allocations, you must have a second LIR. One LIR can only have one open IPv4 allocation at one given time. Joao

Can LIR xx.foo request a new allocation and a new ASN for use by the new daughter?
For IP allocations, you must have a second LIR. One LIR can only have one open IPv4 allocation at one given time.
So, if the new company does not yet have any address space, it can request its ASN via an existing LIR... but if the new AS wants to announce anything, it will either - have to start up its own LIR (which includes getting a /20 allocation), or - have to request a /20 or larger assignment from an existing LIR, in order to get an 'announcable' prefix, right (i.e. one that will not be filtered out anywhere)? kind regards, Herbert -- Herbert Baerten HB5351 HostIT Network Manager NCC9166-RIPE

On Wed, Aug 16, 2000 at 09:37:39AM +0200, Herbert Baerten wrote: Hi !
- have to request a /20 or larger assignment from an existing LIR, in order to get an 'announcable' prefix, right (i.e. one that will not be filtered out anywhere)?
Some older LIR“s out there have PA assignments in PI space (194,193,192). They can assign that customer also smaller prefixes. regards Robert Depenbrock -- Sen. Network Engineer - "Jeder Tag ist ein LinuxTag" mediascape communications AG Weidestrasse 122a - 22083 Hamburg - Germany email : rd@mediascape.de (RD-RIPE)

On Wed, 16 Aug 2000, Herbert Baerten wrote:
- have to start up its own LIR (which includes getting a /20 allocation),
And some additional money, of course ...
- have to request a /20 or larger assignment from an existing LIR, in order to get an 'announcable' prefix, right (i.e. one that will not be filtered out anywhere)?
Well, not the "assignment", becuase the assignment can't have subassignments. A rather better approach is to try to plan address space assignment within the current allocation smarter. Say, if xx.foo was allocated 172.16/16 in the past and it wants to start its business in the country YY, then they may "reserve" a small /20 within that allocation (say 172.16.240/20) and start assigning addresses to YY customers from that /20, while using the rest of the /16 for XX customers. From AS Y they will announce 172.16.240/20 and everything will be fine. Of course, everything would be much more elegant if RIPE NCC finally implemented the additional SUB-ALLOCATED PA/PI status attribute, that was proposed by James Aldridge long ago, adopted by the LIR working group and passed to the DB WG for implementation. With such a scheme the LIR xx.foo would simply make a sub-allocation of 172.16.240/20, register it normally in the RIPE Database, give it SUB-ALLOCATED PA status, so the whole picture would look more proper and clean. Regards, Beri -- ----- ___ Berislav Todorovic, Network Engineer ---- / / /____ ____ _/_ -- KPNQwest N.V. - IP NOC (formerly EUnet) --- /--- / // //___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___// //___ /_ ---- Phone: (+3120) 530-5457; Fax: (+3120) 622-4657 - --- Email: beri@EU.net; Mobile: (+31651) 333-641

A rather better approach is to try to plan address space assignment within the current allocation smarter. Say, if xx.foo was allocated 172.16/16 in the past and it wants to start its business in the country YY, then they may
I see your point in general, however in our particular case xx.foo only has 1 allocation, a /19. In theory it could split that and announce one /20 from one AS and the other /20 from its new AS. But then the LIR gets in trouble when one of the /20s fills up much faster than the other... it won't get a new allocation to use for the filled-up AS since its original /19 allocation is not yet full? So even in general, it seems risky to me to have a LIR splitting its open allocation between different ASs? Herbert

I see your point in general, however in our particular case xx.foo only has 1 allocation, a /19. In theory it could split that and announce one /20 from one AS and the other /20 from its new AS. But then the LIR gets in trouble when one of the /20s fills up much faster than the other... it won't get a new allocation to use for the filled-up AS since its original /19 allocation is not yet full?
This is exactly why we have a registery in each country.
So even in general, it seems risky to me to have a LIR splitting its open allocation between different ASs?
I'd say so. Regards, Neil.

Hello, At 9:49 +0200 16/8/00, Berislav Todorovic wrote:
On Wed, 16 Aug 2000, Herbert Baerten wrote:
Of course, everything would be much more elegant if RIPE NCC finally implemented the additional SUB-ALLOCATED PA/PI status attribute, that was proposed by James Aldridge long ago, adopted by the LIR working group and passed to the DB WG for implementation. With such a scheme the LIR xx.foo would simply make a sub-allocation of 172.16.240/20, register it normally in the RIPE Database, give it SUB-ALLOCATED PA status, so the whole picture would look more proper and clean.
I've been trying to find the consensus your paragraph above describes by looking in the list archives and the minutes of the two working groups and I have failed so far. I've seen a proposal from James Aldridge from January this year, but failed to see responses to it or to see any mention of it in the db-wg or any word of its adoption. If we have missed the conclusion of this discussion, please point me to where I can find this. regards, Joao Damas RIPE NCC
Regards, Beri
-- ----- ___ Berislav Todorovic, Network Engineer ---- / / /____ ____ _/_ -- KPNQwest N.V. - IP NOC (formerly EUnet) --- /--- / // //___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___// //___ /_ ---- Phone: (+3120) 530-5457; Fax: (+3120) 622-4657 - --- Email: beri@EU.net; Mobile: (+31651) 333-641

On Wed, 16 Aug 2000, Joao Luis Silva Damas wrote:
implemented the additional SUB-ALLOCATED PA/PI status attribute,
I've been trying to find the consensus your paragraph above describes by looking in the list archives and the minutes of the two working groups and I have failed so far. I've seen a proposal from James Aldridge from January this year, but failed to see responses to it or to see any mention of it in the db-wg or any word of its adoption.
James, can you, please, give more light on this issue? Regards, Beri -- ----- ___ Berislav Todorovic, Network Engineer ---- / / /____ ____ _/_ -- KPNQwest N.V. - IP NOC (formerly EUnet) --- /--- / // //___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___// //___ /_ ---- Phone: (+3120) 530-5457; Fax: (+3120) 622-4657 - --- Email: beri@EU.net; Mobile: (+31651) 333-641
participants (5)
-
Berislav Todorovic
-
Herbert Baerten
-
Joao Luis Silva Damas
-
Neil J. McRae
-
Robert Depenbrock