I totally agree with you that a decision has to be thought about carefully before being implemented.
1. and 2. would be great if every ISP would aggregate properly, but quite difficult to achieve ! Regarding 3. and 4.: What about asking Tier-1 provider/region to originate big aggregates ?: RIPE-delegated blocks like 62.0.0.0/8 could be announced by AS286, AS702, AS5511, etc.. ARIN-ones like 64.0.0.0/6 announced by 701,3561,1,1239, etc.. APNIC-ones like 210/7 by AS 4637, etc Then 0/1, 128/2 and 192/3 could be annouced by every Tier-1, and filtered out as wanted by every Tier-2 etc... Maybe it could be interesting interesting to achieve that for us in CH, so that every ISP annouce the same within CH (of course letting the CH-peerings quite open) I agree that for now we can live with 106'000 prefixes, but if a solution is already planned and agreed, it can be implemented rather quickly in case of a rapid increase of the Internet-table/DoS attack/huge flapping,... ? We could define kind of a 'Swiss-table' with that, containing only useful routing-info, according to the well-known 'Swiss-quality', and propose that for multi-homed customers.. Have a nice day, Andr� At 00:16 07.02.2002 +0100, Andre Oppermann wrote: >Andre Chapuis wrote: >> >> Hi, >> We are thinking about filtering on Upstream/Peers based on smallest >> LIR allocations, like some ISP are already doing (SWITCH, Verio for >> example) >> This would reduce our Internet-table to 71602 !!! > >You come almost to the same numbers as Philip Smith in his RIPE41 >presentation on the routing table analysis: > http://www.ripe.net/ripe/meetings/archive/ripe-41/presentations/ > routing-rt-analysis/index.html > >However, the question is how much information do you want to lose? >With this kind of limitation it's like CD vs. MP3. Unfiltered versus >lossy compression. > >There are different ways of reducing the set of prefixes in the routing >table, these different methods differ primarily by their amount of >losing geniue prefixes: > > 1) Aggregate all more-specific prefixes if the origin-AS is the same > > 2) Aggregate all more-specifics and also aggregate the neighboring > prefixes themselfes if the origin-AS is the *same* > > 3) Filter all more-specific prefixes if an aggregate exists even if > the origin-as is not the same > > 4) Filter all prefixes which are longer than the RIR's minimum > allocation sizes for a netblock > >Note that I use the terms aggregating and filtering to highlight what >is actually happening in these cases. With *aggregating* you are *not* >actually losing any prefix NLRI information. Whereas with *filtering* >you *are* losing prefix NLRI information. Which means you might render >certain networks unreachable via you. > >So cases 1 and 2 are just compacting the routing table without any >loss of path and prefix informatin besides split-block traffic >engineering. > >Cases 3 and 4 would remove prefixes from the routing table based on >the policy. This leads to real loss of information and blackholes >certain networks not fitting the RIR allocation and filter rules. > >The problem with these case comparsions is, where case 1 and 2 would >be more correct to do, cases 3 and 4 are much easier to code in a >ip prefix-list. Otherwise you have to do mucho route-map magic to >let the router auto-aggregate. > > >But we also have to take a look on the different types of ISPs and >what this kind of filtering means to them. An ISP *not* providing >transit to other AS or multi-homed customers (ie. SWITCH) is, besides >the loss of some prefixes, not affected by this kind of aggregation. >For them it doesn't really matter as long as there is any path to >the destination. >For an ISP providing *transit* to other AS and multihomed customers >any of these cases has fatal effects on their ability to provide >transit services. This is because more-specific wins! So lets take >the case of a multihomed customer. You are doing this filtering and >by that eliminating approx 35'000 prefixes from the routing table >announced to the customer. The other ISP serving that customer is >providing all prefixes unfiltered. What happens is that your path >will loose far too often and much of the traffic will be carried by >the other ISP. So multihoming is becoming pointless to a certain >extent. > > >In the end one question ramains; what is the purpose of this? Do your >routers have problems carrying these many prefixes? Are your links or >router CPU's overloaded because of so many announcements and withdrawls? >Do want to set a net-political statement? > > >After having said that I'd recommend to wait with any decision on this >until after RIPE has finished their Multihoming Policy document which >will describe and recommend multiple ways of multihoming. Among them >is most likely a recommendation to use splits and announce them via >multiple upstreams. Your proposed filter will break this though... > >> You can find the filter at the end of the mail, kindly formatted/ >> provided by SWITCH (Thank you Simon) >> What is the general feeling about a kind of 'common' politic for >> Swiss ISPs ? >> Who would be interested as well ? > >I'm all for a set of common policies of Swiss ISP's developed here >on the SWINOG list (if common means that a majority will actually >adopt it). This kind of commoness would make sense also for route >flap dampening, or other issues like DDoS or SPAM/OpenRelay handling. > >For some issues it would be beneficial to follow the suggested values >of RIPE and their working groups. Also it would make sense to forward >the conclusions we've come to to the respective RIPE working group for >consideration. > >> We would let the filters open for CH-peerings, in order for our >> common multihomed customers using our PA assignments to have >> redundancy of course. > >The problem is this multihoming won't work anymore if many ISP's >also start doing this heavy filtering as you do... > >> I am currently asking our customers (and sub-customers) to respect >> this (as far as possible...) >> Currently in AS-SWCMGLOBAL we have 55 prefixes transgressing this >> policy, but it should be easily reduced to a minimal set of >> 'exceptions'; it is hard to incitate our peers to do it, and not >> doing it ourselves... > >Yes ;-) > >-- >Andre >(AO6-RIPE) > > >> Feedback is welcome !! >> >> Have a nice evening, >> Andr� >> >> !!! Prefix list "martians" >> !!! Match prefixes that people should *not* announce to us. >> !!! To be used in a "deny" stance of an ingress route-map >> !!! >> !!! Date Created: 21-Nov-2001 >> !!! RCS $Header: /common/cisco/tftp/pfl/RCS/pf-martians,v 1.5 2002/01/07 14:06:38 >leinen Exp $ >> !!! >> no ip prefix-list martians >> !! Special-use address blocks - http://www.isi.edu/~bmanning/dsua.html >> ip prefix-list martians permit 0.0.0.0/8 >> ip prefix-list martians permit 10.0.0.0/8 le 32 >> ip prefix-list martians permit 127.0.0.0/8 >> ip prefix-list martians permit 169.254.0.0/16 le 32 >> ip prefix-list martians permit 172.16.0.0/12 le 32 >> ip prefix-list martians permit 192.0.2.0/24 le 32 >> ip prefix-list martians permit 192.168.0.0/16 le 32 >> !! RIPE - http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html >> ip prefix-list martians deny 62.0.0.0/8 ge 9 le 19 >> ip prefix-list martians deny 80.0.0.0/7 ge 9 le 20 >> ip prefix-list martians deny 193.0.0.0/8 ge 9 le 24 >> ip prefix-list martians deny 194.0.0.0/8 ge 9 le 24 >> ip prefix-list martians deny 195.0.0.0/8 ge 9 le 20 >> ip prefix-list martians deny 212.0.0.0/7 ge 9 le 19 >> ip prefix-list martians deny 217.0.0.0/8 ge 9 le 20 >> !! APNIC - http://www.apnic.net/db/min-alloc.html >> ip prefix-list martians deny 61.0.0.0/8 ge 9 le 20 >> ip prefix-list martians deny 202.0.0.0/7 le 24 >> ip prefix-list martians deny 210.0.0.0/8 ge 9 le 20 >> ip prefix-list martians deny 211.0.0.0/8 ge 9 le 20 >> ip prefix-list martians deny 218.0.0.0/7 ge 9 le 20 >> ip prefix-list martians deny 220.0.0.0/8 ge 9 le 20 >> !! ARIN - http://www.arin.net/regserv/IPStats.html#cidr >> ip prefix-list martians deny 24.0.0.0/8 le 20 >> ip prefix-list martians deny 63.0.0.0/8 ge 9 le 19 >> ip prefix-list martians deny 64.0.0.0/6 ge 9 le 20 >> ip prefix-list martians deny 68.0.0.0/8 ge 9 le 20 >> ip prefix-list martians deny 196.0.0.0/8 ge 9 le 24 >> ip prefix-list martians deny 198.0.0.0/7 ge 9 le 24 >> ip prefix-list martians deny 200.0.0.0/8 ge 9 le 24 >> ip prefix-list martians deny 204.0.0.0/6 ge 9 le 24 >> ip prefix-list martians deny 208.0.0.0/7 ge 9 le 20 >> ip prefix-list martians deny 216.0.0.0/8 ge 9 le 20 >> ! "Swamp" >> ip prefix-list martians deny 192.0.0.0/8 ge 10 le 24 >> ! Fall-through for undocumented ranges of historical Class A/B/C space >> ip prefix-list martians deny 0.0.0.0/1 ge 8 le 19 >> ip prefix-list martians deny 128.0.0.0/2 ge 8 le 19 >> ip prefix-list martians deny 192.0.0.0/3 ge 10 le 19 >> ip prefix-list martians permit 0.0.0.0/0 le 32 >> end >> >> --------------------- >> Andr� Chapuis >> IP+ Engineering >> Swisscom Ltd >> Genfergasse 14 >> 3050 Bern >> +41 31 893 89 61 >> [EMAIL PROTECTED] >> CCIE #6023 >> --------------------- >> >> ---------------------------------------------- >> [EMAIL PROTECTED] Maillist-Archive: >> http://www.mail-archive.com/swinog%40swinog.ch/ >---------------------------------------------- >[EMAIL PROTECTED] Maillist-Archive: >http://www.mail-archive.com/swinog%40swinog.ch/ --------------------- Andr� Chapuis IP+ Engineering Swisscom Ltd Genfergasse 14 3050 Bern +41 31 893 89 61 [EMAIL PROTECTED] CCIE #6023 --------------------- ---------------------------------------------- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
