Re: RIPE "Golden Networks" Document ID - 229/210/178
--- 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- __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
Re: RIPE "Golden Networks" Document ID - 229/210/178
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 "golden networks", you aren't setting yourself up for annoyance. ---Rob
Re: RIPE "Golden Networks" Document ID - 229/210/178
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 live in long prefixes > - so we exclude the root DNS prefixes 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? Pay me to treat your prefixes more nicely? 1/2 :-) Pete
Re: RIPE "Golden Networks" Document ID - 229/210/178
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 prefixes > - so we exclude the root DNS prefixes 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? -Bill
Re: RIPE "Golden Networks" Document ID - 229/210/178
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? This would be an argument in favor of either asking peers to tag anycast-learned routes no-export, as F-root does, or using anycast prefixes which are short enough that they won't make it through many people's filters, and advertising the aggregate from your tunnel-hub (which is presumed to be stable), as we do. I suspect that a stand-alone prefix, advertised with equal mask length from all instances, without no-export, would be relatively more vulnerable to dampening, as Alex suggests. Topologically, it appears little different than a massively peered or massively multi-homed network of any other sort, as the papers Randy is citing describe. -Bill
Re: RIPE "Golden Networks" Document ID - 229/210/178
--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 memory and processor requirements) it does not seem a likely solution. Hmmm So returning to the illustration Rodney gave Randy about the .foo domain, are we saying that if the .foo domain's DNS is anycast, then as (just from statistics of multiple paths) prefix flaps (as opposed to flaps of individual paths) are going to be more likely [*], route dampening adversely affects such (anycast) sources more than straight unicast? Or, looking at it the other way around, if in a heavily plural anycast domain prefix route changes (as opposed to route changes of individual paths) are more common than "normal" routes [*] (albeit without - dampening aside - affecting reachability), does this mean route dampening disproportionately harms such routes? i.e. is the answer to Randy "because such networks [might] have a higher tendency to use anycast. * = note untested assumption Alex
Re: RIPE "Golden Networks" Document ID - 229/210/178
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 their announcements to you being dampened > >> by you, your users can't get "there". For grin's, let's say we're talking > >> about .foo, one of the larger gtld's. > > > > But .foo is announced from 13 IPs globally, allowing for anycast probably 40 > > nodes. If gtld-A has an incident it may be a good thing to dampen it from > > the internet as it may not be reachable, the other 12 gtlds will be able to > > serve responses in a stable manner. > > > > Unless you're suggesting *all* the gtlds are flapping at once? > > Sorry. I thought I made that clear, in that "if the network has some > combination of events that result in all of their announcements to you > being dampened by you". I am not talking about events that happen all > of the time, where one of 13 hiccups. .foo may have 13 IPs but they > have two upstream providers, and the event causes all of their routes > to flap. ok so as someone else mentioned this would be a local problem. in a network such as this, you should be concerned for the possibility of having large numbers of prefixes dampened and soften your dampening parameters accordingly. there is nothing special in this scenario about 'golden networks' Steve
Re: RIPE "Golden Networks" Document ID - 229/210/178
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 support for RIPE. So I guess it is a part of RIPE. But to answer you properly, I meants parts of RIPE, specifically including RIPE-NCC, do not follow the RIPE-NCC recommendations. ;-) /rlj
RE: Best Practices for Enterprise networks
--On söndag 29 augusti 2004 17.42 -0700 Michel Py <[EMAIL PROTECTED]> wrote: > >>> Tracy Smith wrote: >>> Specifically, to NAT or not to NAT? > > This is not much of an issue anymore. If you receive IP addresses from > your ISP, not natting would be foolish. No. Renumbering is easy and fun, not to mention a great source of revenue for IT consultants. > Even if you do own your own > public IP space, the NAT issues are fundamentally no different than the > firewall ones Yes, they are. NAT and firewalling are orthogonal. They just are bundled in a lot of bad products. > and since not having a firewall is not an option, Yes, it is. Firewalls in the corporate environments have lead to the pathetic state of notpatchedness that allows simple email virii to take down entire enterprises simply because "inside the firewall everyone are nice". Such solutions make much more damage than good. > most > enterprises will indeed NAT some of their subnets in their firewalls, > whether or not they have or could easily obtain public space. Finally, you are correct, although not because you describe some clever plan for enterprise network management, but instead you describe the pathetic state of notworking that permeates (with the aid of overpaid undercompetent firewall conslutants (I used to be one.)) through the corporate world. >> Paul Ferguson wrote: >> Asymmetric paths are a fact of life in the Internet. > > Not for enterprise operators except the largest ones. Except when people, being people, mess up. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE pgpvMdtWCtFmd.pgp Description: PGP signature
Re: RIPE "Golden Networks" Document ID - 229/210/178
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 "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. -- Roland Perry
