Gert Doering wrote:

Hi,

On Tue, May 11, 2004 at 09:15:43AM +1200, Jason Everard wrote:

...

Having lived in Europe for most of my life, EU is not a country, rather a collection of countries. I'm not sure if it is just standard practice to list the European country under "EU", but wouldn't it be better to have "ES" for Espania?

In this context, "EU" means "multinational network in the RIPE region".

It's not necessarily confined to actual EU countries, nor does it mean "all of the EU" - just "more than one country so you can't easily tack a single country code on it".

This definition isn't perfect, but does the job...

FYI: Because of the ambiguities in the meaning of the "country:" attribute when applied to a network, the Database Working Group recommended at the recent RIPE meeting to either get rid of "country:" completely, or at least to make it optional. -- Shane Kerr RIPE NCC

On Tue, 2004-05-11 at 10:57, Engin Gunduz wrote:

Hi,

On 2004-05-11 09:40:10 +0200, Gert Doering wrote:

...

Hi, <SNIP> It's not necessarily confined to actual EU countries, nor does it mean "all of the EU" - just "more than one country so you can't easily tack a single country code on it".

This definition isn't perfect, but does the job...

I'm not too sure about it. 'EU' is ambiguous here: does the data owner mean European Union? Or Europe as a continent? Or the RIPE service region? Or just 'many countries'? Unfortunately, we allow the code 'EU' without defining what it actually means in the RIPE Whois Database... In different inetnums/inet6nums it is used to mean different things.

<SNIP>

We will post the outcome of the discussion that took place in the session later to db-wg and address-policy mailing lists. As far as I can remember, although there wasn't a real consensus, the working group advised to either remove "country:" attribute from inet(6)nums or make it optional.

Removing the attribute would loose a lot of precious information especially when trying to do statistics and looking where there is real usage of certain netblocks. This is for instance also used by many services to 'localize' the data. Eg when you use www.google.com you will be redirected to google.nl when in .nl or google.ch when in .ch. Same for eg php.net and quite some others. Or even simpler, just showing the correct language based on the origin IP (okay people could use the language-accept in HTTP for this ;) Another example of use is IRC servers which generate I-lines based on country of origin. Next to that some people just like to know where connections are coming from and using whois is a great tool to at least know the source country (of course someone could ssh to a box in another country etc... blabla) Making it optional thus is a possibility, another option would be to define the 'eu' wording or better add 'global' as a value. Anyhow, removing it is a no-go IMHO. Greets, Jeroen

Hans Petter Holen wrote:

This is really bad - my knowledge of Dutch is not getting any better when my coputer has an IP address tagged to be in the NL - or even worse, my understanding of French is still nil - even with a "French" IP address.

My browser however knows what languages I prefer - so it would be nice is theese providers could listen to my browser rather than second guessing my language preferences.

I fully agree. I belived "ISO Country Code" was there to identify where the LIR provide services. Not where the users of the addresses are. I have seen cases where we have used address space from one LIR to a customer who is in another country where we dont have a LIR - and that customers have come back and complained that search engines by default sets up wrong language - even if they have choosen a URL with their own cc-TLD. -- amar

Engin Gunduz wrote:

I'm not too sure about it. 'EU' is ambiguous here: does the data owner mean European Union? Or Europe as a continent? Or the RIPE service region? Or just 'many countries'?

From a geographic standpoint its is based in sweden but it

Maybe I should clearify this. This goes back to the time when we created a LIR that would span over all european countries - eu.telianet. This LIR was created to provide addresses for our global backbone and not for a specific country. Hence the name EU. provides services for all our operations within europe - and outside as well. When we started to do the IPv6 request for TeliaSonera we had two options: 1) To request thru each LIR we have today wich would result in a number of "small" blocks. or 2) Do a single request for the whole global TeliaSonera wich would result in one large address block. We went for 2) and the natural choice was to use a LIR that was already covering most countries. So the choice became our "EU LIR". Regards -- amar TeliaSonera /Telia Net

