North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: RIPE "Golden Networks" Document ID - 229/210/178

  • From: Daniel Karrenberg
  • Date: Mon Sep 06 05:06:59 2004

Some facts:

"RIPE" is an operator forum, comparable to NANOG, APRICOT, AFNOG, ....
(Strictly speaking RIPE pre-dates all of the others if one disregards
that NANOG started as the NSFnet regional network meetings. ;-)

"RIPE NCC" is a Regional Internet Registry, comparable to ARIN, APNIC, LACNIC, AFRINIC, ....
(The RIPE NCC is the first of the regional registries.)

RIPE is the public forum where RIPE NCC policies and procedures are set;
they describe how the RIR allocates and assigns internet numbers.

RIPE NCC policies and procedures are *extremely* careful not to prescribe
any inter-domain routing practises and go out of their way to stress that
operators have the authority about that.

RIPE also makes general recommendations, which have nothing to do with the 
RIPE NCC. The "golden networks" recommendations are in this category.
They are also just that: recommendations.


-----------


Some opinions:

The goals of the RIPE recommendations are laudable: Make dampening
work predictably by aligning parameters. They reflect a general 
belief in "think globally, act locally" which still permeates 
RIPE discussions.

However, this is not likely to work because:

	- operators have the sole authority about routing
	- different local goals
	- different capabilities of infrastructure 
	- different capabilities of staff (design and operation)
	- sheer ignorance

(Yes, I tend to be a bit more cynical these days 
than the average RIPE attender.)

I doubt if a survey such as Rodney tries to perform will yield
any useful results because responses will not be universal nor
evenly distributed. 

------

More personal opinions:

If there is a significant number of operators that want to base any of
their decisions on what services are behind specific addresses, this
cannot be solved by static documents but must be solved by a registry. 
I would design this as a voluntary registry which operators may use in
any which way they want if they choose to.  The *art* in the design of
such a registry would be defining the classes of services and agreeing
on how to verify that an address houses a service of a given class 
for some classes such as DNS root and TLD servers. 

OTOH for DNS root and TLD servers, determining their addresses is
trivial using the DNS itself and the containing prefixes can be found
from current BGP tables and/or BGP archives such as the RIS.  
So the case for such a registry for DNS servers alone is highly questionable. 

Daniel