2005-05-05 [08:51:43] --- ferenc has become available 2005-05-05 [08:51:49] --- ferenc has left 2005-05-05 [08:56:55] * evilmarq has joined the channel. 2005-05-05 [09:01:26] --- ferenc has become available 2005-05-05 [09:01:48] --- rhe has become available 2005-05-05 [09:03:11] Hi, I'll be doing the monitoring of this room. If you have any questions to the speakers please tell me and I wiil read it out at the end of the presentation. 2005-05-05 [09:07:10] --- iljitsch has become available 2005-05-05 [09:07:10] --- iljitsch has left: Lost connection 2005-05-05 [09:08:07] * imo has joined the channel. 2005-05-05 [09:08:08] I'm having problems joining the stream... 2005-05-05 [09:09:45] ah, now it works 2005-05-05 [09:12:24] --- iljitsch has become available 2005-05-05 [09:13:34] --- cagri has become available 2005-05-05 [09:18:26] * marcoh has joined the channel. 2005-05-05 [09:19:00] would it be possible to make the audio levels more closely together? the main speaker is loud, the rest (esp jaoa) are hard to hear 2005-05-05 [09:21:04] joao is just still tired++ :-) 2005-05-05 [09:21:18] from what? 2005-05-05 [09:22:11] * will has joined the channel. 2005-05-05 [09:22:13] some serious compressioin would solve those level problems though :-) 2005-05-05 [09:22:21] I spoke to James from RIPE NCC who is resposible for the tech infrastr. He'll try to fix it or get someone to fix it 2005-05-05 [09:22:31] --- jhma has become available 2005-05-05 [09:27:34] nothing at all for all my customers 2005-05-05 [09:28:10] doesn't help small networks. 2005-05-05 [09:31:37] we should be careful: just because flap dampening doesn't do anything for smaller networks doesn't mean it isn't still useful in large networks. 2005-05-05 [09:33:27] could someone please inject some clue: flap dampening almost NEVER works against flapping customers!!! 2005-05-05 [09:35:10] do you want me to read this out? 2005-05-05 [09:35:16] yes 2005-05-05 [09:35:52] add: flap dampening informationis removed when the bgp session goes down so you can't dampen flaps towards a neighboring router. 2005-05-05 [09:37:26] don't hear anything... 2005-05-05 [09:38:38] pls read out as response to iljitsch: I've seen enough customers flapping announcement without flapping BGP session because of lacking internal backbone redundancy. And that flap statistics are being cleared when session goes down might be implementation specific 2005-05-05 [09:39:13] * jluk has joined the channel. 2005-05-05 [09:39:26] * sleinen has joined the channel. 2005-05-05 [09:40:04] dr: yes that can happen but flapping links won't be dampened in your as, but in the next one if they have it enabled. I'm not sure how common flapping with a stable session is for end-users. 2005-05-05 [09:40:13] hm ok, don't read it out... doesn't add to much info to the discussion 2005-05-05 [09:40:16] it could be implementation specific but I very much doubt it. 2005-05-05 [09:40:21] and joao seems to want to finish ;) 2005-05-05 [09:41:17] (all my dampening knowledge stems from the source of all networking: cisco) 2005-05-05 [09:41:43] iljitsch: IIRC, JunOS is different. but would have to double-check this assertion 2005-05-05 [09:42:04] ok I'm volunteering then! 2005-05-05 [09:48:26] * StoCron has joined the channel. 2005-05-05 [09:48:33] * nickname changed from StoCron to cron2 2005-05-05 [09:50:24] so should we start deaggregating if we want to participate in the discussion?? 2005-05-05 [09:50:29] :-) 2005-05-05 [09:51:02] (cron2) ijlitsch: if that brings a solution... :) 2005-05-05 [09:51:46] makes you yearn for the good old days when sprint set up prefix length filtering... 2005-05-05 [09:52:21] (cron2) even so it doesn't help if people announce their /16 AND all 256 /24s out of it ("due to fear of spoofing") - so you need to maintain all the filters locally as well 2005-05-05 [09:53:36] these people better hope that I'll never work at a large network again because I'd filter them the first day on the job. 2005-05-05 [09:54:15] (cron2) the problem is "if these people are large enough, YOUR customers will suffer if you filter them", which makes this ugly 2005-05-05 [09:54:25] and your bottom line 2005-05-05 [09:54:30] filtering costs money 2005-05-05 [09:54:39] that's one of the problems 2005-05-05 [09:54:43] (cron2) dr: yep 2005-05-05 [09:54:48] traffic follows most specific route 2005-05-05 [09:54:55] lost traffic => lost revenue 2005-05-05 [09:55:05] this is the basic crux for BGP transits 2005-05-05 [09:55:07] you need to be big enough that they'll suffer enough to notice, regardless of your users. 2005-05-05 [09:55:28] nah. don't see this critical mass obtainable 2005-05-05 [09:55:29] (cron2) iljitsch: yes, unfortuantely the big guys don't seem to care 2005-05-05 [09:55:38] (jluk) or have enough other people doing the same so that they have to pay attention 2005-05-05 [09:55:45] you'd need the tier 1 to do so _and_ a significant bunch of the tier 2 2005-05-05 [09:57:03] there are also lots of people that think deaggregation is the only and/or best way to do traffic engineering. 2005-05-05 [09:59:09] what ripe should do is have separate blocks for different prefix sizes. 2005-05-05 [09:59:22] Rank AS AS Name Current Wthdw Aggte Annce Redctn % 2005-05-05 131 AS3320 DTAG Deutsche Telekom AG 301 86 21 236 65 21.59% 2005-05-05 [09:59:31] hm ruediger... "extremely highly aggregated"? 2005-05-05 [09:59:33] (cron2) iljitsch: they have 2005-05-05 [09:59:34] so 90/8 = /24, 91/8 = /22, 92/8 = /20 and so on 2005-05-05 [09:59:40] makes for easy prefix length filtering. 2005-05-05 [09:59:54] cron2: really. 2005-05-05 [10:00:10] (cron2) there's a ripe document that specifies min allocation size per /8 (and its updated regularily) 2005-05-05 [10:00:11] (jluk) that's about the only way I can think to do it. 2005-05-05 [10:00:23] (jluk) How would you know which /24's to filter. 2005-05-05 [10:00:35] (jluk) It has to be done automatically, not by hand 2005-05-05 [10:01:15] (sleinen) What about a Web form that can be used to generate prefix filters? 2005-05-05 [10:01:27] https://www.ripe.net/ripe/docs/smallest-alloc-sizes.html byt then there is stuff such as "195/8 allocation /19 assignment /29 2005-05-05 [10:01:27] (sleinen) Based on: min-alloc.html of the various registries + your own preferences... 2005-05-05 [10:01:32] what does this mean??? 2005-05-05 [10:01:58] (jluk) sleinen: what, so you're going to filter all /24's including PI 2005-05-05 [10:02:03] --- ferenc has left: Logged out 2005-05-05 [10:02:19] (sleinen) + defaults for pre-RIR nets 2005-05-05 [10:02:25] iljitsch: /19s to LIRs, /29s as PI? 2005-05-05 [10:02:34] sleinen: not all PI is pre-RIR 2005-05-05 [10:02:43] (sleinen) I know 2005-05-05 [10:02:49] --- ferenc has become available 2005-05-05 [10:02:57] (sleinen) The PI space *is* documented at RIPE NCC 2005-05-05 [10:02:58] rhe: that seems too ridiculous to be true... but what else can it mean? 2005-05-05 [10:03:19] *everything* is documented but good luck building filters based on it. 2005-05-05 [10:03:37] (sleinen) Thanks, I do build filters from that. 2005-05-05 [10:04:13] (sleinen) It's just that you have to interpret the doc intelligently 2005-05-05 [10:04:21] (sleinen) and that's a matter of "taste" 2005-05-05 [10:04:27] steinen: what do you mean? 2005-05-05 [10:04:30] (sleinen) Hence the tool should be customizable... 2005-05-05 [10:04:49] (sleinen) E.g.: whether you want to slavishly follow RIR min-alloc 2005-05-05 [10:04:50] (will) the problem is if everyone builds filters based on their interpretation of a document that was never designed for that use it is difficult to have a good idea of what will actually work IRL 2005-05-05 [10:05:00] (sleinen) even when it tells you to accept /29 (I don't). 2005-05-05 [10:05:37] (sleinen) The problem is currently it's too easy to know what will actually work: 2005-05-05 [10:05:42] it's very simple: there are many people out there that will do just about everything that shouldn't be done as long as they can get away with it 2005-05-05 [10:05:52] (sleinen) Announcing /24 at will from PA Space works in 99.9% of the Internet 2005-05-05 [10:06:12] (sleinen) Iljitsch is right. 2005-05-05 [10:06:30] and as long as some "good" people do bad things, we can't filter all those bad things so the bad people aren't punished so those continue to do it, the "good" people think it's normal and you get 160000 routes. 2005-05-05 [10:07:15] (sleinen) Actually, what we do is this: 2005-05-05 [10:07:17] (jluk) If enough people filter them, then the 'good' people will change :) 2005-05-05 [10:07:24] (sleinen) * use relatively strict filters based on min-alloc etc. 2005-05-05 [10:07:35] (sleinen) * tell our peers when we filter out their more-specifics 2005-05-05 [10:07:39] jluk: right. but then enough people have to filter. 2005-05-05 [10:07:58] (sleinen) * when peer gives us a good explanation, we make TEMPORARY exceptions to allow for renumbering into better space 2005-05-05 [10:08:45] I think it would be good to allow one or two more bits than the minimum allocation (except when you get > /24) so people get to do some forceful traffic engineering when necessary. 2005-05-05 [10:09:35] (sleinen) If you think so, then that number of additional "traffic engineering" specificity should be a parameter of the filter-generation script 2005-05-05 [10:09:54] (sleinen) (I'd probably set it to zero but that's just me.) 2005-05-05 [10:10:32] also, I'd be happy to get smaller blocks over peering to optimize local/regional routing. 2005-05-05 [10:10:44] but I don't want to see this stuff from other continents 2005-05-05 [10:11:26] (sleinen) Right. The reason we do this with our peers is that we know them, and the feedback works (sometimes). 2005-05-05 [10:12:09] (sleinen) From the other continents, I mostly aggregate EVERYTHING to 0.0.0.0/0 :-) 2005-05-05 [10:13:02] we really need geographic aggregation... allow small blocks from the neighborhood, medium size from the region and only large from the rest of the world. 2005-05-05 [10:14:23] ferenc: please relay: 2005-05-05 A) "less-specifics don't hurt, only more-specifics can be harmful, so don't filter "greater-or-equal" 2005-05-05 B) many IPv6 players out there currently have NO real concept of "upstream", 2005-05-05 "peer" and "downstream" 2005-05-05 [10:15:22] don't talk bgp with these people because your traffic will be sucked into tunnels that circle the globe several times. 2005-05-05 [10:15:32] yes 2005-05-05 [10:17:32] (cron2) I think Ruediger's comment is the best: "make sure the IRRs have route6: and rs-set objects!" 2005-05-05 [10:18:19] --- jakob has become available 2005-05-05 [10:23:29] ferenc: do we have the current presentation online? 2005-05-05 [10:24:39] http://rosie.ripe.net/ripe/meetings/ripe-50/presentations/uploads/Thursday/colitti-active_bgp_probing.pdf 2005-05-05 [10:24:42] thx 2005-05-05 [10:26:21] * KnockandO has joined the channel. 2005-05-05 [10:26:29] --- jakob has left 2005-05-05 [10:33:07] (KnockandO) There's lots of false assumptions in this presentation... 2005-05-05 [10:33:28] (cron2) is it? I'm convinced it works well - except upsetting routers on the path 2005-05-05 [10:33:33] (cron2) possibly 2005-05-05 [10:33:40] (KnockandO) How many ASs can you exclude? 2005-05-05 [10:34:12] (KnockandO) You will find a lot of possible paths and with some complicated paths never know whether this one is feasible... 2005-05-05 [10:34:14] (cron2) about 70-80 2005-05-05 [10:34:17] (KnockandO) (AECD etc.) 2005-05-05 [10:34:23] --- iljitsch has left 2005-05-05 [10:34:40] (KnockandO) Actually, this is just guessing on a higher level. 2005-05-05 [10:34:48] (cron2) no, it's not :) 2005-05-05 [10:35:50] * UncleH has joined the channel. 2005-05-05 [10:35:56] (KnockandO) You have to be lucky to get the result you expect when excluding ASs along the two paths he showed 2005-05-05 [10:36:11] (cron2) the RTT test is not so helpful, but the actual path exploration will work deterministically 2005-05-05 [10:36:17] (KnockandO) May take you a long time excluding ASNs until your path is confirmed. 2005-05-05 [10:36:37] (KnockandO) Yup, you can prove positive results, but not getting any result doesn't mean that path is not feasible. 2005-05-05 [10:37:07] (KnockandO) But admittedly, this approach helps a lot in discovering the net. 2005-05-05 [10:37:18] (cron2) of course a single announcement / BGP check isn't going to help you much - you need to do this level by level, until you have mapped everything around it 2005-05-05 [10:37:57] (cron2) s/it/you/ 2005-05-05 [10:40:24] no, people don't know why $box crashed out of the air two weeks after the memory corruption happened 2005-05-05 [10:40:32] and nobody can find out afterwards why 2005-05-05 [10:41:26] (cron2) dr: this is a valid argument, but this is something vendors should test for (automatically) - send in maximum-length paths, as-sets, community sets, etc., to figure out whether their buffer management works 2005-05-05 [10:41:42] cron2: "should" is the right word 2005-05-05 [10:41:59] (jluk) for all I know they may already do it 2005-05-05 [10:42:00] cron2: can I try the safety lock of my .45ACP while pointing at you? ;) 2005-05-05 [10:42:39] "try" as in "test wether it works as designed and tested in factory" ;) 2005-05-05 [10:42:40] (cron2) dr: that's a not really valid comparison - and gun vendors usually *do* test their equipment... 2005-05-05 [10:43:02] sure, then you should be comfortably for me to repeat this test on you live object ;) 2005-05-05 [10:43:23] I think it's irresponsible to push the boundaries like that 2005-05-05 [10:43:32] (cron2) no, because there is no information to be gained from that (except see how well my nerves are) 2005-05-05 [10:43:49] cron2: they could test their tools in lab too 2005-05-05 [10:43:58] (KnockandO) At least, this prepending game is big fun :) 2005-05-05 [10:44:05] (KnockandO) Let's try and break routers... 2005-05-05 [10:44:12] (cron2) dr: they did, but to actually collect path informations, you need to go out 2005-05-05 [10:44:12] (KnockandO) Coffee break. 2005-05-05 [10:49:47] * evilmarq has left the channel. 2005-05-05 [10:50:27] ferenc: thanks for relaying 2005-05-05 [10:51:29] --- dr has left 2005-05-05 [10:56:09] --- jhma has left 2005-05-05 [10:58:50] * marcoh has left the channel. 2005-05-05 [11:01:30] --- rhe has left 2005-05-05 [11:02:20] --- ferenc has left 2005-05-05 [11:03:58] * KnockandO has left the channel. 2005-05-05 [11:04:12] * cron2 has left the channel. 2005-05-05 [11:05:13] * UncleH has left the channel. 2005-05-05 [11:10:37] * imo has left the channel. 2005-05-05 [11:11:00] * will has left the channel. 2005-05-05 [11:19:25] (jluk) hmm, I just seem to have lost the video feed - Is it me or is it gone ? 2005-05-05 [11:22:57] * jluk has left the channel. 2005-05-05 [11:23:02] * jluk has joined the channel. 2005-05-05 [11:23:10] * sleinen quit IRC altogether 2005-05-05 [13:51:57] * jluk has left the channel. 2005-05-05 [14:30:28] --- irc has left: Replaced by new connection 2005-05-05 [14:30:28] --- irc has become available 2005-05-05 [14:30:30] --- irc has left: Disconnected 2005-05-05 [14:30:31] --- irc has become available