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

2004-09-06 Thread Roland Perry
In article <[EMAIL PROTECTED]>, Daniel Karrenberg <[EMAIL PROTECTED]> writes 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 recommen

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

2004-09-06 Thread Daniel Karrenberg
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,

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

2004-09-04 Thread David Barak
--- Petri Helenius <[EMAIL PROTECTED]> wrote: > Pay me to treat your prefixes more nicely? 1/2 :-) > Isn't that the difference between transit and peering? Does anyone dampen people who are paying them? = David Barak -fully RFC 1925 compliant-

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

2004-09-04 Thread Robert E . Seastrom
Bill Woodcock <[EMAIL PROTECTED]> writes: > What about the ccTLD prefixes? There are a lot more of them. And the > gTLDs? And exchange points? And Microsoft Update servers? Where do you > stop? If you simply don't dampen (hooray for adequate CPUs), then you are not only honoring the "golde

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

2004-09-04 Thread Petri Helenius
Bill Woodcock wrote: On Fri, 3 Sep 2004, Iljitsch van Beijnum wrote: > the logic seems rather irrefutable: > - as a rule, shorter prefixes are more important and/or more stable > than long ones > - so we dampen long prefixes more aggressively > - the root DNS servers tend to liv

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

2004-09-04 Thread Bill Woodcock
On Fri, 3 Sep 2004, Iljitsch van Beijnum wrote: > the logic seems rather irrefutable: > - as a rule, shorter prefixes are more important and/or more stable > than long ones > - so we dampen long prefixes more aggressively > - the root DNS servers tend to live in long pref

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

2004-09-04 Thread Bill Woodcock
On Sat, 4 Sep 2004, Alex Bligh wrote: > if in a heavily plural anycast domain prefix route changes are more > common than "normal" routes (albeit without - dampening aside - > affecting reachability), does this mean route dampening > disproportionately harms such routes? Thi

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

