From smd at clock.org Wed Mar 14 10:25:35 2001 From: smd at clock.org (smd at clock.org) Date: Wed, 14 Mar 2001 02:25:35 -0800 Subject: most current version Message-ID: <20010314102543Z27268-27327+2@cesium.clock.org> | as he is known to be net.alive, his lack of comment is probably a statement | of some sort. unfortunately, no one knows what sort! IIRC Abha said it wasn't ready for review, so click, off went my attention. Did I miss new instructions? Sean. From ahuja at umich.edu Wed Mar 14 18:50:36 2001 From: ahuja at umich.edu (abha ahuja) Date: Wed, 14 Mar 2001 13:50:36 -0500 (EST) Subject: most current version In-Reply-To: <20010314102543Z27268-27327+2@cesium.clock.org> Message-ID: okay... here is pointer. http://www.merit.edu/~ahuja/draft-ptomaine-taxonomy-00.txt i sent to bcole to review as well. will announce today. in meantime, you folks should prolly subscribe to list (thanks, heas!) if you haven't already.... -abha ;) majordomo at shrubbery.net, subscribe ptomaine From heas at shrubbery.net Wed Mar 14 21:04:15 2001 From: heas at shrubbery.net (john heasley) Date: Wed, 14 Mar 2001 13:04:15 -0800 Subject: most current version In-Reply-To: ; from ahuja@umich.edu on Wed, Mar 14, 2001 at 01:50:36PM -0500 References: <20010314102543Z27268-27327+2@cesium.clock.org> Message-ID: <20010314130415.B10413@shrubbery.net> Wed, Mar 14, 2001 at 01:50:36PM -0500, abha ahuja: > > okay... > > here is pointer. > http://www.merit.edu/~ahuja/draft-ptomaine-taxonomy-00.txt > > i sent to bcole to review as well. > will announce today. > > in meantime, you folks should prolly subscribe to list (thanks, heas!) if > you haven't already.... > > -abha ;) > > majordomo at shrubbery.net, subscribe ptomaine the draft doesnt consider differences of effects from the POV of a transit AS (ie: teir 1 or teir N ISP, say sprint and ELI) vs. an end node. it is the end nodes, those small dialup ISPs (for eg), who have older routers with less resources that would benefit most from some degree of filtering or rx-aggregation or the knobs to do so. i suggest that it would be {near} impossible for a transit AS to do either rx filtering from peers (where filtering means /dev/null). loss of routes from filtering could easily result in unroutable prefixes should the resulting aggregate be withdrawn or one of the two contributing routes behind the aggregate become unreachable; in fact, the rx-router enjoys no resource benefits (in fact it is penilized) as for this problem to be avoided, the router must retain the contributing routes and consider these in recomputations; not to mention that should it be necessary to withdraw the aggregate and advert the specifics, there are at least 2 computations (advert valid specific, remove aggregate). hmm, could that be magnified as it trickles through secondary ASes or flaps? also, every AS at the same "level", if you consider "level" to be AS-hops as in the transit ASes between a src and dst AS, as in: N - 1239 - Z N - 2914 - Z 2914 and 1239 would have to do filtering and/or aggregation the same way, have the same routes, ???? to prevent loss wrt route selection for end nodes. otoh, for a small AS w/ 2 T1s, trying to turn bgp knobs to gain balance in either direction can be large and repetitive task. this proxy aggregation makes this even more difficult. ] ID - (SO, SN) - the same prefix from the same neighbors and the same ] origin AS ] ] 198.108.1.0/24 from 1 2 3 ] 198.108.1.0/24 from 1 11 3 ] ] Only one of these prefixes would be sent from AS 1. AS 1 would pass ] only the best route. However, there is a case where if AS 1 is ] peering with your network in multiple places and is not announcing ] their routes consistently, some of the receiving network's internal ] routers would show both of these paths in the RIB. there is nothing inconsistent about this. if AS 2 and 11 connect to two different routers within AS 1 and the routes are equal in all respects (wieght, lclprf, ...), AS 1 is going to avert the route it chooses as best; ie: the route whose next-hop is closest igp-wise. and, assuming the AS 1 doesnt not alter the route, all the routers in the ibgp mesh should have both prefixes in their RIB. imo, shoot this thing before it spawns. time might be better spent on defining more effective knobs for route selection than lcl pref, alternatives to traditional multi-homing.... what happened to ed kern and dianne's draft (or was it just a nanog presentation) on multihoming without an AS? what if 2 peering teir 1s were to assume an AS akin to rfc 2270 for which customers of these 2 teir 1s were to use and/or aggregates of the routes were origin this AS and specifics of were exchanged between the 2 teir 1s. eg: rfc2270 AS 5 teir 1 AS 1 teir 1 AS 2 aggregate 192.168.0.0/16 origin AS 5 announced by 1 and 2 AS 1 and 2 exchange specifics of the aggregate over their peering links. this allows reduction of the number of global prefixes and continues to allow AS 5 the same degree of redundancy given typical peering practices. otoh, it assumes AS 1 and 2 can enter into such a business agreement and remain cooperative; so maybe it is impossible. From ahuja at umich.edu Wed Mar 14 23:01:57 2001 From: ahuja at umich.edu (abha ahuja) Date: Wed, 14 Mar 2001 18:01:57 -0500 (EST) Subject: most current version In-Reply-To: <20010314130415.B10413@shrubbery.net> Message-ID: > the draft doesnt consider differences of effects from the POV of a > transit AS (ie: teir 1 or teir N ISP, say sprint and ELI) vs. an > end node. it is the end nodes, those small dialup ISPs (for eg), > who have older routers with less resources that would benefit most > from some degree of filtering or rx-aggregation or the knobs to do > so. i agree that the smaller guys with the least resources would want to reduce their load the most, they are the least likely to be able to do something like this. almost all of these aggregation techniques are only useful for sender-side. So, in general, it will reduce the amount of garbage sent between peers. rx-side aggregation is possible, but not in nearly as many situations from what i can tell... please feel free to discuss because maybe i am missing something. > i suggest that it would be {near} impossible for a transit AS to do > either rx filtering from peers (where filtering means /dev/null). loss > of routes from filtering could easily result in unroutable prefixes > should the resulting aggregate be withdrawn or one of the two contributing > routes behind the aggregate become unreachable; in fact, the rx-router > enjoys no resource benefits (in fact it is penilized) as for this problem > to be avoided, the router must retain the contributing routes and consider > these in recomputations; not to mention that should it be necessary to > withdraw the aggregate and advert the specifics, there are at least 2 > computations (advert valid specific, remove aggregate). hmm, could that > be magnified as it trickles through secondary ASes or flaps? hmmm... rx-side filtering is only possible if the next-hops are the same for 2 paths. if the next-hop AS/ip is the same for both, then it is possible to filter out a more specific without any loss of information. or am i missing what you are saying here? > also, every AS at the same "level", if you consider "level" to be AS-hops > as in the transit ASes between a src and dst AS, as in: > > N - 1239 - Z > N - 2914 - Z > > 2914 and 1239 would have to do filtering and/or aggregation the same > way, have the same routes, ???? to prevent loss wrt route selection for > end nodes. agreed. but, if the bgp rules are still followed, ie - you only advertize what you are using (special knobs aside) this shouldn't cause unreachability. > ] ID - (SO, SN) - the same prefix from the same neighbors and the same > ] origin AS > ] > ] 198.108.1.0/24 from 1 2 3 > ] 198.108.1.0/24 from 1 11 3 > ] > ] Only one of these prefixes would be sent from AS 1. AS 1 would pass > ] only the best route. However, there is a case where if AS 1 is > ] peering with your network in multiple places and is not announcing > ] their routes consistently, some of the receiving network's internal > ] routers would show both of these paths in the RIB. > > there is nothing inconsistent about this. if AS 2 and 11 connect to > two different routers within AS 1 and the routes are equal in all > respects (wieght, lclprf, ...), AS 1 is going to avert the route it > chooses as best; ie: the route whose next-hop is closest igp-wise. > and, assuming the AS 1 doesnt not alter the route, all the routers in > the ibgp mesh should have both prefixes in their RIB. you are correct. > what happened to ed kern and dianne's draft (or was it just a nanog > presentation) on multihoming without an AS? what if 2 peering teir 1s > were to assume an AS akin to rfc 2270 for which customers of these > 2 teir 1s were to use and/or aggregates of the routes were origin this > AS and specifics of were exchanged between the 2 teir 1s. eg: > > rfc2270 AS 5 > teir 1 AS 1 > teir 1 AS 2 > aggregate 192.168.0.0/16 origin AS 5 announced by 1 and 2 > > AS 1 and 2 exchange specifics of the aggregate over their peering > links. > > this allows reduction of the number of global prefixes and continues to > allow AS 5 the same degree of redundancy given typical peering practices. > otoh, it assumes AS 1 and 2 can enter into such a business agreement and > remain cooperative; so maybe it is impossible. is there a draft on this? definitely interested. -abha ;) From randy at psg.com Wed Mar 14 23:07:51 2001 From: randy at psg.com (Randy Bush) Date: Wed, 14 Mar 2001 15:07:51 -0800 Subject: most current version References: <20010314130415.B10413@shrubbery.net> Message-ID: > i agree that the smaller guys with the least resources would want to > reduce their load the most, they are the least likely to be able to do > something like this. almost all of these aggregation techniques are only > useful for sender-side. perhaps you've forgotten the idr draft on receivers sending filters to senders. now, think of what the push-back folk are talking about for ddos, and think of useless (to whom!) de-aggregation as a dos. randy From ahuja at umich.edu Wed Mar 14 23:10:49 2001 From: ahuja at umich.edu (abha ahuja) Date: Wed, 14 Mar 2001 18:10:49 -0500 (EST) Subject: most current version In-Reply-To: Message-ID: > > i agree that the smaller guys with the least resources would want to > > reduce their load the most, they are the least likely to be able to do > > something like this. almost all of these aggregation techniques are only > > useful for sender-side. > > perhaps you've forgotten the idr draft on receivers sending filters to > senders. ahh... yes. that would definitely help. > now, think of what the push-back folk are talking about for ddos, and think > of useless (to whom!) de-aggregation as a dos. :) From vijay at umbc.edu Wed Mar 14 23:08:12 2001 From: vijay at umbc.edu (Vijay Gill) Date: Wed, 14 Mar 2001 18:08:12 -0500 Subject: most current version In-Reply-To: Message-ID: On Wed, 14 Mar 2001, abha ahuja wrote: > i agree that the smaller guys with the least resources would want to > reduce their load the most, they are the least likely to be able to do > something like this. almost all of these aggregation techniques are only > useful for sender-side. So, in general, it will reduce the amount of Let them eat cake! > garbage sent between peers. rx-side aggregation is possible, but not in > nearly as many situations from what i can tell... please feel free to > discuss because maybe i am missing something. Most RX side bgp (from helping out a small regional) was done to reduce their cost to their primary transit provider (turning on peering with networks behind say, 701, would allow them to shortcut 701) and to provide a bgp feed to a few customers. Things like filtering everthing except _701_ and _1239_ and _1_ on various links were used to achieve a measure of traffic engineering on their links (outbound). They really could have gotten away with using a default out. FWIW From smd at clock.org Wed Mar 14 10:26:30 2001 From: smd at clock.org (smd at clock.org) Date: Wed, 14 Mar 2001 02:26:30 -0800 Subject: most current version Message-ID: <20010314102644Z27268-27329+2@cesium.clock.org> oh, i did miss new instructions, but they're very new. :-) i'll read the draft. Sean. From heas at shrubbery.net Thu Mar 15 00:28:43 2001 From: heas at shrubbery.net (john heasley) Date: Wed, 14 Mar 2001 16:28:43 -0800 Subject: most current version In-Reply-To: ; from randy@psg.com on Wed, Mar 14, 2001 at 03:07:51PM -0800 References: <20010314130415.B10413@shrubbery.net> Message-ID: <20010314162843.E8046@shrubbery.net> Wed, Mar 14, 2001 at 03:07:51PM -0800, Randy Bush: > > i agree that the smaller guys with the least resources would want to > > reduce their load the most, they are the least likely to be able to do > > something like this. almost all of these aggregation techniques are only > > useful for sender-side. > > perhaps you've forgotten the idr draft on receivers sending filters to > senders. > > now, think of what the push-back folk are talking about for ddos, and think > of useless (to whom!) de-aggregation as a dos. pointers, please. seems to me that the knobs already exist to kill smurf-like dos attacks; operators are just too damn lazy to use them. From heas at shrubbery.net Thu Mar 15 00:24:55 2001 From: heas at shrubbery.net (john heasley) Date: Wed, 14 Mar 2001 16:24:55 -0800 Subject: most current version In-Reply-To: ; from ahuja@umich.edu on Wed, Mar 14, 2001 at 06:01:57PM -0500 References: <20010314130415.B10413@shrubbery.net> Message-ID: <20010314162455.D8046@shrubbery.net> Wed, Mar 14, 2001 at 06:01:57PM -0500, abha ahuja: > > > the draft doesnt consider differences of effects from the POV of a > > transit AS (ie: teir 1 or teir N ISP, say sprint and ELI) vs. an > > end node. it is the end nodes, those small dialup ISPs (for eg), > > who have older routers with less resources that would benefit most > > from some degree of filtering or rx-aggregation or the knobs to do > > so. > > i agree that the smaller guys with the least resources would want to > reduce their load the most, they are the least likely to be able to do > something like this. almost all of these aggregation techniques are only > useful for sender-side. So, in general, it will reduce the amount of > garbage sent between peers. rx-side aggregation is possible, but not in > nearly as many situations from what i can tell... please feel free to > discuss because maybe i am missing something. > > > > i suggest that it would be {near} impossible for a transit AS to do > > either rx filtering from peers (where filtering means /dev/null). loss > > of routes from filtering could easily result in unroutable prefixes > > should the resulting aggregate be withdrawn or one of the two contributing > > routes behind the aggregate become unreachable; in fact, the rx-router > > enjoys no resource benefits (in fact it is penilized) as for this problem > > to be avoided, the router must retain the contributing routes and consider > > these in recomputations; not to mention that should it be necessary to > > withdraw the aggregate and advert the specifics, there are at least 2 > > computations (advert valid specific, remove aggregate). hmm, could that > > be magnified as it trickles through secondary ASes or flaps? > > hmmm... rx-side filtering is only possible if the next-hops are the same > for 2 paths. if the next-hop AS/ip is the same for both, then it is > possible to filter out a more specific without any loss of information. > or am i missing what you are saying here? if i produce 0/23 out of 0/24 and 1/24, i have to retain both of those /24's so if either is withdrawn i know the aggregate is crap and i have to tell my neighbor. > > also, every AS at the same "level", if you consider "level" to be AS-hops > > as in the transit ASes between a src and dst AS, as in: > > > > N - 1239 - Z > > N - 2914 - Z > > > > 2914 and 1239 would have to do filtering and/or aggregation the same > > way, have the same routes, ???? to prevent loss wrt route selection for > > end nodes. > > agreed. but, if the bgp rules are still followed, ie - you only advertize > what you are using (special knobs aside) this shouldn't cause > unreachability. no, the end nodes loose information. eg: 1239 has a policy to tx-aggregate to their customers and 2914 does not. which route(s) end up in the fib and which are used for forwarding? > > what happened to ed kern and dianne's draft (or was it just a nanog > > presentation) on multihoming without an AS? what if 2 peering teir 1s > > were to assume an AS akin to rfc 2270 for which customers of these > > 2 teir 1s were to use and/or aggregates of the routes were origin this > > AS and specifics of were exchanged between the 2 teir 1s. eg: > > > > rfc2270 AS 5 > > teir 1 AS 1 > > teir 1 AS 2 > > aggregate 192.168.0.0/16 origin AS 5 announced by 1 and 2 > > > > AS 1 and 2 exchange specifics of the aggregate over their peering > > links. > > > > this allows reduction of the number of global prefixes and continues to > > allow AS 5 the same degree of redundancy given typical peering practices. > > otoh, it assumes AS 1 and 2 can enter into such a business agreement and > > remain cooperative; so maybe it is impossible. > > is there a draft on this? definitely interested. ed would have to comment. randy, weren't you involved? you arranged to land that t1 from their lab in vienna and we loaned them a prefix to play with. From randy at psg.com Thu Mar 15 00:45:21 2001 From: randy at psg.com (Randy Bush) Date: Wed, 14 Mar 2001 16:45:21 -0800 Subject: most current version References: <20010314130415.B10413@shrubbery.net> <20010314162455.D8046@shrubbery.net> Message-ID: > if i produce 0/23 out of 0/24 and 1/24, i have to retain both of those /24's > so if either is withdrawn i know the aggregate is crap and i have to tell > my neighbor. not necessarily. i am your receiving neighbor, and i may not be willing to pay the cost so i can reach some of your base when your network is farbled. why should the cost of your unreliability be passed on to me? > ed would have to comment. randy, weren't you involved? nope. it's hard enough to do things straight. i leave kink to you southerners. randy From heas at shrubbery.net Thu Mar 15 23:57:24 2001 From: heas at shrubbery.net (john heasley) Date: Thu, 15 Mar 2001 15:57:24 -0800 Subject: most current version In-Reply-To: ; from randy@psg.com on Wed, Mar 14, 2001 at 04:45:21PM -0800 References: <20010314130415.B10413@shrubbery.net> <20010314162455.D8046@shrubbery.net> Message-ID: <20010315155723.J8046@shrubbery.net> Wed, Mar 14, 2001 at 04:45:21PM -0800, Randy Bush: > > if i produce 0/23 out of 0/24 and 1/24, i have to retain both of those /24's > > so if either is withdrawn i know the aggregate is crap and i have to tell > > my neighbor. > > not necessarily. i am your receiving neighbor, and i may not be willing to > pay the cost so i can reach some of your base when your network is farbled. > why should the cost of your unreliability be passed on to me? b/c you have a business obligation to your customers. if a prefix is reachable w/o aggregation, it should continue to be reachable in the case that aggregation is no longer valid. what happens if route that was once contributor to an aggregate changes legitimately? do i now have to clear sessions in order to regain the lost information, or do i have to rely upon my neighbor supporting 'remote soft-clear' feature of ORF? From joel at longsys.com Thu Mar 15 23:43:12 2001 From: joel at longsys.com (Joel M. Halpern) Date: Thu, 15 Mar 2001 18:43:12 -0500 Subject: Initial taxonomy draft comment Message-ID: <4.2.2.20010315184156.00c406f0@localhost> I was reading the taxonomy, and there appeared to be an unstated assumption in the description of "covered" cases. If I am reading the document correctly, when AS (holding a long prefix, wants to multi-home with an address from AS2's block, you would like to see: 198.108.0.0/16 from 7 2 198.108.1.0/24 from 1 11 3 rather than having AS2 advertise 198/108.1.0/24 as well. In fact, early on you say that such an advertisement should have been aggregated by AS2. This seems to mean that remote AS are to treat AS2s announcement as providing comparable coverage to that of AS3 itself. [The assumption I am concerned about.] This would seem to have two implications: Firstly, this is a major change from the routing assumptions to date. We currently assume that a longer match is "better". If there were no loss of functionality, removing this assumption might well be good, but should be stated. Secondly, this would mean that there would be no way for AS2 to arrange that the traffic for AS3 did NOT come to it if the connection between AS2 and AS3 went down. This seems to undermine one of the basic purposes of multi-homing. Have I misread the intentions of the document? They seem pretty clearly stated in the taxonomy section on CD - (SO, DN) where it states that AS2 should aggregate. Yours, Joel M. Halpern From randy at psg.com Fri Mar 16 00:36:42 2001 From: randy at psg.com (Randy Bush) Date: Thu, 15 Mar 2001 16:36:42 -0800 Subject: most current version References: <20010314130415.B10413@shrubbery.net> <20010314162455.D8046@shrubbery.net> <20010315155723.J8046@shrubbery.net> Message-ID: >>> if i produce 0/23 out of 0/24 and 1/24, i have to retain both of those >>> /24's so if either is withdrawn i know the aggregate is crap and i have >>> to tell my neighbor. >> not necessarily. i am your receiving neighbor, and i may not be willing >> to pay the cost so i can reach some of your base when your network is >> farbled. why should the cost of your unreliability be passed on to me? > b/c you have a business obligation to your customers. if a prefix is > reachable w/o aggregation, it should continue to be reachable in the case > that aggregation is no longer valid. what happens if route that was once > contributor to an aggregate changes legitimately? do i now have to > clear sessions in order to regain the lost information, or do i have to > rely upon my neighbor supporting 'remote soft-clear' feature of ORF? let is not dwell on the tricks, shortcomings, and kink of current vendors' products. and let's not drill into where current protocols might not support exactly what we want. the purpose here is to discover and discuss what is it we need to get through the next years of bgp+ reliance until we can get a scalable egp. randy From dmm at maoz.com Fri Mar 16 02:25:44 2001 From: dmm at maoz.com (David Meyer) Date: Thu, 15 Mar 2001 18:25:44 -0800 Subject: a few comments on draft-ptomaine-taxonomy-00.txt Message-ID: <200103160225.f2G2Pi900954@mos-eisley.cisco.com> First, the draft is a very nice start and gives us something around which to frame discussion. So thank you for doing that work. A few comments: (i). While I believe that most of us know what is meant by "route pollution", it seems reasonable to define precisely what is and what is not pollution in a document like this. (ii). How closely is the taxonomy tied to current BGP bestpath semantics? It seems that some of the examples are; however, the the classification does not appear to depend on it (which is a good thing). Dave From heas at shrubbery.net Fri Mar 16 02:29:49 2001 From: heas at shrubbery.net (john heasley) Date: Thu, 15 Mar 2001 18:29:49 -0800 Subject: archive In-Reply-To: ; from randy@psg.com on Thu, Mar 15, 2001 at 04:37:10PM -0800 References: <20010315155916.K8046@shrubbery.net> Message-ID: <20010315182949.I8046@shrubbery.net> Thu, Mar 15, 2001 at 04:37:10PM -0800, Randy Bush: > >> how may the archive of this list be accessed? > > i have not been maintaining one, but i could certainly do so and > > attempt to populate it with the messages rx'd thus far. > > please. ieft lists are publicly archived. thanks. > > randy From: Majordomo at shrubbery.net Subject: Majordomo results >>>> index ptomaine total 72 -rw-rw-r-- 1 majordom majordom 19224 Mar 16 02:09 ptomaine.20010314 -rw-rw-r-- 1 majordom majordom 12343 Mar 16 02:11 ptomaine.20010315 -rw-rw-r-- 1 majordom majordom 3625 Mar 16 02:26 ptomaine.20010316 From joel at longsys.com Mon Mar 19 16:05:55 2001 From: joel at longsys.com (Joel M. Halpern) Date: Mon, 19 Mar 2001 11:05:55 -0500 Subject: Taxonomy Draft information In-Reply-To: <4.2.2.20010315184156.00c406f0@localhost> Message-ID: <4.2.2.20010319105954.00bac910@localhost> The current taxonomy draft seem to occasionally drift into being a recommendations document. At one point it says that an AS "should be able to aggregate". Later on it states that an AS "should aggregate" information which is not aggregated in current practice. The current document (without these recommendations) seems to be a very useful guide to getting more information out of the data collection that is going on, and providing for a common understanding of the data. I believe that recommendations for future behavior would be best served by capturing them in some other document. Yours, Joel M. Halpern PS: The document occasionally talk about different information flowing between peers vs customers vs transits. While such distinctions are meaningful in many contexts, it does not appear to help this document noticeably. From henk at ripe.net Tue Mar 20 19:10:33 2001 From: henk at ripe.net (Henk Uijterwaal (RIPE-NCC)) Date: Tue, 20 Mar 2001 20:10:33 +0100 (CET) Subject: No subject Message-ID: susbscribe henk at ripe.net ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal at ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ As long as you don't tell your friends how I played the hand, then I won't tell my friends how you defended it. (Anonymous) From smd at clock.org Tue Mar 20 19:58:46 2001 From: smd at clock.org (smd at clock.org) Date: Tue, 20 Mar 2001 11:58:46 -0800 Subject: proxy-aggregation of geoff huston Message-ID: <20010320195855Z27502-9811+7@cesium.clock.org> As mentioned in the ptomaine WG... ip as-path access-list 14 permit _1221_ route-map TELSTRA permit 5 descr proxy-aggregate the lazy australian who says it can't be done match as-path 14 router bgp 1880 aggregate-address 192.36.0.0 255.255.0.0 as-set suppress-map TELSTRA ^Z Network Next Hop Metric LocPrf Weight Path *> 192.36.0.0/16 0.0.0.0 100 32768 {1257,2874,702,2836,1755,13297,1653,2831,6782,5556,2833,8434,8674,1800,2865,5574,2841} ? * 192.36.1.0 198.67.142.173 90 0 1800 1257 i * i 194.68.128.21 100 0 1257 i * 192.108.199.209 100 0 1883 1800 1257 i *> 194.71.10.3 0 1257 i * 194.68.132.21 0 3220 1257 i * 192.36.147.30 100 0 1755 1257 1257 i * 192.36.147.11 0 1800 1257 i * 192.36.147.8 0 1800 1257 i * 192.36.147.1 0 1877 1257 i * 192.36.3.0 198.67.142.173 90 0 1800 1239 5511 2874 ? * i 194.68.128.17 100 0 2874 ? * 192.108.199.209 100 0 1883 2874 ? * 194.71.10.3 0 1257 2874 ? * 194.68.132.17 0 3220 2874 ? *> 194.68.132.17 0 2874 ? * 192.36.147.30 100 0 1755 5511 2874 ? * 192.36.147.11 0 1800 1239 5511 2874 ? * 192.36.147.8 0 1800 1239 5511 2874 ? ... From smd at clock.org Tue Mar 20 20:07:37 2001 From: smd at clock.org (smd at clock.org) Date: Tue, 20 Mar 2001 12:07:37 -0800 Subject: proxy-aggregation commentary Message-ID: <20010320200742Z27502-9813+15@cesium.clock.org> 1. "lazy" is unfair and was meant tongue-in-cheek, because gih clearly is not. it was "australian" nonplural, not an attack on TELSTRA it did provoke some thinking in his head though :-) 2. that said, what this means it that downstreams of stupi WILL NOT SEE the subnets of 192.36/16 iff the subnet passed through AS 1221 downstreams (if they are NOT in the AS SET) will see the aggregate and non-AS 1221 more specifics Sean. From m.d.ford at talk21.com Tue Mar 20 20:14:09 2001 From: m.d.ford at talk21.com (m.d.ford at talk21.com) Date: Tue, 20 Mar 2001 20:14:09 GMT Subject: subscribe ptomaine Message-ID: <20010320201442.PCDY9208.t21mta01-app.talk21.com@t21mtaV-lrs> subscribe ptomaine __________________________ 'Every day, computers make human beings easier to use.' -------------------- talk21 your FREE portable and private address on the net at http://www.talk21.com From gih at telstra.net Tue Mar 20 20:38:38 2001 From: gih at telstra.net (Geoff Huston) Date: Wed, 21 Mar 2001 07:38:38 +1100 Subject: proxy-aggregation commentary In-Reply-To: <20010320200742Z27502-9813+15@cesium.clock.org> Message-ID: <4.3.2.7.2.20010321073030.00b3a640@localhost> At 3/21/01 07:07 AM, smd at clock.org wrote: >1. "lazy" is unfair and was meant tongue-in-cheek, because gih clearly is not. > it was "australian" nonplural, not an attack on TELSTRA > > it did provoke some thinking in his head though :-) > >2. that said, what this means it that downstreams of stupi WILL NOT SEE > the subnets of 192.36/16 iff the subnet passed through AS 1221 > > downstreams (if they are NOT in the AS SET) will see the aggregate > and non-AS 1221 more specifics thanks Sean, 2. is a really interesting point. The intent of the slides (sent to Abha - I can't web em up for a while) was to say that policies, as expressed today in specific advertisements, do have a 'use by' attribute, and that there is no point to splash local policies globally, but local policies are also not just as close as NO EXPORT, and are not an AS TTL. The 'use by' is harder to express, but its attempting to say that the specifics do NOT need to be global, but can be aggregated into a larger generic policy at "some distance away'. All vague terms I admit, but this example of yours shows that there are good mechanmisms to remote absorb local policy. Now comes the more interesting bit - is there a way for the local origin AS to trigger this remote policy absorbtion through a community attribute of some form or fashion, or through a similar signalling mechanism. i.e. good technique Sean, thanks for pointing it out. Now going through my head is the question of how to work out how to use it in a way that helps us learn about how to express policy within the inter domain space. If we can do that we are well past simple proxy aggregation and well toward a way of expressing policy as a qualification on an underlying connectivity. Geoff From roll at stupi.se Tue Mar 20 21:47:08 2001 From: roll at stupi.se (Peter Lothberg) Date: Tue, 20 Mar 2001 21:47:08 CET Subject: proxy-aggregation of geoff huston In-Reply-To: Your message of Tue, 20 Mar 2001 11:58:46 -0800 Message-ID: > As mentioned in the ptomaine WG... > > ip as-path access-list 14 permit _1221_ > > route-map TELSTRA permit 5 > descr proxy-aggregate the lazy australian who says it can't be done > match as-path 14 > > router bgp 1880 > aggregate-address 192.36.0.0 255.255.0.0 as-set suppress-map TELSTRA > > ^Z > > Network Next Hop Metric LocPrf Weight Path > *> 192.36.0.0/16 0.0.0.0 100 32768 {1257,2874,702,2836,1755,13297,1653,2831,6782,5556,2833,8434,8674,1800,2865,5574,2841} ? > * 192.36.1.0 198.67.142.173 90 0 1800 1257 i > * i 194.68.128.21 100 0 1257 i > * 192.108.199.209 100 0 1883 1800 1257 i > *> 194.71.10.3 0 1257 i > * 194.68.132.21 0 3220 1257 i > * 192.36.147.30 100 0 1755 1257 1257 i > * 192.36.147.11 0 1800 1257 i > * 192.36.147.8 0 1800 1257 i > * 192.36.147.1 0 1877 1257 i > * 192.36.3.0 198.67.142.173 90 0 1800 1239 5511 2874 ? > * i 194.68.128.17 100 0 2874 ? > * 192.108.199.209 100 0 1883 2874 ? > * 194.71.10.3 0 1257 2874 ? > * 194.68.132.17 0 3220 2874 ? > *> 194.68.132.17 0 2874 ? > * 192.36.147.30 100 0 1755 5511 2874 ? > * 192.36.147.11 0 1800 1239 5511 2874 ? > * 192.36.147.8 0 1800 1239 5511 2874 ? > ... > But, problem with them is what the are doing is traffic engineering to the third hops behind their transits. That s why they need the deagreggated routes. -P From mccreary at pch.net Tue Mar 20 22:19:21 2001 From: mccreary at pch.net (mccreary at pch.net) Date: Tue, 20 Mar 2001 15:19:21 -0700 Subject: What problem should we be working on? Message-ID: <200103202219.f2KMJLH62930@xoanon.colorado.edu> Van's comments in the WG meeting are worth reiterating a bit. Router resources such as memory size and CPU speed scale like Moore's Law, and so growth in the resources required in core routers are really only of concern if they are growing faster than the available resources. We have seen the number of paths grow by ~2x over the past three years, and presumably the amount of memory required in core routers has grown proportonately. Moore's Law suggests the available memory will continue to grow much faster than this, doubling in capacity every 18-24 months. This suggests the current rate of growth is manageable, and in fact we can tolerate a significantly higher rate of compound growth. We can make similar measurements of the rate of growth in CPU load on core routers to see if the growth rate is also slower than Moore's Law. Does anyone have data that might allow us to determine this growth rate? As Geoff pointed out, there are strong economic forces that are pushing us towards finer grained policy in the core routing table. No matter what we do, we will have to cope with very large core routing tables until a replacement for BGP4 can be deployed. If the amount of resources consumed in the core routers is not a problem, then we should be spending more time identifying the factors that will really cause us problems in the future, and designing schemes to deal with them. Since we know from Craig and Abha's work that convergence times grow with denser interconnectivity, it is likely that the biggest problem we will face in the near future is increasing convergence times. Do we know how proxy aggregation will affect convergence times? Naively it seems that proxy aggregation has a chance of helping, since it might hide some of the finer-grained routing changes from ASes downstream of the aggregator. On the other hand, it might also increase route volatility by coupling transitions in separate routes together. For example, if the aggregate must be withdrawn whenever one of the aggregated routes is withdrawn, then this seems to be the most likely outcome. We need to try and determine which of these outcomes is more likely to occur. -- Sean McCreary mccreary at pch.net From ahuja at umich.edu Tue Mar 20 22:30:29 2001 From: ahuja at umich.edu (abha ahuja) Date: Tue, 20 Mar 2001 17:30:29 -0500 (EST) Subject: What problem should we be working on? In-Reply-To: <200103202219.f2KMJLH62930@xoanon.colorado.edu> Message-ID: Hi Sean... [...] > We can make similar measurements of the rate of growth in CPU load on core > routers to see if the growth rate is also slower than Moore's Law. Does > anyone have data that might allow us to determine this growth rate? I think Vijay's slides from NANOG might include this? > As Geoff pointed out, there are strong economic forces that are pushing us > towards finer grained policy in the core routing table. No matter what we > do, we will have to cope with very large core routing tables until a > replacement for BGP4 can be deployed. If the amount of resources consumed in > the core routers is not a problem, then we should be spending more time > identifying the factors that will really cause us problems in the future, and > designing schemes to deal with them. Since we know from Craig and Abha's > work that convergence times grow with denser interconnectivity, it is likely > that the biggest problem we will face in the near future is increasing > convergence times. Right. Most definitely. Keep in mind that there are multiple efforts occurring in parallel here. There is the short term fixes to the BGP protocol itself in IDR, the middle frameworking and possible new protocol things and the longer range stuff for a new routing architecture that goes on in the IRTF. The ptomaine stuff is definitely aimed at the immediate need (or maybe in a few months out) to help us deal with the operational issues. But, I agree, we all need to understand exactly what the factors are with regard to growth and scaling. > Do we know how proxy aggregation will affect convergence times? > Naively it seems that proxy aggregation has a chance of helping, since > it might hide some of the finer-grained routing changes from ASes > downstream of the aggregator. On the other hand, it might also > increase route volatility by coupling transitions in separate routes > together. For example, if the aggregate must be withdrawn whenever > one of the aggregated routes is withdrawn, then this seems to be the > most likely outcome. We need to try and determine which of these > outcomes is more likely to occur. Most definitely. -abha ;) From vijay at umbc.edu Tue Mar 20 22:36:56 2001 From: vijay at umbc.edu (Vijay Gill) Date: Tue, 20 Mar 2001 17:36:56 -0500 Subject: What problem should we be working on? In-Reply-To: Message-ID: On Tue, 20 Mar 2001, abha ahuja wrote: > > Hi Sean... > > [...] > > > We can make similar measurements of the rate of growth in CPU load on core > > routers to see if the growth rate is also slower than Moore's Law. Does > > anyone have data that might allow us to determine this growth rate? > > I think Vijay's slides from NANOG might include this? Actually Dr. Li's slides are the ones you really want. http://www.nanog.org/mtg-0102/witt.html /vijay From mccreary at pch.net Wed Mar 21 00:07:28 2001 From: mccreary at pch.net (mccreary at pch.net) Date: Tue, 20 Mar 2001 17:07:28 -0700 Subject: What problem should we be working on? In-Reply-To: Your message of "Tue, 20 Mar 2001 17:30:29 EST." Message-ID: <200103210007.f2L07SH64131@xoanon.colorado.edu> Abha wrote: [...] >I think Vijay's slides from NANOG might include this? Tony Li's slide set (available from http://www.nanog.org/mtg-0102/witt.html) makes the point about storage requirements very well. He also issues the very pertinent warning that the growth rate is increasing and will eventually surpass the growth rate of Moore's Law. I think we can consider this to be a longer-term problem though, and defer its solution until deployment of a new inter-domain routing protocol that supports scoped advertisements :-) However, he doesn't present any analysis of how quickly CPU load is changing in core routers. This measurement may be difficult to interpret because of load changes due to other processes not related to inter-domain routing, and the waters may be further muddied by incremental deployment of the BGP implementation improvements you and Craig have recommended. But I thought I'd ask anyway... -- Sean McCreary mccreary at pch.net From matthew.ford at bt.com Wed Mar 21 13:41:10 2001 From: matthew.ford at bt.com (matthew.ford at bt.com) Date: Wed, 21 Mar 2001 13:41:10 -0000 Subject: subscribe ptomaine Message-ID: subscribe ptomaine From jonathan.2.stevens at bt.com Wed Mar 21 13:41:16 2001 From: jonathan.2.stevens at bt.com (jonathan.2.stevens at bt.com) Date: Wed, 21 Mar 2001 13:41:16 -0000 Subject: No subject Message-ID: subscribe ptomaine From ahuja at umich.edu Wed Mar 21 14:43:51 2001 From: ahuja at umich.edu (abha ahuja) Date: Wed, 21 Mar 2001 09:43:51 -0500 (EST) Subject: proxy-aggregation commentary In-Reply-To: <4.3.2.7.2.20010321073030.00b3a640@localhost> Message-ID: > 2. is a really interesting point. The intent of the slides (sent to > Abha - I can't web em up for a while) was to say that policies, Until I find a better place to put them, here is a pointer to both Geoff and my slides... http://www.merit.edu/~ahuja/ptomaine-bof/ -abha ;) From rja at inet.org Wed Mar 21 14:22:36 2001 From: rja at inet.org (RJ Atkinson) Date: Wed, 21 Mar 2001 09:22:36 -0500 Subject: What problem should we be working on? In-Reply-To: <200103210007.f2L07SH64131@xoanon.colorado.edu> References: Message-ID: <5.0.2.1.2.20010321091633.009fd040@10.30.15.2> IMHO, the longer-term issue is not strictly a "resource" issue, but rather one of how far a path-vector algorithm scales while still having reasonably palatable global end-to-end convergence time. That noted, the longer-term issue is being handled in the IRTF Routing Research Group (and perhaps in multi6), rather than in Ptomaine. IMHO, we all need to try to sort appropriately among the several lists/groups trying to ensure we don't hit the wall. Cheers, Ran rja at inet.org From jabley-ietf at automagic.org Fri Mar 23 04:31:56 2001 From: jabley-ietf at automagic.org (Joe Abley) Date: Thu, 22 Mar 2001 23:31:56 -0500 Subject: a crude method of limiting long-prefix propagation Message-ID: <20010322233156.K28573@buddha.home.automagic.org> http://www.automagic.org/~jabley/draft-jabley-edge-policy-propagation-control-00.txt This is something that came out of a couple of conversations in the bar. Hopefully I captured some of the salient points before the vodka kicked in. I thought this might qualify as a possible short-term measure to reduce prefix bloat, hence ptomaine. Someone set me up the flame. Network Working Group J. Abley Internet-Draft Metromedia Fiber Network Inc. Expires: September 20, 2001 March 22, 2001 Edge Policy Propagation Control draft-jabley-edge-policy-propagation-control-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 20, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract There is a requirement for some multi-homed sites to influence the path selected by autonomous systems beyond those that are immediately adjacent. One of the few generic mechanisms available is to deaggregate and advertise long component prefixes to the network, since there can be some confidence that the longest prefix will be used, regardless of other local policy such as local preference. Most ASes exhibit liberal route import policy with respect to prefix length, which facilitates this technique. Unfortunately, although the deaggregated prefix set may be required Abley Expires September 20, 2001 [Page 1] Internet-Draft Edge Policy Propagation Control March 2001 to be installed in only a few targeted ASes for the aims of the origin to be achieved, there is no reliable mechanism to limit the propagation of the prefixes. This contributes to prefix bloat in the default-free zone, which is a concern. This draft describes a community-based convention which might be used to limit propagation of long prefixes to those ASes where they are required to meet the edge policy for cases where the target ASes are no further than one AS hop away from the transit AS. Abley Expires September 20, 2001 [Page 2] Internet-Draft Edge Policy Propagation Control March 2001 1. Introduction There is a requirement for some multi-homed sites to influence the path selected by autonomous systems beyond those that are immediately adjacent. One of the few generic mechanisms available is to deaggregate and advertise long component prefixes to the network, since there can be some confidence that the longest prefix will be used, regardless of other local policy such as local preference. Most ASes exhibit liberal route import policy with respect to prefix length, which facilitates this technique. Unfortunately, although the deaggregated prefix set may be required to be installed in only a few targeted ASes for the aims of the origin to be achieved, there is no reliable mechanism to limit the propagation of the prefixes. This contributes to prefix bloat in the default-free zone, which is a concern. Abley Expires September 20, 2001 [Page 3] Internet-Draft Edge Policy Propagation Control March 2001 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Abley Expires September 20, 2001 [Page 4] Internet-Draft Edge Policy Propagation Control March 2001 3. Edge Policy Propagation Convention 3.1 At the Edge An edge site deaggregates its advertisements according to the required differential policy. Aggregate prefixes are advertised as normal; long prefixes are advertised towards particular transit ASes tagged with community attributes which define their scope: EPPC_ALOW:ME this prefix should be handled according to the convention described in this document; ME is the ASN of the first transit AS. EPPC_ALLOW:A It is desirable that this prefix should propagate as far as AS A. EPPC_ALLOW is some 16-bit quantity, well-known amongst the community of operators who cooperate according to this convention. It should be chosen from the private-use range of ASNs specified in [2]. 3.2 Towards the Other Edge ASes which support this convention must include an additional clause in their advertisement policy to all peer ASes, as follows: o If the community attribute EPPC_ALLOW:ME is present, and EPPC_ALLOW:YOU is not present, then AS ME should suppress the advertisement towards AS YOU. o If the community attribute EPPC_ALLOW:ME is present, and EPPC_ALLOW:YOU is also present, then AS ME should advertise the prefix towards AS YOU with the no-export well-known attribute. Abley Expires September 20, 2001 [Page 5] Internet-Draft Edge Policy Propagation Control March 2001 4. Commentary 4.1 Related Work Many ASes have existing policy which provides this functionality. However, there is little consistency in the policy knobs available to customers from different providers. Widespread adoption of a consistent set of base bells and whistles might result in customers using them. 4.2 Limitations This mechanism only allows an edge site to reach one AS further into the network. The ability to reach further and still be constrained may also be useful. However, where the edge AS is motivated by the desire to perform coarse traffic engineering to prominent ASNs, which participate in a dense mesh of peering in the DFZ, it is not unreasonable to think that this approach might be sufficient for a significant number of edge networks to express their policy. Abley Expires September 20, 2001 [Page 6] Internet-Draft Edge Policy Propagation Control March 2001 5. Example Consider the following internetwork: +------+ +-----+ AS B +-----+ | +---+--+ | +---+--+ | +--+---+ | AS A | | | AS D | +---+--+ | +--+---+ | +---+--+ | +-----+ AS C +-----+ +---+--+ | +---+--+ | AS E | +------+ AS A exchanges a large volume of traffic with AS D, but is unable to peer with AS D directly. Their policy requirement is that inbound traffic from AS D should be split between through their connections to AS B and AS C. The networks operated by AS A are completely described by the aggregate 172.16.0.0/16. AS A determines that 172.16.0.0/17 and 172.16.128.0/17 are each responsible for sinking approximately half the inbound traffic from AS D. AS A therefore makes the following advertisements: o To AS B, announce 172.16.0.0/16 with no community string attributes, and 172.16.0.0/17 with the community attributes EPPC_ALLOW:B and EPPC_ALLOW:D. o To AS C, announce 172.16.0.0/16 with no community string attributes, and 172.16.128.0/17 with the community attributes EPPC_ALLOW:C and EPPC_ALLOW:D. AS B and AS C both accept the prefixes advertised to them. They advertise 172.16.0.0/16 to all peers, but only advertise the longer- prefix routes to AS D, since EPPC_ALLOW:B identifies the prefix as directed edge policy, and the only corresponding policy indicator present is EPPC_ALLOW:D. The long prefixes are advertised to AS D with the no-export community set, and hence will not propagate beyond AS D. The result is that the long prefix routes only propagate as far as AS D: AS E, for example, receives the aggregate 172.16.0.0/16 only. Abley Expires September 20, 2001 [Page 7] Internet-Draft Edge Policy Propagation Control March 2001 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996. [3] Huston, G., "Analyzing the Internet's BGP Routing Table", January 2001. Author's Address Joe Abley Metromedia Fiber Network Inc. 2204 Pembroke Court Burlington, ON L7P 3X8 Canada Phone: +1 905 319 9064 EMail: jabley at mfnx.net Abley Expires September 20, 2001 [Page 8] Internet-Draft Edge Policy Propagation Control March 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Abley Expires September 20, 2001 [Page 9] From mccreary at pch.net Fri Mar 23 06:37:44 2001 From: mccreary at pch.net (mccreary at pch.net) Date: Thu, 22 Mar 2001 23:37:44 -0700 Subject: a crude method of limiting long-prefix propagation In-Reply-To: Your message of "Thu, 22 Mar 2001 23:31:56 EST." <20010322233156.K28573@buddha.home.automagic.org> Message-ID: <200103230637.f2N6biH01190@xoanon.colorado.edu> You wrote: >http://www.automagic.org/~jabley/draft-jabley-edge-policy-propagation-control- >00.txt > >This is something that came out of a couple of conversations in the bar. >Hopefully I captured some of the salient points before the vodka kicked >in. > >I thought this might qualify as a possible short-term measure to reduce >prefix bloat, hence ptomaine. With a small change in semantics, it seems like this scheme is sufficient to support restricted announcement of any route to an explicit set of ASes. Just change the meaning of EPPC_ALOW:ASN a little so it indicates `advertiseable to', so that a participating AS will only advertise this route to a peer if the proper community attribute appears in the route. This scheme has the disadvantage that it requires all ASes in the region to support this method for indicating a scoped advertisement, rather than just those immediately adjacent to the origin AS. However, it also adds the ability to support arbitrarily shaped regions for limited distribution of specifics. The real question is whether any ISP thinks this is compatible with their current traffic engineering efforts. Any solution requiring significant amounts of inter-provider cooperation will need to demonstrate clear benefits for all parties involved, and I can't think of a compelling reason why an AS 2 or more hops from the origin AS would want to support remote manipulation of their transit traffic (in the general case, at least). -- Sean McCreary mccreary at pch.net From jabley-ietf at automagic.org Fri Mar 23 07:30:17 2001 From: jabley-ietf at automagic.org (Joe Abley) Date: Fri, 23 Mar 2001 02:30:17 -0500 Subject: a crude method of limiting long-prefix propagation In-Reply-To: <200103230637.f2N6biH01190@xoanon.colorado.edu>; from mccreary@pch.net on Thu, Mar 22, 2001 at 11:37:44PM -0700 References: <20010322233156.K28573@buddha.home.automagic.org> <200103230637.f2N6biH01190@xoanon.colorado.edu> Message-ID: <20010323023017.N28573@buddha.home.automagic.org> On Thu, Mar 22, 2001 at 11:37:44PM -0700, mccreary at pch.net wrote: > With a small change in semantics, it seems like this scheme is sufficient to > support restricted announcement of any route to an explicit set of ASes. Just > change the meaning of EPPC_ALOW:ASN a little so it indicates `advertiseable > to', so that a participating AS will only advertise this route to a peer if > the proper community attribute appears in the route. Yup. I already piped the -00 draft through asp and derived something very similar. The following draft does not contain the one-AS-hop limitation, and includes sample config for IOS and JUNOS. http://www.automagic.org/~jabley/draft-jabley-edge-policy-propagation-control-01.txt As suggested by Curtis, Ben is plugging the basic idea encompassed in this mechanism into a new bgp attribute, as an alternative approach to using community strings. Joe Network Working Group J. Abley Internet-Draft Metromedia Fiber Network Inc. Expires: September 21, 2001 March 23, 2001 Edge Policy Propagation Control draft-jabley-edge-policy-propagation-control-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 21, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract There is a requirement for some multi-homed sites to influence the path selected by autonomous systems beyond those that are immediately adjacent. One of the few generic mechanisms available is to deaggregate and advertise long component prefixes to the network, since there can be some confidence that the longest prefix will be used, regardless of other local policy such as local preference. Most ASes exhibit liberal route import policy with respect to prefix length, which facilitates this technique. Unfortunately, although the deaggregated prefix set may be required Abley Expires September 21, 2001 [Page 1] Internet-Draft Edge Policy Propagation Control March 2001 to be installed in only a few targeted ASes for the aims of the origin to be achieved, there is no reliable mechanism to limit the propagation of the prefixes. This contributes to prefix bloat in the default-free zone, which is a concern. This draft describes a community-based convention which might be used to limit propagation of long prefixes to those ASes where they are required. Abley Expires September 21, 2001 [Page 2] Internet-Draft Edge Policy Propagation Control March 2001 1. Introduction There is a requirement for some multi-homed sites to influence the path selected by autonomous systems beyond those that are immediately adjacent. One of the few generic mechanisms available is to deaggregate and advertise long component prefixes to the network, since there can be some confidence that the longest prefix will be used, regardless of other local policy such as local preference. Most ASes exhibit liberal route import policy with respect to prefix length, which facilitates this technique. Unfortunately, although the deaggregated prefix set may be required to be installed in only a few targeted ASes for the aims of the origin to be achieved, there is no reliable mechanism to limit the propagation of the prefixes. This contributes to prefix bloat in the default-free zone, which is a concern. Abley Expires September 21, 2001 [Page 3] Internet-Draft Edge Policy Propagation Control March 2001 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Abley Expires September 21, 2001 [Page 4] Internet-Draft Edge Policy Propagation Control March 2001 3. Edge Policy Propagation Convention 3.1 At the Edge An edge site deaggregates its advertisements according to the required fine-grain policy. Aggregate prefixes are advertised as normal; long prefixes are advertised tagged with community attributes which define their scope: EPPC_ALLOW:0 -- this prefix should be handled according to the convention described in this document. EPPC_ALLOW:A -- it is desirable that this prefix should propagate to AS A. Multiple communities of the form EPPC_ALLOW:A may be present to define propagation scope. EPPC_ALLOW is some 16-bit quantity, well-known amongst the community of operators who cooperate according to this convention. It should be chosen from the private-use range of ASNs specified in [2]. 3.2 Towards the Other Edge ASes which support this convention must include additional clauses in their advertisement policy to all neighbour ASes, as follows: o When announcing prefixes to AS A: if the community attributes EPPC_ALLOW:0 and EPPC_ALLOW:A are both present, then delete the EPPC_ALLOW:A community, and then advertise the prefix. o If the community attribute EPPC_ALLOW:0 is present, and EPPC_ALLOW:A is not present, then suppress the advertisement. An implementation of this policy for cisco and Juniper routers can be found in Section 5. 3.3 Related Work A similar approach based on a new BGP attribute is described in the companion document draft-black-prop-list-00.txt. Abley Expires September 21, 2001 [Page 5] Internet-Draft Edge Policy Propagation Control March 2001 4. Example Consider the following internetwork: +------+ +-----+ AS B +-----+ | +---+--+ | +---+--+ | +--+---+ +------+ | AS A | | | AS D +----+ AS F | +---+--+ | +--+---+ +------+ | +---+--+ | +-----+ AS C +-----+ +---+--+ | +---+--+ | AS E | +------+ AS A requires a particular set of prefixes to propagate within AS B, D and F, but not elsewhere. AS A therefore advertises the set of prefixes with the community attributes EPPC_ALLOW:0, EPPC_ALLOW:D and EPPC_ALLOW:F. AS B suppresses the advertisements towards AS C, since the community attribute APPC_ALLOW:0 is present without APPC_ALLOW:C. AS B advertises the prefixes towards AS D, removing APPC_ALLOW:D before sending. Similarly, AS D suppresses the advertisements towards AS C, and advertises the prefixes towards AS F after removing APPC_ALLOW:E. AS F suppresses the advertisements towards all peers, since APPC_ALLOW:0 is present without any other APPC_ALLOW:*. The result is that the long prefix routes only propagate to AS B, AS D and AS F, in accordance with the policy specified by AS A. Abley Expires September 21, 2001 [Page 6] Internet-Draft Edge Policy Propagation Control March 2001 5. Sample Implementations 5.1 Juniper JUNOS policy-options { /* EPPC policy towards A. */ policy-statement eppc-to-A { /* If this route is an EPPC route and is for A, then delete * EPCC:A and continue. */ term is-A { from community [ comm-eppc-zero comm-eppc-A ]; then { community delete comm-eppc-A; next policy; } } /* If this route is an EPPC route, then drop it. */ term is-eppc { from community comm-eppc-zero; then reject; } /* Otherwise continue as normal. */ then next policy } /* The EPPC:0 community */ community comm-eppc-zero members EPPC_ALLOW:0; /* The EPPC:A community meaning send to AS A */ community comm-eppc-A members EPPC_ALLOW:A; } Abley Expires September 21, 2001 [Page 7] Internet-Draft Edge Policy Propagation Control March 2001 5.2 cisco IOS ip community-list EPPC-0 permit EPPC_ALLOW:0 ip community-list EPPC-200 permit EPPC_ALLOW:200 ! route-map AS200 permit 10 match comm-list EPPC-0 EPPC-200 set comm-list EPPC-0 delete ! route-map AS200 deny 20 match comm-list EPPC-0 ! route-map AS200 permit 30 ! Abley Expires September 21, 2001 [Page 8] Internet-Draft Edge Policy Propagation Control March 2001 6. Acknowledgements Thanks to Andrew Partan for excellent envelope-scribbling and for the Juniper config fragment. Abley Expires September 21, 2001 [Page 9] Internet-Draft Edge Policy Propagation Control March 2001 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996. [3] Huston, G., "Analyzing the Internet's BGP Routing Table", January 2001. Author's Address Joe Abley Metromedia Fiber Network Inc. 2204 Pembroke Court Burlington, ON L7P 3X8 Canada Phone: +1 905 319 9064 EMail: jabley at mfnx.net Abley Expires September 21, 2001 [Page 10] Internet-Draft Edge Policy Propagation Control March 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Abley Expires September 21, 2001 [Page 11] From jabley-ietf at automagic.org Fri Mar 23 08:05:56 2001 From: jabley-ietf at automagic.org (Joe Abley) Date: Fri, 23 Mar 2001 03:05:56 -0500 Subject: a crude method of limiting long-prefix propagation In-Reply-To: <20010323023017.N28573@buddha.home.automagic.org>; from jabley-ietf@automagic.org on Fri, Mar 23, 2001 at 02:30:17AM -0500 References: <20010322233156.K28573@buddha.home.automagic.org> <200103230637.f2N6biH01190@xoanon.colorado.edu> <20010323023017.N28573@buddha.home.automagic.org> Message-ID: <20010323030556.Q28573@buddha.home.automagic.org> Ah, I sent that out slightly prematurely: On Fri, Mar 23, 2001 at 02:30:17AM -0500, Joe Abley wrote: > 3.2 Towards the Other Edge > > ASes which support this convention must include additional clauses in > their advertisement policy to all neighbour ASes, as follows: > > o When announcing prefixes to AS A: if the community attributes > EPPC_ALLOW:0 and EPPC_ALLOW:A are both present, then delete the > EPPC_ALLOW:A community, and then advertise the prefix. In fact, I don't think there is any need to delete the :A community attribute. That was something we were using for an earlier idea, where we were considering using an empty set of EPPC_ALOW:X attributes to signal the end of the propagation scope. We didn't wind up doing that, and it makes sense to keep all the attributes intact so that they can be observed for troubleshooting purposes. Joe From ahuja at wibh.net Fri Mar 23 08:47:13 2001 From: ahuja at wibh.net (abha) Date: Fri, 23 Mar 2001 00:47:13 -0800 (PST) Subject: a crude method of limiting long-prefix propagation In-Reply-To: <20010323023017.N28573@buddha.home.automagic.org> Message-ID: Very cool. This is very similar to what I had in mind from my discussions with folks earlier this week. Although I've only skimmed the draft at this point, it seems that this is for the case when the aggregate and the more specifics are announced. It would be interesting to consider applying this mechanism for cases where only the more specifics are heard... meaning, specifying when it would be safe to aggregate two or more specific announcements. -abha ;) On Fri, 23 Mar 2001, Joe Abley wrote: > On Thu, Mar 22, 2001 at 11:37:44PM -0700, mccreary at pch.net wrote: > > With a small change in semantics, it seems like this scheme is sufficient to > > support restricted announcement of any route to an explicit set of ASes. Just > > change the meaning of EPPC_ALOW:ASN a little so it indicates `advertiseable > > to', so that a participating AS will only advertise this route to a peer if > > the proper community attribute appears in the route. > > Yup. I already piped the -00 draft through asp and derived something > very similar. The following draft does not contain the one-AS-hop > limitation, and includes sample config for IOS and JUNOS. > > http://www.automagic.org/~jabley/draft-jabley-edge-policy-propagation-control-01.txt > > As suggested by Curtis, Ben is plugging the basic idea encompassed in > this mechanism into a new bgp attribute, as an alternative approach to > using community strings. > > > Joe > > > Network Working Group J. Abley > Internet-Draft Metromedia Fiber Network Inc. > Expires: September 21, 2001 March 23, 2001 > > > Edge Policy Propagation Control > draft-jabley-edge-policy-propagation-control-01 > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on September 21, 2001. > > Copyright Notice > > Copyright (C) The Internet Society (2001). All Rights Reserved. > > Abstract > > There is a requirement for some multi-homed sites to influence the > path selected by autonomous systems beyond those that are immediately > adjacent. > > One of the few generic mechanisms available is to deaggregate and > advertise long component prefixes to the network, since there can be > some confidence that the longest prefix will be used, regardless of > other local policy such as local preference. Most ASes exhibit > liberal route import policy with respect to prefix length, which > facilitates this technique. > > Unfortunately, although the deaggregated prefix set may be required > > > > Abley Expires September 21, 2001 [Page 1] > > Internet-Draft Edge Policy Propagation Control March 2001 > > > to be installed in only a few targeted ASes for the aims of the > origin to be achieved, there is no reliable mechanism to limit the > propagation of the prefixes. This contributes to prefix bloat in the > default-free zone, which is a concern. > > This draft describes a community-based convention which might be used > to limit propagation of long prefixes to those ASes where they are > required. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Abley Expires September 21, 2001 [Page 2] > > Internet-Draft Edge Policy Propagation Control March 2001 > > > 1. Introduction > > There is a requirement for some multi-homed sites to influence the > path selected by autonomous systems beyond those that are immediately > adjacent. > > One of the few generic mechanisms available is to deaggregate and > advertise long component prefixes to the network, since there can be > some confidence that the longest prefix will be used, regardless of > other local policy such as local preference. Most ASes exhibit > liberal route import policy with respect to prefix length, which > facilitates this technique. > > Unfortunately, although the deaggregated prefix set may be required > to be installed in only a few targeted ASes for the aims of the > origin to be achieved, there is no reliable mechanism to limit the > propagation of the prefixes. This contributes to prefix bloat in the > default-free zone, which is a concern. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Abley Expires September 21, 2001 [Page 3] > > Internet-Draft Edge Policy Propagation Control March 2001 > > > 2. Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [1]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Abley Expires September 21, 2001 [Page 4] > > Internet-Draft Edge Policy Propagation Control March 2001 > > > 3. Edge Policy Propagation Convention > > 3.1 At the Edge > > An edge site deaggregates its advertisements according to the > required fine-grain policy. Aggregate prefixes are advertised as > normal; long prefixes are advertised tagged with community attributes > which define their scope: > > EPPC_ALLOW:0 -- this prefix should be handled according to the > convention described in this document. > > EPPC_ALLOW:A -- it is desirable that this prefix should propagate to > AS A. Multiple communities of the form EPPC_ALLOW:A may be > present to define propagation scope. > > EPPC_ALLOW is some 16-bit quantity, well-known amongst the community > of operators who cooperate according to this convention. It should > be chosen from the private-use range of ASNs specified in [2]. > > 3.2 Towards the Other Edge > > ASes which support this convention must include additional clauses in > their advertisement policy to all neighbour ASes, as follows: > > o When announcing prefixes to AS A: if the community attributes > EPPC_ALLOW:0 and EPPC_ALLOW:A are both present, then delete the > EPPC_ALLOW:A community, and then advertise the prefix. > > o If the community attribute EPPC_ALLOW:0 is present, and > EPPC_ALLOW:A is not present, then suppress the advertisement. > > An implementation of this policy for cisco and Juniper routers can be > found in Section 5. > > 3.3 Related Work > > A similar approach based on a new BGP attribute is described in the > companion document draft-black-prop-list-00.txt. > > > > > > > > > > > > > Abley Expires September 21, 2001 [Page 5] > > Internet-Draft Edge Policy Propagation Control March 2001 > > > 4. Example > > Consider the following internetwork: > > > +------+ > +-----+ AS B +-----+ > | +---+--+ | > +---+--+ | +--+---+ +------+ > | AS A | | | AS D +----+ AS F | > +---+--+ | +--+---+ +------+ > | +---+--+ | > +-----+ AS C +-----+ > +---+--+ > | > +---+--+ > | AS E | > +------+ > > > AS A requires a particular set of prefixes to propagate within AS B, > D and F, but not elsewhere. > > AS A therefore advertises the set of prefixes with the community > attributes EPPC_ALLOW:0, EPPC_ALLOW:D and EPPC_ALLOW:F. > > AS B suppresses the advertisements towards AS C, since the community > attribute APPC_ALLOW:0 is present without APPC_ALLOW:C. AS B > advertises the prefixes towards AS D, removing APPC_ALLOW:D before > sending. > > Similarly, AS D suppresses the advertisements towards AS C, and > advertises the prefixes towards AS F after removing APPC_ALLOW:E. > > AS F suppresses the advertisements towards all peers, since > APPC_ALLOW:0 is present without any other APPC_ALLOW:*. > > The result is that the long prefix routes only propagate to AS B, AS > D and AS F, in accordance with the policy specified by AS A. > > > > > > > > > > > > > Abley Expires September 21, 2001 [Page 6] > > Internet-Draft Edge Policy Propagation Control March 2001 > > > 5. Sample Implementations > > 5.1 Juniper JUNOS > > > policy-options { > /* EPPC policy towards A. */ > policy-statement eppc-to-A { > /* If this route is an EPPC route and is for A, then delete > * EPCC:A and continue. > */ > term is-A { > from community [ comm-eppc-zero comm-eppc-A ]; > then { > community delete comm-eppc-A; > next policy; > } > } > /* If this route is an EPPC route, then drop it. */ > term is-eppc { > from community comm-eppc-zero; > then reject; > } > /* Otherwise continue as normal. */ > then next policy > } > /* The EPPC:0 community */ > community comm-eppc-zero members EPPC_ALLOW:0; > /* The EPPC:A community meaning send to AS A */ > community comm-eppc-A members EPPC_ALLOW:A; > } > > > > > > > > > > > > > > > > > > > > > Abley Expires September 21, 2001 [Page 7] > > Internet-Draft Edge Policy Propagation Control March 2001 > > > 5.2 cisco IOS > > > ip community-list EPPC-0 permit EPPC_ALLOW:0 > ip community-list EPPC-200 permit EPPC_ALLOW:200 > ! > route-map AS200 permit 10 > match comm-list EPPC-0 EPPC-200 > set comm-list EPPC-0 delete > ! > route-map AS200 deny 20 > match comm-list EPPC-0 > ! > route-map AS200 permit 30 > ! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Abley Expires September 21, 2001 [Page 8] > > Internet-Draft Edge Policy Propagation Control March 2001 > > > 6. Acknowledgements > > Thanks to Andrew Partan for excellent envelope-scribbling and for the > Juniper config fragment. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Abley Expires September 21, 2001 [Page 9] > > Internet-Draft Edge Policy Propagation Control March 2001 > > > References > > [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", RFC 2119, March 1997. > > [2] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, > and registration of an Autonomous System (AS)", RFC 1930, March > 1996. > > [3] Huston, G., "Analyzing the Internet's BGP Routing Table", > January 2001. > > > Author's Address > > Joe Abley > Metromedia Fiber Network Inc. > 2204 Pembroke Court > Burlington, ON L7P 3X8 > Canada > > Phone: +1 905 319 9064 > EMail: jabley at mfnx.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Abley Expires September 21, 2001 [Page 10] > > Internet-Draft Edge Policy Propagation Control March 2001 > > > Full Copyright Statement > > Copyright (C) The Internet Society (2001). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > Acknowledgement > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > > > > > > > > > > > > > > > > > > Abley Expires September 21, 2001 [Page 11] > > From yakov at juniper.net Fri Mar 23 18:01:45 2001 From: yakov at juniper.net (Yakov Rekhter) Date: Fri, 23 Mar 2001 10:01:45 -0800 Subject: a crude method of limiting long-prefix propagation In-Reply-To: Your message of "Fri, 23 Mar 2001 02:30:17 EST." <20010323023017.N28573@buddha.home.automagic.org> Message-ID: <200103231801.KAA26649@garnet.juniper.net> Joe, > On Thu, Mar 22, 2001 at 11:37:44PM -0700, mccreary at pch.net wrote: > > With a small change in semantics, it seems like this scheme is sufficient t o > > support restricted announcement of any route to an explicit set of ASes. J ust > > change the meaning of EPPC_ALOW:ASN a little so it indicates `advertiseable > > to', so that a participating AS will only advertise this route to a peer if > > the proper community attribute appears in the route. > > Yup. I already piped the -00 draft through asp and derived something > very similar. The following draft does not contain the one-AS-hop > limitation, and includes sample config for IOS and JUNOS. > > http://www.automagic.org/~jabley/draft-jabley-edge-policy-propagation-control -01.txt > > As suggested by Curtis, Ben is plugging the basic idea encompassed in > this mechanism into a new bgp attribute, as an alternative approach to > using community strings. When considering a new BGP attribute, I wonder whether we could "re-cycle" the DIST_LIST_INCLUDE attribute of IDRP. Yakov. From heas Fri Mar 23 19:54:41 2001 From: heas (john heasley) Date: Fri, 23 Mar 2001 11:54:41 -0800 Subject: a crude method of limiting long-prefix propagation In-Reply-To: <20010323030556.Q28573@buddha.home.automagic.org>; from jabley-ietf@automagic.org on Fri, Mar 23, 2001 at 03:05:56AM -0500 References: <20010322233156.K28573@buddha.home.automagic.org> <200103230637.f2N6biH01190@xoanon.colorado.edu> <20010323023017.N28573@buddha.home.automagic.org> <20010323030556.Q28573@buddha.home.automagic.org> Message-ID: <20010323115441.I9477@shrubbery.net> Fri, Mar 23, 2001 at 03:05:56AM -0500, Joe Abley: > Ah, I sent that out slightly prematurely: > > On Fri, Mar 23, 2001 at 02:30:17AM -0500, Joe Abley wrote: > > 3.2 Towards the Other Edge > > > > ASes which support this convention must include additional clauses in > > their advertisement policy to all neighbour ASes, as follows: > > > > o When announcing prefixes to AS A: if the community attributes > > EPPC_ALLOW:0 and EPPC_ALLOW:A are both present, then delete the > > EPPC_ALLOW:A community, and then advertise the prefix. > > In fact, I don't think there is any need to delete the :A community then there really isnt a need for the :0 communities by matching EPPC_ALLOW:*. > attribute. That was something we were using for an earlier idea, where > we were considering using an empty set of EPPC_ALOW:X attributes to > signal the end of the propagation scope. > > We didn't wind up doing that, and it makes sense to keep all the > attributes intact so that they can be observed for troubleshooting > purposes. > > > Joe important to note that this either makes your generic out-bound peering policy rather long (N(peers) + ?? paragraphs) or means you can not use peer-groups with today's limitations, which do not seem likely to change. From ben at layer8.net Fri Mar 23 23:21:33 2001 From: ben at layer8.net (Ben Black) Date: Fri, 23 Mar 2001 15:21:33 -0800 Subject: a crude method of limiting long-prefix propagation In-Reply-To: <200103231801.KAA26649@garnet.juniper.net>; from yakov@juniper.net on Fri, Mar 23, 2001 at 10:01:45AM -0800 References: <20010323023017.N28573@buddha.home.automagic.org> <200103231801.KAA26649@garnet.juniper.net> Message-ID: <20010323152133.A68250@layer8.net> Yakov, Can you provide a reference for this? I am rather far along in my definition of the PROP_PATH and its behavior, but any input like this is welcome. Ben On Fri, Mar 23, 2001 at 10:01:45AM -0800, Yakov Rekhter wrote: > Joe, > > > On Thu, Mar 22, 2001 at 11:37:44PM -0700, mccreary at pch.net wrote: > > > With a small change in semantics, it seems like this scheme is sufficient t > o > > > support restricted announcement of any route to an explicit set of ASes. J > ust > > > change the meaning of EPPC_ALOW:ASN a little so it indicates `advertiseable > > > to', so that a participating AS will only advertise this route to a peer if > > > the proper community attribute appears in the route. > > > > Yup. I already piped the -00 draft through asp and derived something > > very similar. The following draft does not contain the one-AS-hop > > limitation, and includes sample config for IOS and JUNOS. > > > > http://www.automagic.org/~jabley/draft-jabley-edge-policy-propagation-control > -01.txt > > > > As suggested by Curtis, Ben is plugging the basic idea encompassed in > > this mechanism into a new bgp attribute, as an alternative approach to > > using community strings. > > When considering a new BGP attribute, I wonder whether we could > "re-cycle" the DIST_LIST_INCLUDE attribute of IDRP. > > Yakov. From jabley-ietf at automagic.org Sat Mar 24 13:50:06 2001 From: jabley-ietf at automagic.org (Joe Abley) Date: Sat, 24 Mar 2001 08:50:06 -0500 Subject: a crude method of limiting long-prefix propagation In-Reply-To: <20010323115441.I9477@shrubbery.net>; from heas@shrubbery.net on Fri, Mar 23, 2001 at 11:54:41AM -0800 References: <20010322233156.K28573@buddha.home.automagic.org> <200103230637.f2N6biH01190@xoanon.colorado.edu> <20010323023017.N28573@buddha.home.automagic.org> <20010323030556.Q28573@buddha.home.automagic.org> <20010323115441.I9477@shrubbery.net> Message-ID: <20010324085006.A12301@buddha.home.automagic.org> On Fri, Mar 23, 2001 at 11:54:41AM -0800, john heasley wrote: > Fri, Mar 23, 2001 at 03:05:56AM -0500, Joe Abley: > > Ah, I sent that out slightly prematurely: > > > > On Fri, Mar 23, 2001 at 02:30:17AM -0500, Joe Abley wrote: > > > 3.2 Towards the Other Edge > > > > > > ASes which support this convention must include additional clauses in > > > their advertisement policy to all neighbour ASes, as follows: > > > > > > o When announcing prefixes to AS A: if the community attributes > > > EPPC_ALLOW:0 and EPPC_ALLOW:A are both present, then delete the > > > EPPC_ALLOW:A community, and then advertise the prefix. > > > > In fact, I don't think there is any need to delete the :A community > > then there really isnt a need for the :0 communities by matching EPPC_ALLOW:*. That's true -- however, I wasn't sure how widely a match for N:* was supported (I hear you can do it on ciscos and junipers though). If there are routers that can't match a wildcard community string, the :0 value would allow more widespread support. Is this a non-issue? Joe From jabley-ietf at automagic.org Sat Mar 24 14:10:29 2001 From: jabley-ietf at automagic.org (Joe Abley) Date: Sat, 24 Mar 2001 09:10:29 -0500 Subject: a crude method of limiting long-prefix propagation In-Reply-To: <200103230637.f2N6biH01190@xoanon.colorado.edu>; from mccreary@pch.net on Thu, Mar 22, 2001 at 11:37:44PM -0700 References: <20010322233156.K28573@buddha.home.automagic.org> <200103230637.f2N6biH01190@xoanon.colorado.edu> Message-ID: <20010324091029.C12301@buddha.home.automagic.org> On Thu, Mar 22, 2001 at 11:37:44PM -0700, mccreary at pch.net wrote: > The real question is whether any ISP thinks this is compatible with their > current traffic engineering efforts. Any solution requiring significant > amounts of inter-provider cooperation will need to demonstrate clear benefits > for all parties involved, and I can't think of a compelling reason why an > AS 2 or more hops from the origin AS would want to support remote manipulation > of their transit traffic (in the general case, at least). This is the main question; however, I think there is some hope. A --- B ---- C --- D Suppose A is trying to influence policy at C. This requires cooperation between A, B and C. Between A and B there is a transit arrangement, and hence the lever of money might induce cooperation. A transit arrangement between B and C might be achievable similarly. If B and C are peers, then there is a less-obvious motivation to play. There is the mitigating factor that the config bits to provide the support might already be there, assuming C has customers that have similar requirements to A. All this requires some useful subset of providers to decide to take some action to reduce prefix bloat. However, at least the use of these communities doesn't make the current bloat any worse; the question is whether it makes a sufficient difference to be worth doing. (or, another question: which ASes in the real network need to support this for it to be generally useful?) Ben's alternative implementation in a new bgp attribute might be easier to get running around the network, since its deployment can be driven by vendors rather than operators, and there are fewer vendors who need to join in to make it a reality. Joe From yakov at juniper.net Sun Mar 25 02:37:05 2001 From: yakov at juniper.net (Yakov Rekhter) Date: Sat, 24 Mar 2001 18:37:05 -0800 Subject: a crude method of limiting long-prefix propagation In-Reply-To: Your message of "Fri, 23 Mar 2001 15:21:33 PST." <20010323152133.A68250@layer8.net> Message-ID: <200103250237.SAA34384@garnet.juniper.net> Ben, > Yakov, > Can you provide a reference for this? I am rather far along in > my definition of the PROP_PATH and its behavior, but any input like this > is welcome. see below... Yakov. --------------------------------------------------------------------- 7.12.5 DIST_LIST_INCL DIST_LIST_INCL is an optional transitive attribute. It shall be recognized upon receipt by all routers. When present, this attribute lists the ASs of the routing domains to which the routing information may be distributed. When a router receives an UPDATE message that contains the DIST_LIST_INCL attribute, then the receiving router shall not redistribute the associated routing information to any router which is not a member of at least one autonomous system whose AS is contained in this attribute. A router shall redistribute only that information which has been locally selected as a route, and shall redistribute it only to autonomous systems which are both adjacent to it and are included in the distribution list. A router may distribute the information to any adjacent router that is a member of any routing domain or confederation whose AS is contained in DIST_LIST_INCL. A router is not required to distribute the routing information to every autonomous system whose AS is listed. If a router receives an UPDATE message that doesn't contain the DIST_LIST_INCL attribute, then it may distribute the routing information to all adjacent routers. Alternatively, the local router may also add a DIST_LIST_INCL attribute, to the route information. If the DIST_LIST_INCL attribute is present and has a length of zero octets, then the routing information may be used locally, but shall not be advertised to any other router. When it originates an UPDATE message which describes a route to destinations located in its own routing domain, a router may append the DIST_LIST_INCL attribute, in accordance with its local policies. If a router chooses to advertise a route which was learned from an UPDATE message which already contained the DIST_LIST_INCL attribute, the advertising router may modify this attribute by pruning the set of ASs included in the list. If a router chooses to prune the set, it shall not delete the AS of its own autonomous system. However, if the reduced list is empty (that is, has a length of zero), then the router shall not advertise the routing information to any router located in a different routing domain. From heas at shrubbery.net Sun Mar 25 03:39:38 2001 From: heas at shrubbery.net (john heasley) Date: Sat, 24 Mar 2001 19:39:38 -0800 Subject: a crude method of limiting long-prefix propagation In-Reply-To: <20010324085006.A12301@buddha.home.automagic.org>; from jabley-ietf@automagic.org on Sat, Mar 24, 2001 at 08:50:06AM -0500 References: <20010322233156.K28573@buddha.home.automagic.org> <200103230637.f2N6biH01190@xoanon.colorado.edu> <20010323023017.N28573@buddha.home.automagic.org> <20010323030556.Q28573@buddha.home.automagic.org> <20010323115441.I9477@shrubbery.net> <20010324085006.A12301@buddha.home.automagic.org> Message-ID: <20010324193938.C9477@shrubbery.net> Sat, Mar 24, 2001 at 08:50:06AM -0500, Joe Abley: > On Fri, Mar 23, 2001 at 11:54:41AM -0800, john heasley wrote: > > Fri, Mar 23, 2001 at 03:05:56AM -0500, Joe Abley: > > > Ah, I sent that out slightly prematurely: > > > > > > On Fri, Mar 23, 2001 at 02:30:17AM -0500, Joe Abley wrote: > > > > 3.2 Towards the Other Edge > > > > > > > > ASes which support this convention must include additional clauses in > > > > their advertisement policy to all neighbour ASes, as follows: > > > > > > > > o When announcing prefixes to AS A: if the community attributes > > > > EPPC_ALLOW:0 and EPPC_ALLOW:A are both present, then delete the > > > > EPPC_ALLOW:A community, and then advertise the prefix. > > > > > > In fact, I don't think there is any need to delete the :A community > > > > then there really isnt a need for the :0 communities by matching EPPC_ALLOW:*. > > That's true -- however, I wasn't sure how widely a match for N:* was > supported (I hear you can do it on ciscos and junipers though). If > there are routers that can't match a wildcard community string, the > :0 value would allow more widespread support. probably, exists...3com, bay, ... does gated have support? > Is this a non-issue? imo, no. > > Joe From jabley-ietf at automagic.org Sun Mar 25 04:23:24 2001 From: jabley-ietf at automagic.org (Joe Abley) Date: Sat, 24 Mar 2001 23:23:24 -0500 Subject: a crude method of limiting long-prefix propagation In-Reply-To: <20010324193938.C9477@shrubbery.net>; from heas@shrubbery.net on Sat, Mar 24, 2001 at 07:39:38PM -0800 References: <20010322233156.K28573@buddha.home.automagic.org> <200103230637.f2N6biH01190@xoanon.colorado.edu> <20010323023017.N28573@buddha.home.automagic.org> <20010323030556.Q28573@buddha.home.automagic.org> <20010323115441.I9477@shrubbery.net> <20010324085006.A12301@buddha.home.automagic.org> <20010324193938.C9477@shrubbery.net> Message-ID: <20010324232324.E22499@buddha.home.automagic.org> On Sat, Mar 24, 2001 at 07:39:38PM -0800, john heasley wrote: > Sat, Mar 24, 2001 at 08:50:06AM -0500, Joe Abley: > > That's true -- however, I wasn't sure how widely a match for N:* was > > supported (I hear you can do it on ciscos and junipers though). If > > there are routers that can't match a wildcard community string, the > > :0 value would allow more widespread support. > > probably, exists...3com, bay, ... does gated have support? Don't know. I don't know how widespread gated is outside the lab, either. I sent a question to nanog about this, so hopefully if there's a router out there in common use that can't do a wildcard compare, someone will tell me about it. Joe From heas at shrubbery.net Sun Mar 25 04:32:14 2001 From: heas at shrubbery.net (john heasley) Date: Sat, 24 Mar 2001 20:32:14 -0800 Subject: a crude method of limiting long-prefix propagation In-Reply-To: <20010324232324.E22499@buddha.home.automagic.org>; from jabley-ietf@automagic.org on Sat, Mar 24, 2001 at 11:23:24PM -0500 References: <20010322233156.K28573@buddha.home.automagic.org> <200103230637.f2N6biH01190@xoanon.colorado.edu> <20010323023017.N28573@buddha.home.automagic.org> <20010323030556.Q28573@buddha.home.automagic.org> <20010323115441.I9477@shrubbery.net> <20010324085006.A12301@buddha.home.automagic.org> <20010324193938.C9477@shrubbery.net> <20010324232324.E22499@buddha.home.automagic.org> Message-ID: <20010324203214.D9477@shrubbery.net> Sat, Mar 24, 2001 at 11:23:24PM -0500, Joe Abley: > On Sat, Mar 24, 2001 at 07:39:38PM -0800, john heasley wrote: > > Sat, Mar 24, 2001 at 08:50:06AM -0500, Joe Abley: > > > That's true -- however, I wasn't sure how widely a match for N:* was > > > supported (I hear you can do it on ciscos and junipers though). If > > > there are routers that can't match a wildcard community string, the > > > :0 value would allow more widespread support. > > > > probably, exists...3com, bay, ... does gated have support? > > Don't know. I don't know how widespread gated is outside the lab, either. actually, the lab was why i mentioned it. > I sent a question to nanog about this, so hopefully if there's a router > out there in common use that can't do a wildcard compare, someone will > tell me about it. > > > Joe From joel at longsys.com Mon Mar 26 16:15:05 2001 From: joel at longsys.com (Joel M. Halpern) Date: Mon, 26 Mar 2001 11:15:05 -0500 Subject: a crude method of limiting long-prefix propagation In-Reply-To: <200103250237.SAA34384@garnet.juniper.net> References: Message-ID: <4.2.2.20010326111412.00bc3270@localhost> If we are going to look down this path, for some cases at least, DIST_LIST_EXCL (which lists where NOT to send the information) would also seem useful. Yours, Joel M. Halpern At 06:37 PM 3/24/01 -0800, Yakov Rekhter wrote: >Ben, > > > Yakov, > > Can you provide a reference for this? I am rather far along in > > my definition of the PROP_PATH and its behavior, but any input like this > > is welcome. > >see below... > >Yakov. >--------------------------------------------------------------------- > 7.12.5 DIST_LIST_INCL > > DIST_LIST_INCL is an optional transitive attribute. It > shall be recognized upon receipt by all routers. When present, > this attribute lists the ASs of the routing domains to which > the routing information may be distributed. > > When a router receives an UPDATE message that contains the > DIST_LIST_INCL attribute, then the receiving router shall > not redistribute the associated routing information to any > router which is not a member of at least one autonomous system > whose AS is contained in this attribute. > > A router shall redistribute only that information which has > been locally selected as a route, and shall redistribute it > only to autonomous systems which are both adjacent to it and > are included in the distribution list. A router may distribute > the information to any adjacent router that is a member of > any routing domain or confederation whose AS is contained in > DIST_LIST_INCL. A router is not required to distribute the > routing information to every autonomous system whose AS is > listed. > > If a router receives an UPDATE message that doesn't contain > the DIST_LIST_INCL attribute, then it may distribute the > routing information to all adjacent routers. Alternatively, > the local router may also add a DIST_LIST_INCL attribute, to > the route information. If the DIST_LIST_INCL attribute is > present and has a length of zero octets, then the routing > information may be used locally, but shall not be advertised > to any other router. > > When it originates an UPDATE message which describes a route > to destinations located in its own routing domain, a router > may append the DIST_LIST_INCL attribute, in accordance with > its local policies. > > If a router chooses to advertise a route which was learned > from an UPDATE message which already contained the DIST_LIST_INCL > attribute, the advertising router may modify this attribute > by pruning the set of ASs included in the list. If a router > chooses to prune the set, it shall not delete the AS of its > own autonomous system. However, if the reduced list is empty > (that is, has a length of zero), then the router shall not > advertise the routing information to any router located in > a different routing domain. From jabley-ietf at automagic.org Mon Mar 26 16:34:58 2001 From: jabley-ietf at automagic.org (Joe Abley) Date: Mon, 26 Mar 2001 11:34:58 -0500 Subject: a crude method of limiting long-prefix propagation In-Reply-To: <4.2.2.20010326111412.00bc3270@localhost>; from joel@longsys.com on Mon, Mar 26, 2001 at 11:15:05AM -0500 References: <200103250237.SAA34384@garnet.juniper.net> <4.2.2.20010326111412.00bc3270@localhost> Message-ID: <20010326113458.B30294@buddha.home.automagic.org> On Mon, Mar 26, 2001 at 11:15:05AM -0500, Joel M. Halpern wrote: > If we are going to look down this path, for some cases at least, > DIST_LIST_EXCL (which lists where NOT to send the information) would also > seem useful. The mechanism I used in the community-based approach (and which I think Ben is using in his PROP_PATH attribute) is that if it looks like propagation control is specified for a prefix, then not mentioning an AS where the prefix should be announced is an implicit exclude for that AS. i.e. if the EPPC_ALLOW:0 community is present, and EPPC_ALLOW:A is not present, then the prefix must not be advertised to AS A (and must not be accepted by AS A if AS A understands the EPPC conventions, although I added that after the -01 draft was sent out). Correspondingly, I think the description Ben is working on will specify that if the PROP_PATH attribute is present and AS A is not present in the PROP_PATH, the prefix must not be advertised to or accepted by AS A. Is there a scenario where it is better to specify "I don't want this prefix to go to these ASes" rather than "I only want this prefix to go to these ASes"? I like the current logic better, I think. Joe From curtis at workhorse.fictitious.org Mon Mar 26 17:41:18 2001 From: curtis at workhorse.fictitious.org (Curtis Villamizar) Date: Mon, 26 Mar 2001 12:41:18 -0500 Subject: fyi - my notes on the ptomaine issue Message-ID: <200103261741.MAA55055@workhorse.fictitious.org> This is just an FYI. If anyone is interested, these are excerpts from the notes I jotted down after the ptomaine meeting (some of the notes well after the meeting in the airport waiting for a delayed flight). As Yakov already pointed out, this feature of the new attribute described below is similar to a feature in IDRP (but just about everthing imagionable is in IDRP which is why IDRP never happenned). A key semantic difference is in the proposed semantics below, if an overlap occurred, any provider would aggregate in the absense of this attribute under the assumption that the more specific was a mistaken rather than an intentional and bounded leak through the aggregate. You guys can take it from here (Ben, Joe, anyone else). Curtis A number of presentations were made by Geof Huston, Abha Ahuja, Craig Labovitz. These were mostly reruns of measurements and projections of growth in the number of prefix, AS, or paths. The problem is that more specific components of aggregates have to be announced among a small number of AS but need not be announced very far. Once announced outside the origin AS, the aggregates are never formed due to the difficulty of coordinating aggregation across multiple providers. Prior attempts to fix this were based on the routing registry (IRR). A suggestion was made (by me) to resurrect the prior work (also by me) but to use BGP communities instead of the IRR as the means to communicate the needs to proxy aggregate outside the origin AS. John Scudder later in a private conversation suggested that we use a new BGP attribute since we would otherwise need multiple communities per aggregate (one per AS that must carry the more specifics) plus we need to make modifications to the router code in deciding to form aggregates in what would now be considered special cases. The transition would proceed as follows: 1. First we must agree on the protocol method. There are two candidates. a. Routers would have to form an aggregate for any prefix which has a specific community set that contains their own AS in the lower half but only if the peer AS was not listed in a similar aggregate. This part could be done without change to the router but long term may be less desirable. It also initially requires some per peer configuration. b. If a new BGP attribute was present, and the routers AS was not listed, then the router would not accept any more specific prefixes. If the router's AS was listed and an EBGP peer's AS is not listed, then proxy aggregation is performed outbound. The advantage of this method is it requires software upgrade but no configuration except simple configuration at the origin AS. 2. Demonstrate the capability to aggregate using one of the above methods. a. Providers within the aggregation boundary must be prepared to handle one the above cases. For case (a) (communities) these providers must have their routers configured to recognize the appropriate set of communities. For case (b) (new attribute) the routers must be upgraded and at most a feature enabled. b. The origin AS must put the community or new attribute on the aggregate. 3. Encourage widespread deployment. The goal of widespread deployment is to provide explicit limits to the regions in which multihomed prefixes are announced thereby decreasing the size and growth rate of the global routing table. 4. Begin proxy aggregating in any case where shorter prefixes overlap longer prefixes and where attributes are not present limiting the region where the more specific leak. This step make the default to aggregate rather than to leak globally. It might be that this step is never actually taken but could serve as the "big stick" to provide the "encouragement" in step 3. These notes describing the proposed solutions were written a while after the meeting and after discussions with John, Abha, Geoff, Ben Black, and others. If its wrong it was my error and I expect to be corrected on the ptomaine mailing list. From joel at longsys.com Mon Mar 26 17:47:16 2001 From: joel at longsys.com (Joel M. Halpern) Date: Mon, 26 Mar 2001 12:47:16 -0500 Subject: a crude method of limiting long-prefix propagation In-Reply-To: <20010326113458.B30294@buddha.home.automagic.org> References: <4.2.2.20010326111412.00bc3270@localhost> <200103250237.SAA34384@garnet.juniper.net> <4.2.2.20010326111412.00bc3270@localhost> Message-ID: <4.2.2.20010326124351.00c3c700@localhost> Using Exclude is better under certain topological conditions. The primary condition is when the point where the disparate paths are exquivalent (in an AS sense) is such taht a reasonably large number of AS need the multiple advertisements and where topologically there are a relatively small number of boundary AS who only need the aggregation, and will take of further distribution of the aggregated information. The purpose is to have an alternative mechanism to limit how many AS one must include in the distribution list. You or Yakov are probably in a better position than I to see if the topology would actually make it useful. It just seems that some knob for the more remote case might well be helpful. [Remote of course has nothing to do with geography. In some metros, there are be several AS between facilities two blocks apart.] Yours, Joel M. Halpern At 11:34 AM 3/26/01 -0500, Joe Abley wrote: >On Mon, Mar 26, 2001 at 11:15:05AM -0500, Joel M. Halpern wrote: > > If we are going to look down this path, for some cases at least, > > DIST_LIST_EXCL (which lists where NOT to send the information) would also > > seem useful. > >The mechanism I used in the community-based approach (and which I think >Ben is using in his PROP_PATH attribute) is that if it looks like >propagation control is specified for a prefix, then not mentioning an >AS where the prefix should be announced is an implicit exclude for that >AS. > >i.e. if the EPPC_ALLOW:0 community is present, and EPPC_ALLOW:A is not >present, then the prefix must not be advertised to AS A (and must not >be accepted by AS A if AS A understands the EPPC conventions, although >I added that after the -01 draft was sent out). > >Correspondingly, I think the description Ben is working on will specify >that if the PROP_PATH attribute is present and AS A is not present in >the PROP_PATH, the prefix must not be advertised to or accepted by AS A. > >Is there a scenario where it is better to specify "I don't want this >prefix to go to these ASes" rather than "I only want this prefix to >go to these ASes"? I like the current logic better, I think. > > >Joe From curtis at workhorse.fictitious.org Mon Mar 26 20:28:58 2001 From: curtis at workhorse.fictitious.org (Curtis Villamizar) Date: Mon, 26 Mar 2001 15:28:58 -0500 Subject: a crude method of limiting long-prefix propagation In-Reply-To: Your message of "Mon, 26 Mar 2001 12:47:16 EST." <4.2.2.20010326124351.00c3c700@localhost> Message-ID: <200103262028.PAA56267@workhorse.fictitious.org> In message <4.2.2.20010326124351.00c3c700 at localhost>, "Joel M. Halpern" writes: > Using Exclude is better under certain topological conditions. > > The primary condition is when the point where the disparate paths are > exquivalent (in an AS sense) is such taht a reasonably large number of AS > need the multiple advertisements > > and > > where topologically there are a relatively small number of boundary AS who > only need the aggregation, and will take of further distribution of the > aggregated information. > > The purpose is to have an alternative mechanism to limit how many AS one > must include in the distribution list. You or Yakov are probably in a > better position than I to see if the topology would actually make it > useful. It just seems that some knob for the more remote case might well > be helpful. [Remote of course has nothing to do with geography. In some > metros, there are be several AS between facilities two blocks apart.] > > Yours, > Joel M. Halpern Joel, There are thousands of AS allocated and in use. Most leaks through aggregates need only be advertised to a few AS. The "include list" will be much shorter than an "exclude list". It is also better to require that the more specific be leaked to a well thought out set of AS where there is a known purpose for having the more specifics leaked (ie: a reason such as it is needed for local load balancing). Curtis From joel at longsys.com Mon Mar 26 20:55:55 2001 From: joel at longsys.com (Joel M. Halpern) Date: Mon, 26 Mar 2001 15:55:55 -0500 Subject: a crude method of limiting long-prefix propagation In-Reply-To: <200103262028.PAA56267@workhorse.fictitious.org> References: Message-ID: <4.2.2.20010326155440.00b9b220@localhost> Fair enough. Given the potential size of the list, I wanted to make sure we thought about the alternative. Having thought about it, we can certainly conclude (as Curtis has) that instead we can treat a long list as a warning sign that someone is doing something that probably causes problems. Yours, Joel At 03:28 PM 3/26/01 -0500, Curtis Villamizar wrote: >In message <4.2.2.20010326124351.00c3c700 at localhost>, "Joel M. Halpern" >writes: > > Using Exclude is better under certain topological conditions. > > > > The primary condition is when the point where the disparate paths are > > exquivalent (in an AS sense) is such taht a reasonably large number of AS > > need the multiple advertisements > > > > and > > > > where topologically there are a relatively small number of boundary AS > who > > only need the aggregation, and will take of further distribution of the > > aggregated information. > > > > The purpose is to have an alternative mechanism to limit how many AS one > > must include in the distribution list. You or Yakov are probably in a > > better position than I to see if the topology would actually make it > > useful. It just seems that some knob for the more remote case might well > > be helpful. [Remote of course has nothing to do with geography. In some > > metros, there are be several AS between facilities two blocks apart.] > > > > Yours, > > Joel M. Halpern > > >Joel, > >There are thousands of AS allocated and in use. Most leaks through >aggregates need only be advertised to a few AS. The "include list" >will be much shorter than an "exclude list". It is also better to >require that the more specific be leaked to a well thought out set of >AS where there is a known purpose for having the more specifics leaked >(ie: a reason such as it is needed for local load balancing). > >Curtis