Gert Doering wrote: Hi,

I appreciate that approach. It has the potential to keep down the number of routes - but even if that doesn't work out, due to different per-country routing policies, it definitely served to wake up those people that still think "a /23 allocation per RIR is plenty".

I fully agree. There is a lot that needs to be done. I hope I will have more time in the future to get engaged in WG regarding the issues that we have seen during the process of the request. Not to mention all other issues ;-) -- amar TeliaSonera /Telia Net

Hi, On Tue, May 11, 2004 at 11:37:34AM +0200, Iljitsch van Beijnum wrote:

...

I appreciate that approach. It has the potential to keep down the number of routes - but even if that doesn't work out, due to different per-country routing policies, it definitely served to wake up those people that still think "a /23 allocation per RIR is plenty".

Still, a /20 allows for 268435456 /48s. Is Telia really going to give half of the inhabitants of Europe a /48?

If you count in hierarchy loss - and there *will* have to be multiple layers of hierarchy and aggregation - the maximum subscribers you can reasonably connect are more likely to be in the "20-50 Millions" range. And this is a fairly realistic number for an ISP that's connecting millions of DSL and dial-up end-users in a large number of countries. What I really don't understand is why people are getting so negatively upset about /20s - what do you *want*? 1 billion /32s in the global routing table, making "efficient" and "conservative" use of FP 001 ? Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 60210 (58081) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

On Wed, 2004-05-12 at 08:47, Kurt Erik Lindqvist wrote:

On 2004-05-11, at 11.48, Gert Doering wrote:

...

What I really don't understand is why people are getting so negatively upset about /20s - what do you *want*? 1 billion /32s in the global routing table, making "efficient" and "conservative" use of FP 001 ?

Agreed. "Call me when we hit 1000 routes". Noone will be happier than me....

We are almost half way here, checking GRH which should give somewhat of a globally correct presentation, though there is not much input out of the APNIC corner, http://www.sixxs.net/tools/grh/status/ has: 458 good prefixes 17115 BGP AS-PATH entries 325 BGP community entries Minimum of 1 prefixes Average of 490 prefixes Maximum of 543 prefixes Good prefixes are the TLA's that actually get announced. There are thus also ~40 more specifics. And there are currently 739 allocations from RIR's to LIR's. If the people in the US would wake up they can add 50 visible routes. Having a 1000 IPv6 routes, educated guess, taking into account the number of new allocations made each year and that maybe 90% will also announce them with ~250 allocations in 2003 and 85 allocations already this first 5 months, which is on the low scale: estimation: 2,5+ years? But we do have to take in account that per 6/6/2006 6bone* is going away, which are currently 107 of the announced 'good prefixes', thus make it at least 3 years in total... Greets, Jeroen * According to the RFC, according to IANA it's 6/6/2004 ;) See http://www.iana.org/assignments/ipv6-tla-assignments

On 11-mei-04, at 12:17, amar wrote:

...

Still, a /20 allows for 268435456 /48s. Is Telia really going to give half of the inhabitants of Europe a /48?

I fully understand Your point of view.

No point of view, just asking.

P 48-P Total/48s Threshold Util% ------------------------------------- 20 28 268435456 5534417 2.1%

It is all based on RFC3194. Do You suggest that the HD-Ratio in RFC3194 should be changed?

The HD ratio is based on assumptions. We should base our policies on fact. The trouble with the HD ratio is that it assumes that one out of every five digits is lost due to aggregation boundaries. That assumption may hold occasionally, but it certainly won't as a general rule. This is especially true in IPv6, where the address length is very long. With 45 bits between the 2000::/3 and the subnet edge that's 9 bits that are lost. I think that's excessive. See http://www.bgpexpert.com/archive2003q3.php#12 (at the bottom) for some additional text on this. Now I don't have a very good idea about realistic aggregation levels in very large IPv6 ISP networks. If you can shed some light on this, that would be very useful.