2004-09-04 Thread Alex Bligh
--On 02 September 2004 16:09 -0700 John Bender <[EMAIL PROTECTED]> wrote: This would not be as problematic if dampening could be applied to a path rather than a prefix, since an alternate could then be selected. But since this would require modifications to core aspects of BGP (and additional m

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

2004-09-04 Thread Stephen J. Wilcox
On Fri, 3 Sep 2004, Rodney Joffe wrote: > On Sep 3, 2004, at 10:46 AM, Stephen J. Wilcox wrote: > > >> Given Network A, which has "golden network" content behind it as described > >> by the RIPE paper (root and tld data), if the network has some combination > >> of events that result in all of t

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

2004-09-04 Thread Rodney Joffe
Roland Perry wrote: Did you mean "parts of RIPE-NCC"? Sorry to be so pedantic, but this thread started off with a mild diversion caused by confusion between RIPE and RIPE-NCC. You're right - it is a little confusing. According to their joined "about" pages, RIPE-NCC provides the administrative s

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

2004-09-04 Thread Roland Perry
In article <[EMAIL PROTECTED]>, Rodney Joffe <[EMAIL PROTECTED]> writes For those who care, based on responses and some analysis, it appears that very few networks do follow the ripe-229 recommendations regarding "golden networks", including, oddly enough, parts of RIPE itself. Did you mean "par

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

2004-09-03 Thread Rodney Joffe
Hi Steve, Steve Gibbard wrote: On Thu, 2 Sep 2004, Rodney Joffe wrote: So, it seems to me that there are three questions here: What is critical infrastructure? DNS for which domains? What about other services? Google? Hotmail or Yahoo? The answer to this presumably varies considerably from pl

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

2004-09-03 Thread Steve Gibbard
On Thu, 2 Sep 2004, Rodney Joffe wrote: > You are absolutely right in suggesting that .foo has to get its act > together. You may even tell your users that. But you'll be telling > every single one of them, because every single one of them is going to > attempt to resolve .foo domain names during

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

2004-09-03 Thread Rodney Joffe
On Sep 3, 2004, at 10:46 AM, Stephen J. Wilcox wrote: Given Network A, which has "golden network" content behind it as described by the RIPE paper (root and tld data), if the network has some combination of events that result in all of their announcements to you being dampened by you, your user

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

2004-09-03 Thread Stephen J. Wilcox
On Thu, 2 Sep 2004, Rodney Joffe wrote: > On Sep 2, 2004, at 2:58 PM, Randy Bush wrote: > > >> If you don't implement ripe-229, why not? > > > > because the golden address space stuff is stupid > > > > OK. I'll bite... > > Given Network A, which has "golden network" content behind it as descri

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

2004-09-02 Thread Jared Mauch
On Fri, Sep 03, 2004 at 10:03:26AM +1200, Randy Bush wrote: > > I don't fundamentally have a problem with any of it. 4 flaps before you > > start dampening in a time window is a lot of flapping. > > you may want to look at > > http://rip.psg.com/~randy/030226.apnic-flap.pdf I've been w

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

2004-09-02 Thread John Bender
On Fri, 3 Sep 2004 00:15:42 +0200 Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote: > But then again, dampening really doesn't buy you much as it only > applies to routes that are flapping beyond the link to the next AS. So > if you have > an instable link somewhere, you can't dampen that > inst

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

2004-09-02 Thread Randy Bush
>> because the golden address space stuff is stupid > Given Network A, which has "golden network" content behind it as > described by the RIPE paper i don't care. if i had spare time on my hands, i would damp them more quickly for stupidity and greed. again, golden network space is a stupid id

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

2004-09-02 Thread Rodney Joffe
Hi Randy, On Sep 2, 2004, at 2:58 PM, Randy Bush wrote: If you don't implement ripe-229, why not? because the golden address space stuff is stupid OK. I'll bite... Given Network A, which has "golden network" content behind it as described by the RIPE paper (root and tld data), if the network has

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

2004-09-02 Thread Iljitsch van Beijnum
On 2-sep-04, at 23:58, Randy Bush wrote: If you don't implement ripe-229, why not? because the golden address space stuff is stupid Maybe so, but the logic seems rather irrefutable: - as a rule, shorter prefixes are more important and/or more stable than long ones - so we dampen long prefixes mor

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

2004-09-02 Thread Randy Bush
> I don't fundamentally have a problem with any of it. 4 flaps before you > start dampening in a time window is a lot of flapping. you may want to look at http://rip.psg.com/~randy/030226.apnic-flap.pdf randy

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

2004-09-02 Thread Randy Bush
> If you don't implement ripe-229, why not? because the golden address space stuff is stupid

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

2004-09-02 Thread Deepak Jain
Is bgp dampening really necessary anymore? Obviously we should dampen people that flap a high number of times in an hour, but the vast majority of the internet operates in a state where dampening causes more pain than benifit, imho. I agree with your line of reasoning. However, if you fo

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

2004-09-02 Thread Jared Mauch
On Thu, Sep 02, 2004 at 08:44:34AM -0700, Rodney Joffe wrote: > See: http://www.ripe.net/ripe/docs/routeflap-damping.html > and > http://www.qorbit.net/documents/golden-networks (thanks, Steve!) > > If you do, what parameters do you use, or do you not dampen the "golden > networks" at all? > >

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

2004-09-02 Thread John Curran
Bill, I agree with your general line of reasoning, but would likely characterize RIPE as an RIR *and* operator forum... formulating and reviewing recommendations on operational matters make some sense as a result. As to the particular set of prefixes, there's a great question as to wh

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

2004-09-02 Thread Frederico A C Neves
On Fri, Sep 03, 2004 at 04:06:12AM +1200, Bill Manning wrote: > > well > > RIPE is the RIR for Europe. RIPE-229 is, from my viewpoint, arbitrary > and capricious. > the root servers are -ONE- set of interesting servers. what about the > web sites that point > to these "important" docume

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

2004-09-02 Thread Bill Manning
well RIPE is the RIR for Europe. RIPE-229 is, from my viewpoint, arbitrary and capricious. the root servers are -ONE- set of interesting servers. what about the web sites that point to these "important" documents? or the time servers, or my NOC & monitoring machines? The idea of an Inte

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

2004-09-02 Thread Rodney Joffe
Hello folks, This is actually NANOG applicable, despite referring to RIPE... ;-) How many of you who manage BGP speaking networks implement the RIPE "best practices" regarding dampening parameters for so-called "golden networks"? See: http://www.ripe.net/ripe/docs/routeflap-damping.html and ht