Yes, Geert Jan, but if you look at the list I prepared,
you'll note that the only chunks of old style Bs that are
18-bits long all come from one home-AS and most are in a
pair of old-style class Bs which easily could be aggregated
into a single /15 with the loss of some routing specificity
(which is lost anyway when that provider's internal metrics
don't propagate to its external peers).
The remainder of the 'chunks' of old style Bs are
all longer than 18 bits, and most are /24s or /26s,
and I see none at all that appear difficult to aggregate,
or which look like anything other than leaks due to
misconfiguration.
If you get to the point where someone needs to have a /18
in the old-style class B space and it can't be aggregated,
we can return to this.
Sean.
Hallo,
the Municipality of Zuerich has got assigned 1/2 class B in April this year
after a long discussion with RIPE NCC. They will soon get onto Internet.
I need to be sure that this address space is routed on the Internet.
Sean, Geert-Jan, could you comment, please.
Regards,
Willi Huber
inetnum: 131.117.0.0 - 131.117.127.255
netname: ZUERI-NET
descr: Municipality of Zuerich
descr: Zuerich. Switzerland
country: CH
admin-c: BM16-RIPE
tech-c: BM16-RIPE
changed: huber@switch.ch 950412
source: RIPE
person: Beat Morf
address: Organisation & Informatik der Stadt Zuerich
address: Wilhelmstrasse 10
address: CH-8022 Zuerich
phone: +41 1 279 92 62
phone: +41 1 279 91 11
fax-no: +41 1 279 93 85
e-mail: beat.morf@oiz.stzh.inet.ch
nic-hdl: BM16-RIPE
changed: huber@switch.ch 950601
source: RIPE
Willi Huber <huber@chx400.switch.ch> writes:
>
> the Municipality of Zuerich has got assigned 1/2 class B in April this year
>
> after a long discussion with RIPE NCC. They will soon get onto Internet.
> I need to be sure that this address space is routed on the Internet.
>
> Sean, Geert-Jan, could you comment, please.
Willi,
as far as the RIPE NCC is concerned we see this as follows:
1) All major transit providers are capable and willing to route fully
classless, so we can assign address space in a classless manner.
2) Some service providers apply route filtering based on prefix length
or other general criteria. This is a matter of the service providers
concerned and we have no control over it. The proper way to resolve
problems caused by this is to talk to the service provider concerned.
Of course we will be happy to help if we can.
3) We inform service providers about the RIPE NCC assignment policies in
the appropriate fora such as RIPE WGs, NANOG and IETF CIDRD WG. This
enables service providers to take assignment policies into account when
defining their routing policies.
4) We examine routing policies of service providers which are brought
to our attention and provide feedback to the providers if we detect
potential problems due to our assignment policies.
5) Service providers are invited to contribute to the definition of
RIPE NCC assignemnt policies via the RIPE Local IR WG.
In the particular case at hand we have informed Sprint (and everyone else)
about the fact that we assign prefixes longer than /16 in the B space
and Sprint have informed us that they currently see no problem routing
these unless they can be aggregated to /16s or shorter.
So your customer should not have a problem with Sprint.
If you have any further questions, please do not hesitate to contact us.
Regards
Daniel Karrenberg
RIPE NCC Manager
PS: Sorry about the delay caused by illness.