From mknopper at cisco.com Tue Mar 12 21:40:04 2002 From: mknopper at cisco.com (Mark Knopper) Date: Tue, 12 Mar 2002 16:40:04 -0500 Subject: proposed ptomaine agenda In-Reply-To: <1015919623.7920.36.camel@elf.packetdesign.com> Message-ID: Below is a proposed agenda for the PTOMAINE session Tuesday 1300-1400 at the IETF next week. Please reply with any comments or suggestions. 1. - Geoff Huston - NOPEER community for BGP route scope control draft-huston-nopeer-00.txt 2. - Russ White - presenting Olivier Bonaventure's draft - Controlling the redistribution of BGP routes http://www.info.fundp.ac.be/~obo/private/draf-bonaventure-bgp-redistribution -02.txt 3. - Ted Hardie - Bounding Longest Match Considered draft-hardie-bounded-longest-match-02.txt 4. Cathy Wittbrodt - giving Gert Doering's presentation on - IPv6 routing scalability --Mark From Olivier.Bonaventure at info.fundp.ac.be Fri Mar 15 07:49:31 2002 From: Olivier.Bonaventure at info.fundp.ac.be (Olivier Bonaventure) Date: Fri, 15 Mar 2002 08:49:31 +0100 Subject: proposed ptomaine agenda References: Message-ID: <3C91A78B.EC21C864@info.fundp.ac.be> Mark, > > Below is a proposed agenda for the PTOMAINE session Tuesday 1300-1400 at the > IETF next week. Please reply with any comments or suggestions. > > 1. > - Geoff Huston - NOPEER community for BGP route scope control > draft-huston-nopeer-00.txt > > 2. > - Russ White - presenting Olivier Bonaventure's draft - Controlling the > redistribution of BGP routes > http://www.info.fundp.ac.be/~obo/private/draf-bonaventure-bgp-redistribution > -02.txt The official version of this draft is available here : http://search.ietf.org/internet-drafts/draft-bonaventure-bgp-redistribution-02.txt This is a joint draft with Russ White, Jeffrey Haas, Stefaan De Cnodder and Bruno Quoitin > 3. > - Ted Hardie - Bounding Longest Match Considered > draft-hardie-bounded-longest-match-02.txt > > 4. Cathy Wittbrodt - giving Gert Doering's presentation on - IPv6 routing > scalability > Olivier From cjw at groovy.com Mon Mar 18 15:26:56 2002 From: cjw at groovy.com (CJW) Date: Mon, 18 Mar 2002 07:26:56 -0800 Subject: Slides for Ptomaine session Message-ID: <200203181526.g2IFQvY67838@duchess.groovy.com> Mark asked me to post these to the list. I'll be presenting Gert's slides (URL below) http://www.space.net/~gert/RIPE/R41-v6-table/ has now everything as one-GIF-per-Slide format, with mini-HTML around to click previous/next. See you there! ---CJ From Ted.Hardie at nominum.com Mon Mar 18 22:09:42 2002 From: Ted.Hardie at nominum.com (Ted Hardie) Date: Mon, 18 Mar 2002 14:09:42 -0800 Subject: Slides for bounded longest match presentation Message-ID: <20020318140942.C63970@shell.nominum.com> Hi, Attached are the slides for the bounded longest match presentation for ptomaine. My apologies; they are in ppt and I don't have time or tools to make them something saner before the meeting. Sorry about that, Ted -------------- next part -------------- A non-text attachment was scrubbed... Name: Bounding longest match considered.ppt Type: application/octet-stream Size: 32768 bytes Desc: not available Url : http://www.shrubbery.net/pipermail/ptomaine/attachments/20020318/81130ae8/attachment.obj From randy at psg.com Mon Mar 18 22:24:15 2002 From: randy at psg.com (Randy Bush) Date: Mon, 18 Mar 2002 16:24:15 -0600 Subject: Slides for bounded longest match presentation References: <20020318140942.C63970@shell.nominum.com> Message-ID: A non-text attachment was scrubbed... Name: blmc.pdf Type: application/pdf Size: 9550 bytes Desc: not available Url : http://www.shrubbery.net/pipermail/ptomaine/attachments/20020318/366bd792/attachment.pdf From gih at telstra.net Mon Mar 18 22:33:05 2002 From: gih at telstra.net (Geoff Huston) Date: Tue, 19 Mar 2002 09:33:05 +1100 Subject: slides for NOPEER Message-ID: <5.1.0.14.2.20020319092132.024a1ec0@localhost> Hi, The (3) slides for the draft-huston-nopeer-00.txt proposal can be found at: http://www.potaroo.net/papers/ietf/nopeer.pdf or (if you want ppt) http://www.potaroo.net/papers/ietf/nopeer.ppt regards, Geoff From ruwhite at cisco.com Tue Mar 19 16:13:49 2002 From: ruwhite at cisco.com (Russ White) Date: Tue, 19 Mar 2002 11:13:49 -0500 (EST) Subject: Controlling BGP Distribution Slides Message-ID: Are at: http://www.riw.to/temp/ in both ppt and pdf format, or should be. :-) Russ __________________________________ riw at cisco.com CCIE <>< Grace Alone From ruwhite at cisco.com Tue Mar 19 18:39:52 2002 From: ruwhite at cisco.com (Russ White) Date: Tue, 19 Mar 2002 13:39:52 -0500 (EST) Subject: Controlling BGP Distribution Slides In-Reply-To: Message-ID: Okay--I see that my web server isn't set up to handle this right. :-( Try these two: http://www.riw.to/temp/bgp-redist.pdf http://www.riw.to/temp/bgp-resist.ppt Gee, it's about time to set my web server up so I can manage these things more nicely.... :-) Russ On Tue, 19 Mar 2002, Russ White wrote: > > Are at: > > http://www.riw.to/temp/ > > in both ppt and pdf format, or should be. > > :-) > > Russ > > __________________________________ > riw at cisco.com CCIE <>< Grace Alone > > > __________________________________ riw at cisco.com CCIE <>< Grace Alone From mknopper at cisco.com Wed Mar 20 16:01:41 2002 From: mknopper at cisco.com (Mark Knopper) Date: Wed, 20 Mar 2002 11:01:41 -0500 Subject: draft ptomaine minutes Message-ID: PTOMAINE working group 19 March 2002 meeting summary > - Geoff Huston - NOPEER community for BGP route scope control > draft-huston-nopeer-00.txt The (3) slides for the draft-huston-nopeer-00.txt proposal can be found at: http://www.potaroo.net/papers/ietf/nopeer.pdf or (if you want ppt) http://www.potaroo.net/papers/ietf/nopeer.ppt It was agreed to make this a ptomaine wg document. > - Ted Hardie - Bounding Longest Match Considered > draft-hardie-bounded-longest-match-02.txt Presentation is at: http://bgp.nu/~mak/IETF/blmc.pdf http://bgp.nu/~mak/IETF/blmc.ppt Andrew Partan pointed out that there are cases where the announcer of the covering aggregrate *does not have a route* to the more specific. This was seen as an anomaly by Ted/Russ, but Andrew, Geoff, and Randy note that it is very common. This means that the bounding of the longest match must be constrained to those announcements where the next hop is common, which limits the utility of the proposal. It also means that odd other announcements which have the longer match but different next-hops get preferenced. Cengiz A. pointed out that we need to look at the data. Anyone who has pointers to relevant data should post to the list. Andrew: possible persistent route oscillation, as longer prefix may re-appear somewhere else. Ted and Russ will consider a plan to test, or at least provide an analytic proof that this works. It was agreed to keep discussing this draft in the working group. Ted/Russ will update to address the points above, and will resubmit. > - Russ White (riw at cisco.com) - Controlling the > redistribution of BGP routes > draft-bonaventure-bgp-redistribution-02.txt http://www.riw.to/temp/bgp-redist.pdf http://www.riw.to/temp/bgp-resist.ppt This is a joint draft with Russ White, Jeffrey Haas, Stefaan De Cnodder and Bruno Quoitin. - Requires use of extended communities, which not everyone uses. - Geoff: how do you know your specifics aren't leaking? It was agreed to make this a WG document. > Cathy Wittbrodt - presented Gert Doering's presentation on - IPv6 routing scalability http://www.space.net/~gert/RIPE/R41-v6-table/ has now everything as one-GIF-per-Slide format, with mini-HTML around to click previous/next. This presentation describes the global IPv6 routing table (yes, there is one...) growth resulting from use of BGP4++ on the combined 6bone and RIR. - Andrew: The martians (extra long AS path) may not be a BGP withdrawal bug. They may be a transient state due to BGP counting to infinity. Cathy to ask Gert about this. - Can the tunneled v6 AS paths be mapped to real geographic network paths? Other notes: - Please comment on WG charter: http://www.ietf.org/html.charters/ptomaine-charter.html - List archive is here: http://www.shrubbery.net/ptomaine - Abha's Merit page has been restored (thanks to Merit): http://www.merit.edu/~ahuja/ From post-ptomaine at partan.com Wed Mar 20 19:38:14 2002 From: post-ptomaine at partan.com (Andrew Partan) Date: Wed, 20 Mar 2002 14:38:14 -0500 Subject: BGP TTL Message-ID: <20020320143814.B933@partan.com> A brief discussion over lunch brought up the idea of adding a BGP attribute - a TTL - to limit how far (by AS count) a route will propogate. I.e.: set TTL to 1 and your route only goes to your neighbors. Set TTL to 2 and it only goes to your neighbors and their neighbors. It might also help to limit the BGP ASPATH count-to-infinity problem when you withdraw a route (as you will only count to the TTL). This may not be useful in all cases but I suspect that it would be useful in enough cases that I think we should add this tool. --asp From aditya at mighty.grot.org Wed Mar 20 19:55:50 2002 From: aditya at mighty.grot.org (Aditya) Date: Wed, 20 Mar 2002 11:55:50 -0800 Subject: BGP TTL In-Reply-To: <20020320143814.B933@partan.com> References: <20020320143814.B933@partan.com> Message-ID: <20020320195550.GA71512@mighty.grot.org> On Wed, Mar 20, 2002 at 02:38:14PM -0500, Andrew Partan wrote: > A brief discussion over lunch brought up the idea of adding a BGP > attribute - a TTL - to limit how far (by AS count) a route will > propogate. > > I.e.: set TTL to 1 and your route only goes to your neighbors. ie. community no-export > Set TTL to 2 and it only goes to your neighbors and their neighbors. > > It might also help to limit the BGP ASPATH count-to-infinity problem > when you withdraw a route (as you will only count to the TTL). > > This may not be useful in all cases but I suspect that it would be > useful in enough cases that I think we should add this tool. so could you give an example where you wouldn't use community no-export nor a pre-agreed upon community between multiple AS (neighbors and their neighbors) that this would be useful? NB. not questioning the idea, but just trying to envision where it might be useful. Adi From gih at telstra.net Wed Mar 20 20:00:31 2002 From: gih at telstra.net (Geoff Huston) Date: Thu, 21 Mar 2002 07:00:31 +1100 Subject: BGP TTL In-Reply-To: <20020320143814.B933@partan.com> Message-ID: <5.1.0.14.2.20020321065528.02042bd0@localhost> This has been a concept that has floated round for some time as a way of limiting scope for some fine-grained advertisements. The issue is that the network itself is quite dense (route-views sees an average AS path length of between 3 and 4.5 AS hops for each of the route-views peers) and the average AS path length for address prefixes is noted to be between 2.5 and 3.5 AS hops. The question for me is whether a TTL has any practical scope limitation in such a richly interconnected environment. Geoff At 3/21/2002 06:38 AM, Andrew Partan wrote: >A brief discussion over lunch brought up the idea of adding a BGP >attribute - a TTL - to limit how far (by AS count) a route will >propogate. > >I.e.: set TTL to 1 and your route only goes to your neighbors. >Set TTL to 2 and it only goes to your neighbors and their neighbors. > >It might also help to limit the BGP ASPATH count-to-infinity problem >when you withdraw a route (as you will only count to the TTL). > >This may not be useful in all cases but I suspect that it would be >useful in enough cases that I think we should add this tool. > > --asp From post-ptomaine at partan.com Wed Mar 20 20:07:20 2002 From: post-ptomaine at partan.com (Andrew Partan) Date: Wed, 20 Mar 2002 15:07:20 -0500 Subject: BGP TTL In-Reply-To: <20020320195550.GA71512@mighty.grot.org>; from aditya@mighty.grot.org on Wed, Mar 20, 2002 at 11:55:50AM -0800 References: <20020320143814.B933@partan.com> <20020320195550.GA71512@mighty.grot.org> Message-ID: <20020320150720.A22271@partan.com> On Wed, Mar 20, 2002 at 11:55:50AM -0800, Aditya wrote: > > I.e.: set TTL to 1 and your route only goes to your neighbors. > ie. community no-export Only if your neighbor listens to communities & does not strip any that they recieve. [Someone at lunch mentioned one ISP that wanted a guarentee that their neighbor would not propogate some routes & did not want to rely on setting no-export as that breaks too often.] > so could you give an example where you wouldn't use community no-export nor a > pre-agreed upon community between multiple AS (neighbors and their neighbors) > that this would be useful? You can use communities and cooperative configuration to make nearly anything work. However this is not the case fairly often in practice. You can attempt to get this done via cooperation and try to enforce this by checking route-servers and adding Ts&Cs to contracts, but it sure would be a lot easier if the protocol just did it. Its also a lot harder to get cooperation more than 1 AS hop away (assuming that you know all of those folks). --asp From post-ptomaine at partan.com Wed Mar 20 20:16:37 2002 From: post-ptomaine at partan.com (Andrew Partan) Date: Wed, 20 Mar 2002 15:16:37 -0500 Subject: BGP TTL In-Reply-To: <5.1.0.14.2.20020321065528.02042bd0@localhost>; from gih@telstra.net on Thu, Mar 21, 2002 at 07:00:31AM +1100 References: <20020320143814.B933@partan.com> <5.1.0.14.2.20020321065528.02042bd0@localhost> Message-ID: <20020320151637.B22271@partan.com> On Thu, Mar 21, 2002 at 07:00:31AM +1100, Geoff Huston wrote: > The issue is that the network itself is quite dense (route-views sees an > average AS path length of between 3 and 4.5 AS hops for each of the > route-views peers) and the average AS path length for address prefixes is > noted to be between 2.5 and 3.5 AS hops. > > The question for me is whether a TTL has any practical scope limitation in > such a richly interconnected environment. I thought about this some; settings of 1 or 2 would probably make the most sense in limiting the scope of the advertisement (much higher and you are probably reaching the entire internet anyhow). However even a setting of (say) 10 would limit the count-to-infinity problem - see, e.g.: the current 6bone & their *very* long AS paths. [As the 6bone today is mostly full of mutual-transit peerings, you can get some very long count-to-infinity paths.] --asp From michael.hallgren at Teleglobe.com Wed Mar 20 20:27:21 2002 From: michael.hallgren at Teleglobe.com (Hallgren, Michael) Date: Wed, 20 Mar 2002 20:27:21 -0000 Subject: BGP TTL Message-ID: > > On Wed, Mar 20, 2002 at 11:55:50AM -0800, Aditya wrote: > > > I.e.: set TTL to 1 and your route only goes to your neighbors. > > ie. community no-export > > Only if your neighbor listens to communities & does not strip any > that they recieve. [Someone at lunch mentioned one ISP that wanted > a guarentee that their neighbor would not propogate some routes & > did not want to rely on setting no-export as that breaks too often.] > Right. Genrally (from what I've seen around) community values signalled might be taken in account when from customers... but rarely (only special cases, like honoring MEDs by the way) from peers. Diverging experience and opinions welcome. > > so could you give an example where you wouldn't use > community no-export nor a > > pre-agreed upon community between multiple AS (neighbors > and their neighbors) > > that this would be useful? > > You can use communities and cooperative configuration to make nearly > anything work. However this is not the case fairly often in > practice. > > You can attempt to get this done via cooperation and try to enforce > this by checking route-servers and adding Ts&Cs to contracts, but > it sure would be a lot easier if the protocol just did it. Its > also a lot harder to get cooperation more than 1 AS hop away > (assuming that you know all of those folks). ... mh > > --asp > From cmartin at gnilink.net Wed Mar 20 20:25:23 2002 From: cmartin at gnilink.net (Martin, Christian) Date: Wed, 20 Mar 2002 15:25:23 -0500 Subject: BGP TTL Message-ID: <94B9091E1149D411A45C00508BACEB35015F2CA3@entmail.gnilink.com> > Only if your neighbor listens to communities & does not strip any > that they recieve. [Someone at lunch mentioned one ISP that wanted > a guarentee that their neighbor would not propogate some routes & > did not want to rely on setting no-export as that breaks too often.] Perhaps communities should become mandatory transitive attributes? Or, at a minimum, perhaps the default configuration (as is the case with one major vendor)? From what I am seeing, the current ptomaine work (aside from nopeer) is heavily reliant on communities, which as you suggest, often are broken. There have been many a route leakage because one peer was not configured to propagate communities. regards, -chris From pekkas at netcore.fi Wed Mar 20 20:25:54 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 20 Mar 2002 22:25:54 +0200 (EET) Subject: BGP TTL In-Reply-To: <20020320151637.B22271@partan.com> Message-ID: On Wed, 20 Mar 2002, Andrew Partan wrote: > However even a setting of (say) 10 would limit the count-to-infinity > problem - see, e.g.: the current 6bone & their *very* long AS paths. > [As the 6bone today is mostly full of mutual-transit peerings, you > can get some very long count-to-infinity paths.] Just as an aside: the huge AS-paths were thought to be an implementation bug (discussed on 6bone at isi.edu list) which generates bogus routes. I believe the culprit was already found and fixed, but then those routes re-appeared again, so probably not.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From pekkas at netcore.fi Wed Mar 20 20:37:36 2002 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 20 Mar 2002 22:37:36 +0200 (EET) Subject: BGP TTL In-Reply-To: <94B9091E1149D411A45C00508BACEB35015F2CA3@entmail.gnilink.com> Message-ID: On Wed, 20 Mar 2002, Martin, Christian wrote: > > Only if your neighbor listens to communities & does not strip any > > that they recieve. [Someone at lunch mentioned one ISP that wanted > > a guarentee that their neighbor would not propogate some routes & > > did not want to rely on setting no-export as that breaks too often.] > > Perhaps communities should become mandatory transitive attributes? Not sure if that's a good idea. Communities can clash, and they often only make sense if explicitly configured to do so. It definitely doesn't sound good to accumulate all the communities from along the AS-PATH of e.g. length 10 at the last AS. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From matthew.ford at bt.com Wed Mar 20 20:47:13 2002 From: matthew.ford at bt.com (matthew.ford at bt.com) Date: Wed, 20 Mar 2002 20:47:13 -0000 Subject: BGP TTL Message-ID: > However even a setting of (say) 10 would limit the count-to-infinity > problem - see, e.g.: the current 6bone & their *very* long AS paths. > [As the 6bone today is mostly full of mutual-transit peerings, you > can get some very long count-to-infinity paths.] Just as an aside: the huge AS-paths were thought to be an implementation bug (discussed on 6bone at isi.edu list) which generates bogus routes. I believe the culprit was already found and fixed, but then those routes re-appeared again, so probably not.. => which makes me think that the supposed BGP withdrawal bug is a red-herring and the problem is in fact the count-to-infinity behaviour as discussed in ptomaine. Time to start filtering on the 6bone... -- Mat. From gih at telstra.net Wed Mar 20 20:48:42 2002 From: gih at telstra.net (Geoff Huston) Date: Thu, 21 Mar 2002 07:48:42 +1100 Subject: BGP TTL In-Reply-To: <20020320151637.B22271@partan.com> References: <5.1.0.14.2.20020321065528.02042bd0@localhost> <20020320143814.B933@partan.com> <5.1.0.14.2.20020321065528.02042bd0@localhost> Message-ID: <5.1.0.14.2.20020321073742.02059ba0@localhost> At 3/21/2002 07:16 AM, Andrew Partan wrote: >However even a setting of (say) 10 would limit the count-to-infinity >problem - see, e.g.: the current 6bone & their *very* long AS paths. >[As the 6bone today is mostly full of mutual-transit peerings, you >can get some very long count-to-infinity paths.] max AS path length in the V4 BGP world ppears to be somewhere between 11 and 22 (http://www.potaroo.net//bgp2/as6447/bgp-max-aspath-length.html) and if you keep AS path prepending the number is between 25 and 32 (http://www.potaroo.net//bgp2/as6447/bgp-max-p-aspath-length.html) (This view uses the route-views data) Implies to me that a count to inifinity block TTL in V4 BGP is safely set at 64, although what you are stopping is not count to infinity per se a degnerate case of BGP timers interacting (at this point I wave my hands and point to Craig Labovitz' work where he explained the situations leading to various sub-forms of BGP count to infinity!) Geoff From heas at shrubbery.net Wed Mar 20 21:14:39 2002 From: heas at shrubbery.net (john heasley) Date: Wed, 20 Mar 2002 13:14:39 -0800 Subject: BGP TTL In-Reply-To: ; from pekkas@netcore.fi on Wed, Mar 20, 2002 at 10:37:36PM +0200 References: <94B9091E1149D411A45C00508BACEB35015F2CA3@entmail.gnilink.com> Message-ID: <20020320131438.D4911@shrubbery.net> Wed, Mar 20, 2002 at 10:37:36PM +0200, Pekka Savola: > On Wed, 20 Mar 2002, Martin, Christian wrote: > > > Only if your neighbor listens to communities & does not strip any > > > that they recieve. [Someone at lunch mentioned one ISP that wanted > > > a guarentee that their neighbor would not propogate some routes & > > > did not want to rely on setting no-export as that breaks too often.] > > > > Perhaps communities should become mandatory transitive attributes? > > Not sure if that's a good idea. Communities can clash, and they often > only make sense if explicitly configured to do so. no, it isnt a good idea, particularly if what is meant is that values can not be deleted. enforcing 65535:* to remain once added as well as exchange of communities being mandatory might not be a bad idea though. > It definitely doesn't sound good to accumulate all the communities from > along the AS-PATH of e.g. length 10 at the last AS. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From post-ptomaine at partan.com Wed Mar 20 22:30:17 2002 From: post-ptomaine at partan.com (Andrew Partan) Date: Wed, 20 Mar 2002 17:30:17 -0500 Subject: BGP TTL In-Reply-To: <94B9091E1149D411A45C00508BACEB35015F2CA3@entmail.gnilink.com>; from cmartin@gnilink.net on Wed, Mar 20, 2002 at 03:25:23PM -0500 References: <94B9091E1149D411A45C00508BACEB35015F2CA3@entmail.gnilink.com> Message-ID: <20020320173017.A9705@partan.com> On Wed, Mar 20, 2002 at 03:25:23PM -0500, Martin, Christian wrote: > Perhaps communities should become mandatory transitive attributes? That is not a good idea. You still need to block communities you use internally so others can't effect your router. Ideal provider config is - strip all communities you use for internal markers on input - act on all communities you tell you customers they may use - strip all your communities on output - let all other communities thru untouched --asp From heas at shrubbery.net Wed Mar 20 23:27:11 2002 From: heas at shrubbery.net (john heasley) Date: Wed, 20 Mar 2002 15:27:11 -0800 Subject: BGP TTL In-Reply-To: <20020320173017.A9705@partan.com>; from post-ptomaine@partan.com on Wed, Mar 20, 2002 at 05:30:17PM -0500 References: <94B9091E1149D411A45C00508BACEB35015F2CA3@entmail.gnilink.com> <20020320173017.A9705@partan.com> Message-ID: <20020320152711.M21419@shrubbery.net> Wed, Mar 20, 2002 at 05:30:17PM -0500, Andrew Partan: > On Wed, Mar 20, 2002 at 03:25:23PM -0500, Martin, Christian wrote: > > Perhaps communities should become mandatory transitive attributes? > > That is not a good idea. You still need to block communities you use > internally so others can't effect your router. > > Ideal provider config is > - strip all communities you use for internal markers on input > - act on all communities you tell you customers they may use > - strip all your communities on output > - let all other communities thru untouched do folks (teir-1s) actually leak customer initiated/added communities through to their peers? any actually listen to communities from their peers? From mknopper at cisco.com Wed Mar 20 23:20:37 2002 From: mknopper at cisco.com (Mark Knopper) Date: Wed, 20 Mar 2002 18:20:37 -0500 Subject: revised- ptomaine minutes Message-ID: Please note minor added comment regarding Joel Halpern's question regarding BGP communities. Mark ==== PTOMAINE working group 19 March 2002 meeting summary > - Geoff Huston - NOPEER community for BGP route scope control > draft-huston-nopeer-00.txt The (3) slides for the draft-huston-nopeer-00.txt proposal can be found at: http://www.potaroo.net/papers/ietf/nopeer.pdf or (if you want ppt) http://www.potaroo.net/papers/ietf/nopeer.ppt It was agreed to make this a ptomaine wg document. > - Ted Hardie - Bounding Longest Match Considered > draft-hardie-bounded-longest-match-02.txt Presentation is at: http://bgp.nu/~mak/IETF/blmc.pdf http://bgp.nu/~mak/IETF/blmc.ppt Andrew Partan pointed out that there are cases where the announcer of the covering aggregrate *does not have a route* to the more specific. This was seen as an anomaly by Ted/Russ, but Andrew, Geoff, and Randy note that it is very common. This means that the bounding of the longest match must be constrained to those announcements where the next hop is common, which limits the utility of the proposal. It also means that odd other announcements which have the longer match but different next-hops get preferenced. Joel Halpern asked a question about BGP communities--whether customers of ISPs who are supporting the current mechanisms are actually using those mechanisms. He received a resounding yes. Cengiz A. pointed out that we need to look at the data. Anyone who has pointers to relevant data should post to the list. Andrew: possible persistent route oscillation, as longer prefix may re-appear somewhere else. Ted and Russ will consider a plan to test, or at least provide an analytic proof that this works. It was agreed to keep discussing this draft in the working group. Ted/Russ will update to address the points above, and will resubmit. > - Russ White (riw at cisco.com) - Controlling the > redistribution of BGP routes > draft-bonaventure-bgp-redistribution-02.txt http://www.riw.to/temp/bgp-redist.pdf http://www.riw.to/temp/bgp-resist.ppt This is a joint draft with Russ White, Jeffrey Haas, Stefaan De Cnodder and Bruno Quoitin. - Requires use of extended communities, which not everyone uses. - Geoff: how do you know your specifics aren't leaking? It was agreed to make this a WG document. > Cathy Wittbrodt - presented Gert Doering's presentation on - IPv6 routing scalability http://www.space.net/~gert/RIPE/R41-v6-table/ has now everything as one-GIF-per-Slide format, with mini-HTML around to click previous/next. This presentation describes the global IPv6 routing table (yes, there is one...) growth resulting from use of BGP4++ on the combined 6bone and RIR. - Andrew: The martians (extra long AS path) may not be a BGP withdrawal bug. They may be a transient state due to BGP counting to infinity. Cathy to ask Gert about this. - Can the tunneled v6 AS paths be mapped to real geographic network paths? Other notes: - Please comment on WG charter: http://www.ietf.org/html.charters/ptomaine-charter.html - List archive is here: http://www.shrubbery.net/ptomaine - Abha's Merit page has been restored (thanks to Merit): http://www.merit.edu/~ahuja/ From jabley at automagic.org Thu Mar 21 00:12:47 2002 From: jabley at automagic.org (Joe Abley) Date: Wed, 20 Mar 2002 19:12:47 -0500 Subject: BGP TTL In-Reply-To: <20020320152711.M21419@shrubbery.net> Message-ID: <5FB6B722-3C60-11D6-8C04-00039312C852@automagic.org> On Wednesday, March 20, 2002, at 06:27 , john heasley wrote: > do folks (teir-1s) actually leak customer initiated/added communities > through to their peers? any actually listen to communities from their > peers? 6461 doesn't, if you're collecting data points (no to both). Joe From jabley at automagic.org Thu Mar 21 00:03:44 2002 From: jabley at automagic.org (Joe Abley) Date: Wed, 20 Mar 2002 19:03:44 -0500 Subject: BGP TTL In-Reply-To: <5.1.0.14.2.20020321073742.02059ba0@localhost> Message-ID: <1C6BA31C-3C5F-11D6-8C04-00039312C852@automagic.org> On Wednesday, March 20, 2002, at 03:48 , Geoff Huston wrote: > At 3/21/2002 07:16 AM, Andrew Partan wrote: >> However even a setting of (say) 10 would limit the count-to-infinity >> problem - see, e.g.: the current 6bone & their *very* long AS paths. >> [As the 6bone today is mostly full of mutual-transit peerings, you >> can get some very long count-to-infinity paths.] > > max AS path length in the V4 BGP world ppears to be somewhere between > 11 and 22 (http://www.potaroo.net//bgp2/as6447/bgp-max-aspath- > length.html) > > and if you keep AS path prepending the number is between 25 and 32 > (http://www.potaroo.net//bgp2/as6447/bgp-max-p-aspath-length.html) > > (This view uses the route-views data) A histogram of number of paths vs. ASN hops might also be interesting. I just tried to do a "show ip bgp path" on route-views, but it kicked me out before it was complete (probably fair enough; there are LOTS of paths on that router) but here's a histogram from AS6461: 1 ASNs (0.01%) are 0 AS-hops away 565 ASNs (4.57%) are 1 AS-hops away 7373 ASNs (59.62%) are 2 AS-hops away 3369 ASNs (27.24%) are 3 AS-hops away 798 ASNs (6.45%) are 4 AS-hops away 229 ASNs (1.85%) are 5 AS-hops away 29 ASNs (0.23%) are 6 AS-hops away 2 ASNs (0.02%) are 7 AS-hops away 1 ASNs (0.01%) are 8 AS-hops away Similar histograms based on path info from other prominent ISPs (Level3, Verio, UU) have a similar-shaped distribution. This suggests that a TTL-style knob would be a fairly coarse control if applied from 6461; by the time a route has propagated into three ASes you have already inflicted it upon 91% of the ASes in the network. I suspect the general spike seen around 2-3 AS hops above is going to be common to the view from most networks, so a less-central AS still doesn't get much control (it goes "nobody sees it, a few people see it, a few more people, a few more, woah, half the internet sees it, most of the other half also sees it," and trails off from there). I like the TTL idea; Ben Black scribbled something similar on the back of an envelope after the IDR meeting in Minneapolis last time. But I don't think it's going to be useful while the network is so centralised on a relatively dense central mesh of ASes. Joe (awk script to generate the output above follows; pipe the output of "show ip bgp path" on a cisco into it) #!/usr/bin/awk -f /^0x/ { cl = 0; asn = ""; for (i = 5; i < NF; i++) { if (cl == 0) { asn = $i; cl++; } else { if (asn != $i) { asn = $i; cl++; } } } if (shortest[asn] > cl || shortest[asn] == "") shortest[asn] = cl; } END { t = 0; for (n in shortest) { hist[shortest[n]]++; t++; } for (n in hist) printf "%d ASNs (%2.2f%%) are %d AS-hops away\n", hist[n], 100*hist[n]/t, n; } From gih at telstra.net Thu Mar 21 01:59:34 2002 From: gih at telstra.net (Geoff Huston) Date: Thu, 21 Mar 2002 12:59:34 +1100 Subject: BGP TTL In-Reply-To: <1C6BA31C-3C5F-11D6-8C04-00039312C852@automagic.org> References: <5.1.0.14.2.20020321073742.02059ba0@localhost> Message-ID: <5.1.0.14.2.20020321125200.045b1e50@localhost> Joe Abley wrote: >I like the TTL idea; Ben Black scribbled something similar on the back of >an envelope after the IDR meeting in Minneapolis last time. But I don't >think it's going to be useful while the network is so centralised on a >relatively dense central mesh of ASes. I've been looking at this AS distribution by AS path length for some months now (http://www.potaroo.net/bgp2/1221/bgp-pasbyhop-vector.html) is an example, and the observation is that its getting shorter, not longer. The dense, central mesh appears to be getting denser. (a presentation that includes some observations on this is at http://www.potaroo.net/papers/bgp/bgp-2001.pdf) Geoff From gih at telstra.net Thu Mar 21 01:24:39 2002 From: gih at telstra.net (Geoff Huston) Date: Thu, 21 Mar 2002 12:24:39 +1100 Subject: BGP TTL In-Reply-To: <1C6BA31C-3C5F-11D6-8C04-00039312C852@automagic.org> References: <5.1.0.14.2.20020321073742.02059ba0@localhost> Message-ID: <5.1.0.14.2.20020321120850.00a4bc50@localhost> >At 3/21/2002 07:16 AM, Andrew Partan wrote: >>However even a setting of (say) 10 would limit the count-to-infinity >>problem - see, e.g.: the current 6bone & their *very* long AS paths. >>[As the 6bone today is mostly full of mutual-transit peerings, you >>can get some very long count-to-infinity paths.] Following on from Jo's quick snapshot, you can see a set of AS path length histograms for a whole set of route-views peers at http://www.potaroo.net/bgp They all show some form of strong clustering of AS's at a distance of between 2 and 4 AS's. But more to the point, I now have had time to wonder why a BGP AS TTL is necessary for the count to infinity problem. I can't understand what the problem is, frankly, and maybe an explanation would help educate a poor dumb operator such a myself. Let me explain my ignorance: Now that I'm away from noisy crowded meeting rooms, I recall that Craig and Abha's work on BGP instability indicated that, under certain timing conditions, BGP would explore a whole set of alternate AS paths for a prefix at a constant AS Path length, as I recall, which in turn created a lengthy time for a remote listener to see the BGP advertisement to withdraw completely. What was not there was count to infinity. Of course what is happening here is that because BGP maintains an AS path vector, count to infinity is not a count through a loop, but its a potential count through ever-longer bogus AS paths until the original withdraw manages to catch up with the wave of bogus announcements. As I understand it (and being wrong is quite a probability!) this could conceivably be caused by a progressive condition where a withdraw proceeds very slowly through BGP along one set of paths, while the same withdraw proceeds quickly through another set. The set of AS's which see the faster withdraw may see an update from an AS where the withdraw has not yet propagated and learn that as an alternate path, and propagate that. In practice I'm not sure that this behavior is susceptible to damping by an AS Path TTL. So I don't understand - if AS path TTLS are a Good Idea, what is the errant BGP behaviour that makes it a Good Idea? Thanks, Geoff From Olivier.Bonaventure at info.fundp.ac.be Thu Mar 21 08:17:13 2002 From: Olivier.Bonaventure at info.fundp.ac.be (Olivier Bonaventure) Date: Thu, 21 Mar 2002 09:17:13 +0100 Subject: BGP TTL References: <94B9091E1149D411A45C00508BACEB35015F2CA3@entmail.gnilink.com> <20020320173017.A9705@partan.com> <20020320152711.M21419@shrubbery.net> Message-ID: <3C999709.678584AF@info.fundp.ac.be> Hello, > Wed, Mar 20, 2002 at 05:30:17PM -0500, Andrew Partan: > > On Wed, Mar 20, 2002 at 03:25:23PM -0500, Martin, Christian wrote: > > > Perhaps communities should become mandatory transitive attributes? > > > > That is not a good idea. You still need to block communities you use > > internally so others can't effect your router. > > Ideal provider config is > > - strip all communities you use for internal markers on input > > - act on all communities you tell you customers they may use > > - strip all your communities on output > > > - let all other communities thru untouched It would probably be useful to think about using the extended communities instead of the normal communities since extended communities will be easier to handle, see e.g. the transitive/non-transitive bit. > do folks (teir-1s) actually leak customer initiated/added communities > through to their peers? any actually listen to communities from their > peers? We did a survey of the utilization of the BGP communities based on the RIPE whois database and on the BGP tables collected by RIPE RIS and Routeviews in January. This survey shows that many ISPs support communities and have defined their own communities, including tier-1 ISPs and that several ISPs allow those communities to leak through their peer. More information about this survey is available in an internet draft that will be officially announced next week but is already available as : http://www.infonet.fundp.ac.be/doc/tr/Infonet-TR-2002-02.html The raw data summarised in the survey is available from http://alpha.infonet.fundp.ac.be/anabgp/ If you would like to have other informations about the utilization of the BGP communities, let us know. Best regards, Olivier Bonaventure -- http://www.infonet.fundp.ac.be From kurtis at kpnqwest.net Thu Mar 21 10:15:04 2002 From: kurtis at kpnqwest.net (Kurt Erik Lindqvist KPNQwest) Date: Thu, 21 Mar 2002 11:15:04 +0100 (MET) Subject: BGP TTL In-Reply-To: <20020320143814.B933@partan.com> Message-ID: > A brief discussion over lunch brought up the idea of adding a BGP > attribute - a TTL - to limit how far (by AS count) a route will > propogate. > > I.e.: set TTL to 1 and your route only goes to your neighbors. > Set TTL to 2 and it only goes to your neighbors and their neighbors. > > It might also help to limit the BGP ASPATH count-to-infinity problem > when you withdraw a route (as you will only count to the TTL). > > This may not be useful in all cases but I suspect that it would be > useful in enough cases that I think we should add this tool. Hmm, do you mean this would be dropped when receiving? I am just afraid this would slow down convergence and route acceptance at a larger outage... - kurtis - From heas at shrubbery.net Thu Mar 21 17:23:04 2002 From: heas at shrubbery.net (john heasley) Date: Thu, 21 Mar 2002 09:23:04 -0800 Subject: BGP TTL In-Reply-To: <3C999709.678584AF@info.fundp.ac.be>; from Olivier.Bonaventure@info.fundp.ac.be on Thu, Mar 21, 2002 at 09:17:13AM +0100 References: <94B9091E1149D411A45C00508BACEB35015F2CA3@entmail.gnilink.com> <20020320173017.A9705@partan.com> <20020320152711.M21419@shrubbery.net> <3C999709.678584AF@info.fundp.ac.be> Message-ID: <20020321092304.D5987@shrubbery.net> Thu, Mar 21, 2002 at 09:17:13AM +0100, Olivier Bonaventure: > Hello, > > > Wed, Mar 20, 2002 at 05:30:17PM -0500, Andrew Partan: > > > On Wed, Mar 20, 2002 at 03:25:23PM -0500, Martin, Christian wrote: > > > > Perhaps communities should become mandatory transitive attributes? > > > > > > That is not a good idea. You still need to block communities you use > > > internally so others can't effect your router. > > > Ideal provider config is > > > - strip all communities you use for internal markers on input > > > - act on all communities you tell you customers they may use > > > - strip all your communities on output > > > > > - let all other communities thru untouched > > > It would probably be useful to think about using the extended communities instead > of the normal communities since extended communities will be easier to handle, > see e.g. the transitive/non-transitive bit. > > > do folks (teir-1s) actually leak customer initiated/added communities > > through to their peers? any actually listen to communities from their > > peers? > > We did a survey of the utilization of the BGP communities based on the RIPE > whois database and on the BGP tables collected by RIPE RIS and Routeviews > in January. This survey shows that many ISPs support communities and have defined > their own communities, including tier-1 ISPs and that several ISPs allow > those communities to leak through their peer. More information about this > survey is available in an internet draft that will be officially announced next week > but is already available as : > > http://www.infonet.fundp.ac.be/doc/tr/Infonet-TR-2002-02.html > > The raw data summarised in the survey is available from > > http://alpha.infonet.fundp.ac.be/anabgp/ looks like a lot of polution to me. we do not leak communities handed to us from ebgp or our numerous internal markings. 2914:410 <<<<< our route or learned from a customer unknown learned from AS2914 (6828 routes) 2914:420 <<<<< learned from a peer unknown learned from AS2914 (83100 routes) any other 2914: marking is rogue. > If you would like to have other informations about the utilization of the > BGP communities, let us know. > > Best regards, > > Olivier Bonaventure > > -- > http://www.infonet.fundp.ac.be From post-ptomaine at partan.com Thu Mar 21 20:50:40 2002 From: post-ptomaine at partan.com (Andrew Partan) Date: Thu, 21 Mar 2002 15:50:40 -0500 Subject: BGP TTL In-Reply-To: ; from kurtis@kpnqwest.net on Thu, Mar 21, 2002 at 11:15:04AM +0100 References: <20020320143814.B933@partan.com> Message-ID: <20020321155040.A21590@partan.com> On Thu, Mar 21, 2002 at 11:15:04AM +0100, Kurt Erik Lindqvist KPNQwest wrote: > Hmm, do you mean this would be dropped when receiving? I am just afraid > this would slow down convergence and route acceptance at a larger > outage... Its another way of doing route filtering. It does add a bit to the work at the eBGP border, but it should be a simple: if TTL == 0 then drop else TTL-- --asp From micklesc at aol.net Thu Mar 21 23:01:47 2002 From: micklesc at aol.net (Cleve Mickles) Date: Thu, 21 Mar 2002 18:01:47 -0500 Subject: Slides for Ptomaine session In-Reply-To: <200203181526.g2IFQvY67838@duchess.groovy.com> Message-ID: Hi Cathy, I noticed in your slide 8 that you picked up a "short lived" IPv6 prefix and announcement we received from ARIN. We initially received 2001:4B00::/35 and a couple months later ARIN made a correction to the allocation which placed us within the ARIN allocated IPv6 range(ie 2001:04B0::/35). Did anyone point this out during the discussion? There were a few folks aware of why the prefx showed up in the routing tables. If not, I'll take my 50 lashes. Thanks, Cleve... > -----Original Message----- > From: owner-ptomaine at shrubbery.net > [mailto:owner-ptomaine at shrubbery.net]On Behalf Of CJW > Sent: Monday, March 18, 2002 10:27 AM > To: ptomaine at shrubbery.net > Subject: Slides for Ptomaine session > > > > Mark asked me to post these to the list. I'll be presenting Gert's slides > (URL below) > > http://www.space.net/~gert/RIPE/R41-v6-table/ has now everything > as one-GIF-per-Slide format, with mini-HTML around to click > previous/next. > > See you there! > ---CJ > Cleve Mickles Network Architect America Online, Network Operations From danny at tcb.net Fri Mar 22 03:03:33 2002 From: danny at tcb.net (Danny McPherson) Date: Thu, 21 Mar 2002 20:03:33 -0700 Subject: Slides for Ptomaine session Message-ID: <200203220303.g2M33YH24436@tcb.net> > Did anyone point this out during the > discussion? There were a few folks aware > of why the prefx showed up in the routing > tables. If not, I'll take my 50 lashes. Nope. It was only discussed that AOL mis-typed the address. This explains the root cause... -danny From cwhyte at microsoft.com Fri Mar 22 03:51:56 2002 From: cwhyte at microsoft.com (Chris Whyte) Date: Thu, 21 Mar 2002 19:51:56 -0800 Subject: BGP TTL Message-ID: > > On Wednesday, March 20, 2002, at 06:27 , john heasley wrote: > > > do folks (teir-1s) actually leak customer initiated/added > communities > > through to their peers? any actually listen to communities > from their > > peers? > > 6461 doesn't, if you're collecting data points (no to both). This is very true of course but I can see value in receiving communities from peers too. For example, one might want to use a tool that can provide you with the amount of traffic destined for a specific community that represents a geography in your peer's network. As tools develop in this area, which they are, I can see communities being useful to get other traffic or performance-related data. Thanks, Chris > > > Joe > > From danny at tcb.net Fri Mar 22 04:31:34 2002 From: danny at tcb.net (Danny McPherson) Date: Thu, 21 Mar 2002 21:31:34 -0700 Subject: BGP TTL Message-ID: <200203220431.g2M4VYV24886@tcb.net> 'course, in this world of closest-exit inter-domain routing, one can with certainty assign new community values on ingress and get a reasonable idea of geographic distribution of data sources on the peers network. Of course, this is assuming MED brokenness or other policy isn't skewing "good ole closest-exit" path selection. Not only would conflicting assignments be an issue, but I'm guessing that with the number of available paths impacting Adj-RIB-In size today, a default "additive" community policy would result in a notable impact in memory utilization. The work we're seeing from lots of folks is attempting to scope advertisement of "distant" policy for this and other reasons, not multiply it. -danny > This is very true of course but I can see value in receiving communities > from peers too. For example, one might want to use a tool that can > provide you with the amount of traffic destined for a specific community > that represents a geography in your peer's network. As tools develop in > this area, which they are, I can see communities being useful to get > other traffic or performance-related data. From micklesc at aol.net Fri Mar 22 04:47:22 2002 From: micklesc at aol.net (Cleve Mickles) Date: Thu, 21 Mar 2002 23:47:22 -0500 Subject: Slides for Ptomaine session In-Reply-To: <200203220303.g2M33YH24436@tcb.net> Message-ID: I took a look at the remaining slides...The routing announcement wasn't a typo. We generally trust the allocations we get from the registries and changed the BGP announcement when we received the update from the registry. We have a strict inbound and outbound BGP filtering policy for our V6 peers to prevent us/AOL from announcing things we should not. In the future, we should trust but verify what we get from the registries. We should have questioned the allocation when we received it initially. I'd be curious to know what caused them to notice and correct our allocation? Was it our annoucement or an internal audit? Cleve... > -----Original Message----- > From: owner-ptomaine at shrubbery.net > [mailto:owner-ptomaine at shrubbery.net]On Behalf Of Danny McPherson > Sent: Thursday, March 21, 2002 10:04 PM > To: ptomaine at shrubbery.net > Subject: Re: Slides for Ptomaine session > > > > > > Did anyone point this out during the > > discussion? There were a few folks aware > > of why the prefx showed up in the routing > > tables. If not, I'll take my 50 lashes. > > Nope. It was only discussed that AOL mis-typed > the address. This explains the root cause... > > -danny > > From cwhyte at microsoft.com Fri Mar 22 21:02:17 2002 From: cwhyte at microsoft.com (Chris Whyte) Date: Fri, 22 Mar 2002 13:02:17 -0800 Subject: BGP TTL Message-ID: > > 'course, in this world of closest-exit inter-domain routing, > one can with certainty assign new community values on ingress > and get a reasonable idea of geographic distribution of data > sources on the peers network. Of course, this is assuming > MED brokenness or other policy isn't skewing "good ole > closest-exit" path selection. > > Not only would conflicting assignments be an issue, but I'm > guessing that with the number of available paths impacting > Adj-RIB-In size today, a default "additive" community policy > would result in a notable impact in memory utilization. Yes, but not all of us are tier-1s, and probably (hopefully?) never will be, so keep in mind that there are some of us out there who don't have >1.5M paths and 'additive' is a perfectly fine thing to do in our network today and the foreseeable future. > > The work we're seeing from lots of folks is attempting to scope > advertisement of "distant" policy for this and other reasons, > not multiply it. I don't think a peer advertising someone like me communities multiplies the problem but then maybe I don't thoroughly understand the problem. Again, there are many of us out there who aren't transit free and, therefore, have slightly different requirements for traffic and performance analysis. I believe communities can help us in gathering that information. Thanks, Chris > > -danny > > > > This is very true of course but I can see value in > receiving communities > > from peers too. For example, one might want to use a tool that can > > provide you with the amount of traffic destined for a > specific community > > that represents a geography in your peer's network. As > tools develop in > > this area, which they are, I can see communities being useful to get > > other traffic or performance-related data. > >