update [Re: routeviews down?]
We're back now. Please let us know ([EMAIL PROTECTED]) if you notice anything "strange". Thanks, and sorry again for the inconvenience. Dave signature.asc Description: Digital signature
Brief update [Re: routeviews down?]
I'm down in the Oregon Hall switch room and what I see is that it appears one of the power transfer switches we had failed and shorted out between two UPSs. Most things are back up, with the notable exception of archive.routeviews.org (which is fscking at the moment; which is going to take awhile). I'll update you all as soon as I have additional information. Thank you for your patience, and sorry about the inconvenience. Dave signature.asc Description: Digital signature
Re: routeviews down?
On Thu, Nov 08, 2007 at 09:09:56AM -0600, Ryan Harden wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Our BGP Session to them has been up and down several times over the last > few days, but is currently up. Yeah, the problem was power in the UO switch room power distribution. Suffice it to say that there have been multiple failures over the past few days. Dave signature.asc Description: Digital signature
Re: routeviews down?
On Thu, Nov 08, 2007 at 06:54:27AM -0800, Randy Bush wrote: > > it seems to be broken in a number of ways. i reported a few hours ago. We're having problems with switch room power. We're working on it. Sorry about the inconvenience. Dave signature.asc Description: Digital signature
Re: rv2 outage
On Mon, Aug 20, 2007 at 01:50:53AM -0400, tariq biziou wrote: > >Although I have still NOT seen any evidence to either support > >or dispell this report, I did see this report regarding some > >sort of "show ip bgp regexp" DoS exploit circulating on Friday: > > > show ip bgp regexp (.*)(_\1)+ > Vendor C, please fix. We've worked around this one using tacas on route-views while waiting for a suitable image that has a fix. Dave signature.asc Description: Digital signature
Re: [funsec] Not so fast, broadband providers tell big users (fwd)
On Tue, Mar 13, 2007 at 03:45:07PM +, Chris L. Morrow wrote: > > > > On Tue, 13 Mar 2007, Roland Dobbins wrote: > > > > > > > On Mar 13, 2007, at 8:17 AM, Chris L. Morrow wrote: > > > > > what business drivers are there to put more bits on the wire to > > > the end user? > > > > BitTorrent. > > which uses all available bandwidth on the user link, and can/does play > nicely with other user apps... It's not a reason for $TELCO to want to add > more BW to your link though. > > I suppose what I was asking is: Is there a better/faster/cheaper > alternative to your 2 incumbant solutions $TELCO || $CABLECO ? > > If there were then I bet $TELCO || $CABLECO would drop prices and speed up > links... since there isn't I think we're all lucky we're not still using a > 110baud coupler modem :) This is part of the "perfect storm" puzzle (basically, "access monopolies are weakened or cease to exist"). See http://www.1-4-5.net/~dmm/talks/apricot2007/perfect_storm for the most recent incarnation of this stuff. Long story short is that this (the whole situation with access networks) is perhaps the most controversial/weakest part of the story. > > And on-demand DVR-type things which I believe will grow in > > popularity. Of course, most of those are overlays which the SPs > > themselves don't offer; when they wish to do so, it'll become an > > issue, IMHO. > > again, these are user apps that depend on the higher BW available, they > don't drive the business to change, really. It seems to me that currently > the DVR/on-demand folks are basically walking the ledge hoping that as > they bring new features the telco's/cableco's will play nice and add > bandwidth to make these services 'work'... That might not last, there > certainly is no real reason that $TELCO || $CABLECO would be driven to > change, aside from 'goodness of their hearts' or 'hey maybe we want to > increase BW so we can offer a spiffy DVR-ish thing to our customers and > get more revenue on our flagging last-mile circuits?' Its hard to say. There's a relatively new (well, last Feb) paper by David Levinson and Andrew Odlyzko entitled "Too expensive to meter: The influence of transaction costs in transportation and communication" [0] that tries to use economic theory and some historical perspective (in particular, on the funding and congestion models for roads) shed some light on this. Its worth reading as it gives some insight as to where all of this may be going, but as usual, its a cloudy crystal ball. --dmm [0] http://www.dtc.umn.edu/~odlyzko/doc/metering-expensive.pdf pgpo7rI6Ig3QA.pgp Description: PGP signature
Re: RIS [Re: AS41961 not seen in many networks]
> (and we are always interested in any suggestions to improve RIS) Likewise routeviews. Let us know if there are peerings folks would like us to pick up. --dmm pgpAPYKudUw2t.pgp Description: PGP signature
Addresses of the Route Views (Oregon) collectors are changing
Over the next few weeks the addresses of the four Route Views collectors in Oregon are changing: Collector Old Address New Address route-views.routeviews.org128.223.60.103 128.223.51.103 route-views2.routeviews.org 128.223.60.102 128.223.51.102 route-views3.routeviews.org 128.223.60.108 128.223.51.108 route-views6.routeviews.org 128.223.60.194 128.223.51.194 If you currently peer with one of these collectors, we'll be emailing you further information on the specific timing and details of the changes. If you access the collectors via telnet, be aware that at some point in the next few weeks the new address will become active. There will be a period of time when both addresses can be used, and then the old address will be decommissioned. See http://www.routeviews.org/renumber.html for any updates to this plan, and to find out current status. Please send any questions to [EMAIL PROTECTED] Thanks, The Route Views Team pgpliId6ZoxSK.pgp Description: PGP signature
Re: Removal of my name
On Wed, Sep 20, 2006 at 02:59:47PM -0400, Derek J. Balling wrote: > An e-mail message *can* in fact, be HTML, as HTML is a text payload > like any other. > BTW, for mutt, you might try In .mailcap: text/html; lynx -dump -force_html %s; needsterminal; copiousoutput; In .muttrc: auto_view text/html application/x-X-sun-attachment In which case you can at least see the what's in the email. --dmm pgpXgvbDyMUrL.pgp Description: PGP signature
Possible IAB workshop on routing and addressing participants?
Folks, The IAB is considering holding a routing and addressing workshop, perhaps in the fall 2006 time frame (see the draft invite below). We're in the process of collecting potential participants, so please pass along any the names of folks that that you think would be productive participants. Thanks, --dmm (for the IAB) Greetings, The IAB is sponsoring a workshop on "Scalable Routing and Addressing Architectures for the Internet" in order to foster interchange between the operator, standards, vendor, and research communities on this important topic. You are being invited to participate in this effort. This workshop effort will consist of mailing list discussions in advance of, and after a face to face meeting. The technical goals of this effort are outlined below. We believe these are the critical elements to fostering a constructive discussion of important routing and addressing technical work going forward and are soliciting workshop participation to work towards those goals. Should you decide to join us in this workshop, you will be expected to attend the face to face meeting [0], contribute to (and possibly present at) that meeting, as well as follow and participate in the mailing list discussions. The most important objective of the workshop is to foster and encourage innovative thinking in an area where there has been little fundamental change for the last twelve years. As such, the primary goals of the workshop include the following two items: (i).Produce a concise problem statement that will serve as the input to future work on this topic. This problem statement will include, among other things, a list of the problems with the current routing and addressing architecture. These include (but are not limited to): - The difficulty in changing provider due to PA/CIDR addressing schemes - The lack of effective multi-homing support - Limited capability to protect against either the spoofing of individual host IP addresses or entire IP address blocks - The limited ability to secure the routing system itself, and (ii). Produce a prioritized list of requirements, all of which must be met by a next generation routing and addressing architecture. A sample list might include (in no particular order): - Retaining the connectionless datagram model of IP routing - Allow users (small and large) to freely switch between providers without substantial service interruption - Include survival of higher-layer connections and associations when connectivity to individual providers changes - Allow both users and ISPs to influence path selection according to traffic management and classification requirements - Provide better support for mobility and nomadicity - Provide architected instrumentation facilities - Allow at least one-to-many multicast - Prevent source address spoofing - Provide a rational economic basis for deployment - Secure the routing infrastructure, including the authentication of updates and the unauthorized injection of information into the routing system - Define scalability requirements for a next generation routing system - Have architected transition mechanisms and be incrementally deployable (where possible) During the workshop, scribes will be assigned to summarize the discussion. Post-workshop, scribes will be expected to participate in finalizing the workshop report. All participants will be expected to review the draft workshop report before publication. The workshop is pgptI3sdzqHAv.pgp Description: PGP signature
Re: 2006.06.06 NANOG-NOTES CC1 ENUM LLC update
On Thu, Jun 08, 2006 at 01:39:41PM -0400, Alex Rubenstein wrote: > > > Tell you what -- I'd love to see this for every meeting, in some sore of > official capacity. Seconded. I found the this especially useful as I was unable to attend this time. --dmm pgps1jvoVrTvd.pgp Description: PGP signature
Re: shim6 @ NANOG
Stephen, > Thus spake "Tony Li" <[EMAIL PROTECTED]> > >Stephen Sprunk wrote: > >>Who exactly has been trying to find scalable routing solutions? > > > >Well, for the last decade or so, there's been a small group of us who > >have been working towards a new routing architecture. Primary > >influences in my mind are Chiappa, O'Dell, Hain, Hinden, Nordmark, > >Atkinson, Fuller, Huston, Rekhter and Meyer. Apologies to any folks > >that feel I've incorrectly included or excluded them. ;-) > > And my apologies for not recognizing the work that y'all have done; my > point was that none of this seems to be officially supported by the IETF, > and thus hasn't borne much fruit. I've seen a few proposals by folks > listed above, and it seems to be old drafts (or even napkins) that get > trotted out when this discussion comes up. If there's work actively going > on today, it's not well publicized. Speaking for myself, I can say that many of us are trying to raise the profile of exactly these issues in the IETF. As you might imagine, that's not exactly a "path of least resistance", given the history/baggage. My position, however, is that the past is something we can learn from, but not be controlled by (a perhaps metaphorical way of saying "lets get on with it"). I'm optimistic that we're getting traction, but as I said, history and inertia are pushing the other way (not that that's going to stop us, but it does slow things down at times). > >>IPv6 advocates have been pushing a no-PI model for over a decade > >>because that's what ISPs told them to do. > > > >More accurately, the routing community has been trying to avoid PI > >addressing simply because of the scalability (and thus cost) concerns. > > s/routing/ISP/ and I'd agree with that. The IETF has virtually no > enterprise representation, and those folks (a) have a lot more routers than > the ISPs, and (b) pay the ISPs' bills. Agreed, and representation is a big problem. I'm trying to work that too. The first thing we tried was the NANOG/APRICOT BOFs (and I think we're going to try it at RIPE too, waiting to hear from the PC on that one). So maybe these were not as successful as I would have hoped, but hey, you have to start somewhere (on the theory that the best way to finish anything is to start). > I agree that PI has scaling/cost problems, but so far all of the > alternatives presented by the IETF present worse problems _in the eyes of > the people that pay the bills_. That doesn't mean the latter are right, > but their views should not be taken lightly. > > >>When they found end users didn't like that, they went off and > >>developed what has become shim6 as a poor apology. There has > >>never been any significant work done on replacing CIDR with > >>something that scales better. > > > >More accurately, that work (GSE/8+8) was slapped down politically > >without due technical consideration. > > Correction noted. > > >Note that replacing CIDR isn't exactly the point. The point is to have > >something that scales. Where CIDR can't cope is exactly when we > >come to multihoming. When multihoming was a rare exception, the > >small number of PI prefixes remains tolerable. However, over time, > >the continued growth in multihoming, even solely as a function of the > >growth of the Internet will come to dominate the cost structure of > >the routing subsystem. > > I'm not sure I agree with that. The ISPs out there have tens of prefixes > each even in v6 land (and hundreds in v4 land), whereas the goal is to have > one per end site. Until the number of multihomed end sites exceeds the > number of ISPs by several orders of magnitude, the impact on the routing > table will be non-dominant though certainly also non-trivial. > > Also, consider how easy it is to do PI-based multihoming in v4: all you > need is a couple pipes (or tunnels), an ASN, and enough hosts to justify a > /24. If you believed all the chicken littles, this would leave us with > millions of v4 PI routes and the DFZ would be in ruins, yet only a few > hundred people have taken ARIN up on that offer. In short, implementation > of PI-based multihoming has ground almost to a halt even under today's > liberal policies. > > Now, given the floodgates are open for v4 and all we see is a trickle of > water, why is everyone running around screaming that the sky will fall if > we do something similar for v6? Do we have any evidence at all that > multihoming growth will outpace Moore and this whole debate is even > relevant? > > >The only alternative to a PI-like architecture is to provide multihomed > >sites with multiple prefixes, none of which need to be globally > >disseminated. Making this multiple prefix architecture work was the > >charter of the multi6 group. This was constrained in interesting ways, >
Re: searching for BGP table donors
On Sun, Mar 05, 2006 at 01:54:52PM -0800, Bill Woodcock wrote: > > On Sun, 5 Mar 2006, Edward B. DREGER wrote: > > In the name of statistical sampling, I'd like to analyze some other > > [simulated] FIBs from different BGP views. > > Would anyone be interested in donating "show ip bgp" output? > > Current year and last year, prior back to 1997 by request: > http://www.pch.net/resources/data/routing-tables/archive/ > > http://archive.routeviews.org/oix-route-views/ Acutally, that's only a part of the routeviews data. See ftp://archive.routeviews.org/ for a more complete listing. Dave pgpOGauODltGL.pgp Description: PGP signature
Re: searching for BGP table donors
On Sun, Mar 05, 2006 at 09:38:02PM +, Edward B. DREGER wrote: > > Greetings all, > > The fuss over shim6, routing table size, and long-prefix PI space has > intrigued me. I've started analyzing some [simulated] FIBs and believe > I may have found something interesting. In the name of statistical > sampling, I'd like to analyze some other [simulated] FIBs from different > BGP views. > > Would anyone be interested in donating "show ip bgp" output? I assume > most people are familiar with script(1), but will mention it here, in > passing, "just in case". Compressed via bzip2 or rzip strongly > preferred; there's a reason I'm not keen to try this on public route > servers. ;-) > > Email is fine for up to a few megabytes. If anyone feels like sending > output from so many routers that even a compressed tarball exceeds that, > ping me to set up an FTP drop. > > Network topology and size matter not. "The more the merrier" when it > comes to data analysis. :-) We have a lot of data, collected from various points around the planet. Check out http://www.routevivews.org. You might also check out the RIPE RIS (http://www.ripe.net/ris). Dave pgpUpyK7epyqH.pgp Description: PGP signature
Re: a radical proposal (Re: protocols that don't meet the need...)
On Thu, Feb 16, 2006 at 02:42:49PM -0500, James R. Cutler wrote: > Since meeting Yakov years ago, I have always tried to teach network > designers to consider addressing and topology together. > > It hasn't always worked. Many don't care about network population > estimates and demographics, some don't recognize those terms, and, a > few just want enough Class C networks to get their job done for the day. Yep, very true. Dave > > Cutler > > At 2/16/2006 10:41 AM -0800, David Meyer wrote: > One of the first things I ever learned from Yakov (at the > first IETF I ever attended): > > "Addressing can follow topology or topology can follow >addressing. Choose one." > > He has since pointed out that this may not be strictly > true when considering VPN technologies. > > Dave > > - > James R. Cutler > [EMAIL PROTECTED] pgpy7zU64PJVZ.pgp Description: PGP signature
Re: a radical proposal (Re: protocols that don't meet the need...)
> It's a little more basic than that. I'm no graph theory expert and reading > such stuff gives me a headache, but I do understand that abstraction > (summarization or aggregation) of routing information is only possible if the > identifiers that are used for numbering network elements (the > "addresses") are assigned in a manner that is isomporphic to > the network topology. TLi started writing a good paper which > described this in terms of sets and subsets; unfortunately, I > don't think it ever saw the light of day). One of the first things I ever learned from Yakov (at the first IETF I ever attended): "Addressing can follow topology or topology can follow addressing. Choose one." He has since pointed out that this may not be strictly true when considering VPN technologies. Dave pgpkidS4tQbHr.pgp Description: PGP signature
Re: shim6 rides again (Re: protocols that don't meet the need...)
On Wed, Feb 15, 2006 at 11:26:47AM -0600, Randy Bush wrote:
>
> > Funny that shim6 is being mentioned. The corresponding open mic session
> > at 35 showed how gathering people for 20 minutes of complaining can
> > effectively replace long, protracted email threads.
>
> and what was the effect in the ietf? zippo.
Agreed. And to be honest, I missed this in my notes from
35 (and the two sets of minutes that we had). While I
can't say authoratively, but I'm willing to wager that
the {MPLS, IPv6, } WG didn't consider this as a
proposal. To that end, I'm happy to help write it up with
whomever wants to for Dallas (or whenever works).
More generally folks, let's solve this problem.
Dave
pgpNwKNUHYtU5.pgp
Description: PGP signature
Re: protocols that don't meet the need...
Daniel, On Wed, Feb 15, 2006 at 11:51:12AM +0100, Daniel Roesen wrote: > > On Tue, Feb 14, 2006 at 01:47:31PM -0800, David Meyer wrote: > > IETF). Now, while many in the IETF argue that there is no > > such thing as an "operator community", I personally see > > it differently, and there are many of us who think that > > operator input is sorely missing from the IETF process. > > The problem with IETF and IPv6 is from my perspective, that operator > input is being rejected as unreasonable or just ignored (shim6). I've > stopped wasting time trying to bring operator's views/points across. > It's not welcome if it doesn't fit already existing views within IETF > regarding IPv6. I know that a lot of active IPv6 folks think the same > but hesitate to communicate that openly. I understand your point, and hey, you're not the only one who sees it this way (and IPv6 isn't the only area where this problem is perceived to exist). Suppose we stipulate that your perspective (which is shared by many), namely that operator input is being rejected/ignored, is true. Then if we agree that IPv6 is here (for some value of "here", and as you mention below), then we need to find a way to solve the problems that we've been talking about here. My sense is that the likely place to do that is in the IETF (being the SDO that does this kind of work). So if you agree with what I've said above, how do we break the impasse and move forward? Like you, I'm interested in forwarding our common set of goals, and it seems pretty obvious that we need to find (or revive) a scalable routing architecture for IPv6. So lets find a way to do that (BTW, if I had the answer, I'd be the first to provide it. This is pretty thorney, as you've pointed out). > > That is one of the reasons we did the NANOG 35 IPv6 > > multihoming BOF (and are doing the same at the upcoming > > apricot meeting). > > Which is a good thing. But still, many IETF folks deny the fact that > they constantly hear that things like shim6 is NOT what the ops folks > (the folks that have to actually work with the stuff IETF brings > forward) are looking for. And we know that it doesn't. It can't. > There is no way to do traffic engineering with any shim6-like system > like one can do with BGP as shim6 is a completely host-centric solution. > It has no clue about upstream/downstream/peering, ASses etc. Those > things that actually make topology and economics. That's aside all the > other administrative nightmares associated. So I started writing up a I-D (the IETF coin of the realm) on this topic, but got sidetracked making slides for Apricot. I'd welcome anyone who wants to help me with that document (my approach was to outline the issues as a basis for bringing this discussion into the IETF). I could use the help. BTW, the doc is called Issues In Traffic Engineering with SHIM6 draft-meyer-shim6-and-te-00.txt but I haven't published it yet. Again, anyone who wants to contribute/write/whatever, insight/thoughts greatly appreciated. > > So (and again, not speaking for the IAB), my perspective > > is that we really need your insight and perspectives, > > more generally, your help in solving some of the > > difficult problems before us (a viable routing and > > addressing architecture for IPv6 comes to mind). > > I firmly believe that this train for IPv6 is long gone. We should go > forward with IPv6 using the legacy routing architecture and start NOW > working on a complete real re-vamp with a PROPER locator/identifier > split - not an ugly hack ontop of the traditional IPv4/IPv6 like shim6 > which doesn't deliver what ops folks need. > > Nevertheless, I really welcome IAB's efforts in the matter. Thanks, that is much appreciated. So on the theory that the best way to finish a task is to start it, let's start working on the document I mentioned above (if folks want to). If folks have other ideas, lets get those on the table too. Dave pgpKJTaQkv9JC.pgp Description: PGP signature
Re: protocols that don't meet the need...
On Tue, Feb 14, 2006 at 07:09:38PM -0500, Christian Kuhtz wrote: > > David, > > On Feb 14, 2006, at 5:07 PM, David Meyer wrote: > >>Hmm, well, when there is lots of vendor and academia involvement, no, > >>there's no operator community presented in number of things I'm > >>following in the IETF. Take manet, for example, I don't even know to > >>begin where to inject operator concerns/requirements. :-/ > > > > Well taken. And further, I would say manet is more the > > rule than the exception in this respect. BTW, it took me > > years to become facile with the (IETF) process (if I'm > > even there now :-)). I can say that I had excellent > > mentoring (Randy and perhaps a few others), so that > > helped. Maybe we need something not as formal as an IETF > > liaison relationship, but perhaps something like > > that. More thinking required... > > Thanks for the feedback. Any time. > I've been following manet as an interested > party for a while, with no real mission other than tracking it for > emerging technologies R&D. Lately, job is architecting municipal > wireless networks (which is really far more than what most people > think of when they think Sbux style WISP hotspots). And I'm looking > at the IETF for what's been worked out so far with respect to > wireless routing protocols for example, and I just can't help sitting > here scratching my head about how I would ever use what they've come > up with so far. And right now, I really can't without major > modifications it seems. And I find that really sad actually. That is a perfect example of the reason why we need more "reality clue" (or whatever) from the ops community in the standards process (choose your SDO). IMO, of course; others will (strenuously) differ with me. > And, don't get me wrong, but I'm not trying to bash them at all. I > just think that real world operations needs and concepts like > wholesale access aren't even anywhere near the radar screen it > seems. And that somehow needs to be fixed. And, yes, municipal > wireless is a roller coaster that's still gathering speed, so, > expecting that everything's already grown and ready for us are > thoroughly unrealistic. But! ;-) Sure, understood. > Right now the routing protocol on the mesh side will likely be > proprietary for some time, which really isn't in the operator's best > interest but that's what we have to work with. I/we have a > substantial interest in this becoming more than an academic PhD > thesis exercise, but something that can really be practically used in > the real world. > > Now, there is stuff in the MPLS community, for example, that I've > followed more or less closely for the past 7 yrs that might actually > be fruitful, but it too requires substantial tailoring. So, no > worries about job security there. ;-) > > >>I think this is as much an IETF issue as it is of the operator > >>community. Operators need to devote time to IETF to make the work in > >>the IETF most relevant to the operators needs. > > > > Yes, and this has always been an acute problem as long as > > I've been around. People have day (night, weekend > > jobs). Co-location of the meetings seems a possible way > > to start attacking one aspect that problem, with the > > understanding that perhaps travel isn't the biggest of > > the problems, but it is a non-trivial issue for many of > > us. > > Agreed. I'm headed to the IEEE 802 plenary in a couple of weeks to > start working standards body stuff for us as well, some of what needs > to happen is lower layer stuff. The less trips and the more I can > combine them, the more likely my management will look at my travel > expense submissions in a favorable light ;-).. So, the more > incentive we can provide with that, the better. I talked a bit with the (relatively new) IAD (IETF Administrative types) about what might be done here. This is something that will take some thought and if anything comes of that, some serious planning. > A while back, there was a desire to colo ARIN with NANOG. That's > really cool to see happen. For me, no offense to anyone, I really > couldn't care less at the moment. I'm on the opposite side of the > spectrum, ARIN being a vehicle for operationalized networks rather > than those who are about to be operationalized. So, perhaps NANOG > should be paired up with other industry forums in some kind of > rotation.. Anyone got ideas on this? Re NANOG/ARIN: The times I've been involved in the joint meetings I've found them very useful. Dave pgpygyQS8edA1.pgp Description: PGP signature
Re: protocols that don't meet the need...
Christian > On Feb 14, 2006, at 4:47 PM, David Meyer wrote: > > > Tony/all, > > > >>I am not going to speak for the IETF, but why would they? Their > >>meetings are > >>already open, and to be globally fair the proposed coordinators > >>would have > >>to attend 3-5 extra meetings a year to cover all the ops groups. > > > > I am also not speaking for the IETF (IAB), but the IAB has > > undertaken the task of trying to bring a little of what's > > happening in the IETF to the operator community (and > > hopefully in the process engaging folks to come to the > > IETF). Now, while many in the IETF argue that there is no > > such thing as an "operator community", I personally see > > it differently, and there are many of us who think that > > operator input is sorely missing from the IETF process. > > That is one of the reasons we did the NANOG 35 IPv6 > > multihoming BOF (and are doing the same at the upcoming > > apricot meeting). > > Hmm, well, when there is lots of vendor and academia involvement, no, > there's no operator community presented in number of things I'm > following in the IETF. Take manet, for example, I don't even know to > begin where to inject operator concerns/requirements. :-/ Well taken. And further, I would say manet is more the rule than the exception in this respect. BTW, it took me years to become facile with the (IETF) process (if I'm even there now :-)). I can say that I had excellent mentoring (Randy and perhaps a few others), so that helped. Maybe we need something not as formal as an IETF liaison relationship, but perhaps something like that. More thinking required... > I think this is as much an IETF issue as it is of the operator > community. Operators need to devote time to IETF to make the work in > the IETF most relevant to the operators needs. Yes, and this has always been an acute problem as long as I've been around. People have day (night, weekend jobs). Co-location of the meetings seems a possible way to start attacking one aspect that problem, with the understanding that perhaps travel isn't the biggest of the problems, but it is a non-trivial issue for many of us. Thanks for the great comments. Dave pgpqxxBWZHWN3.pgp Description: PGP signature
Re: protocols that don't meet the need...
Tony/all, > I am not going to speak for the IETF, but why would they? Their meetings are > already open, and to be globally fair the proposed coordinators would have > to attend 3-5 extra meetings a year to cover all the ops groups. I am also not speaking for the IETF (IAB), but the IAB has undertaken the task of trying to bring a little of what's happening in the IETF to the operator community (and hopefully in the process engaging folks to come to the IETF). Now, while many in the IETF argue that there is no such thing as an "operator community", I personally see it differently, and there are many of us who think that operator input is sorely missing from the IETF process. That is one of the reasons we did the NANOG 35 IPv6 multihoming BOF (and are doing the same at the upcoming apricot meeting). So (and again, not speaking for the IAB), my perspective is that we really need your insight and perspectives, more generally, your help in solving some of the difficult problems before us (a viable routing and addressing architecture for IPv6 comes to mind). All of that being said, I would be glad to facilitate with the IETF in any way I can. Perhaps someone from the NANOG PC/SC or Merit can contact me offline and we can look at with our options are. Any takers? Dave > > Tony > > > -Original Message- > > From: Eastgard, Tom [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, February 14, 2006 1:01 PM > > To: Tony Hain; nanog@merit.edu > > Subject: RE: protocols that don't meet the need... > > > > > -Original Message- > > > From: Tony Hain [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, February 14, 2006 12:35 PM > > > To: nanog@merit.edu > > > Subject: protocols that don't meet the need... > > > > > > > > > A thought I had on the plane last night about the disconnect > > > between the NANOG and IETF community which leaves protocol > > > development to run open-loop. > > > > > > Rather than sit back and complain about the results, why not > > > try to synchronize meeting times. Not necessarily hotels, but > > > within a reasonable distance of each other so the issue about > > > ROI for the trip can be mitigated. > > > This will mean that people who regularly attend both will > > > have overlap issues, but if one meeting every year or two is > > > joint there is an opportunity for those who can't justify the > > > extra trips to at least have some feedback to try and close > > > the loop on protocol design. > > > > Would it make sense to ask IETF to provide a focal or coordinate(s?) to > > NANOG who would host a BOF(s?) on IETF issues --- not to debate, explain > > or > > work them but to board the issues and concerns of the operating community? > > Point being to provide a lightly structured and cost effective mechanism > > for > > operators to give feedback without having to attend three more meetings > > per > > year? > > > > T. Eastgard pgpE2MbQ5fMiQ.pgp Description: PGP signature
routeviews outage
Folks, We've had a UPS failure in the colo space where much of the routeviews gear is housed. We're working on bringing it all back up, but I suspect its going to be a few minutes (like 30-45). Thanks, and sorry for any inconvenience. Dave pgp3kwibMGy8Z.pgp Description: PGP signature
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Fri, Dec 16, 2005 at 03:52:20AM +, Christopher L. Morrow wrote: > > > On Thu, 15 Dec 2005, Marshall Eubanks wrote: > > > Hello Dave; > > > > This won't open for me. > > > > Do you have a pdf of these slides ? > > > > On Dec 15, 2005, at 10:39 PM, David Meyer wrote: > > > > > On Thu, Dec 15, 2005 at 07:34:56PM -0800, David Meyer wrote: > > >> On Fri, Dec 16, 2005 at 03:29:29AM +, Christopher L. Morrow > > >> wrote: > > >>> that qos > > >>> is pointless if your links are +ds3 and not 100% full. Someone > > >>> might have > > >>> a pointer handy for that? > > > > > > You might check slides 35-38 in > > > > > >http://www.1-4-5.net/~dmm/sprintlink_and_mpls.ppt > > those would be them.. and dave can grab just the 3 slides in pdf from: > > http://www.secsup.org/files/dmm-queuing.pdf > > (or of course anyone else can grab them, but it's dave presentation so :) > ) Thanks Chris. Dave pgpeiPMsDxxG6.pgp Description: PGP signature
Re: The Qos PipeDream [Was: RE: Two Tiered Internet]
On Thu, Dec 15, 2005 at 07:34:56PM -0800, David Meyer wrote: > On Fri, Dec 16, 2005 at 03:29:29AM +, Christopher L. Morrow wrote: > > > > On Thu, 15 Dec 2005, John Kristoff wrote: > > > > > > > > On Thu, 15 Dec 2005 19:15:49 -0500 (EST) > > > Sean Donelan <[EMAIL PROTECTED]> wrote: > > > > > > > AT&T, Global Crossing, Level3, MCI, Savvis, Sprint, etc have sold > > > > QOS services for years. Level3 says 20% of the traffic over its > > > > > > What do they mean by QoS? Is it IntServ, DiffServ, PVCs, the law of > > > > I think also mostly this applies to private network things as well... > > which mostly ends up being: "backups get 20% of the pipe and oracle-forms > > gets 70%" (or some variation on that mix... what with 8 queues or whatever > > on the private network you can just go to town :) ) > > > > Speaking to MCI's offering on the public network it's (not sold much) just > > qos on the end link to the customer... It's supposed to help VOIP or other > > jitter prone things behave 'better'. I'm not sure that we do much in the > > way of qos towards the customer aside from respecting the bits on the > > packets that arrive (no remarking as I recall). So, what does this get you > > aside from 'feeling better' ? > > > > > averages or something else? I've had to deploy it on a campus network > > > and in doing so it seems like I've tread into territory where few if > > > any big networks are to be found. Nortel apparently removed DiffServ > > > > most large networks (as was said a few times I think) don't really need it > > in their cores. I think I've seen a nice presentation regarding the > > queuing delay induced on 'large pipe' networks, basically showing that qos > > is pointless if your links are +ds3 and not 100% full. Someone might have > > a pointer handy for that? You might check slides 35-38 in http://www.1-4-5.net/~dmm/sprintlink_and_mpls.ppt Dave pgpwYFugkpI8h.pgp Description: PGP signature
Re: BTW, have I mentioned my "perfect storm hypothesis"?
[...] > How many of these are in place today? Well, clearly google > is building out, so there is potential for (i). to occur > any day now. Likewise (ii) (linksys gear with 4 tunable > radios, North-South WiMAX, east west 802.11bag, and > you're there). Finally, (iii). has an existence proof > that has all but wiped out the recording industry, plus > gtalk, skype, vonage, ... So is the telco industry far > behind? A few folks have mentioned that "wiped out" might be too strong (which I agree with), and I had changed that to "restructuring", but some how that didn't get into the note I sent. So to those who send those corrections on "wiped out", thanks, and I'll update with your suggestions. Dave pgplk5hTrtAwQ.pgp Description: PGP signature
BTW, have I mentioned my "perfect storm hypothesis"?
Long story short (excerpt from an email I sent to Tony Bates and Larry Lang): --- In our discussion yesterday on the Service Exchange Architecture (SEA) list, I mentioned a kind of a "Telecommunications Perfect Storm" (TPS) that we should at least be considering as a hedge against our current strategy. Recall that my perfect storm scenario was something like: (i).Someone, say google (or ebay/skype), learns how to run a profitable, low margin packet carriage business. Remember that the "hypothesis" is that packet carriage will always be a low margin business as a direct consequence of the end-to-end principle. Add to this the fiber (some say bandwidth) glut, and you can see scenarios under which there is a non-zero (or even significant) probability of this outcome. (ii). The access monopolies are somehow broken (say, by a technology like WiMAX), and finally, (iii). You get a set of peer-to-peer (p2p) applications that attack the incumbent revenue stream (starting with voice, but including presence, IM, video, ..). How many of these are in place today? Well, clearly google is building out, so there is potential for (i). to occur any day now. Likewise (ii) (linksys gear with 4 tunable radios, North-South WiMAX, east west 802.11bag, and you're there). Finally, (iii). has an existence proof that has all but wiped out the recording industry, plus gtalk, skype, vonage, ... So is the telco industry far behind? --- As you might imagine, in a "complexity rich" environment you find at most vendors these days, its a hard sell (hence the "hedge" mumbo-jumbo). All that being said, I have had a bit of success pushing the "simplicity" agenda. But its an uphill battle (again, as you might imagine). Dave On Thu, Dec 15, 2005 at 05:30:08PM +, Alexander Harrowell wrote: > And not by offering you anything you might want to buy, either, but by > setting up wanky little tollbooths. > > On 12/15/05, Fergie <[EMAIL PROTECTED]> wrote: > > > > Bingo. > > > > What they are really saying is: > > > > "We're _telling_ you that you need it because we need new > > ways to generate additional revenue." > > > > ;-) > > > > Cheers, > > > > - ferg > > > > > > -- Alexander Harrowell <[EMAIL PROTECTED]> wrote: > > > > The whole QoS/2 tier Internet thing I find deeply, deeply > > suspicious...here in the mobile space, everyone is getting > > obsessed by IMS (IP Multimedia Subsystem) and explaining to > > each other that they need it so they can offer "Better QoS, > > like the subscribers want". What they really mean, I suspect, > > is killing third party applications that compete with their > > own. IMS=I Mash Skype. And, I suspect, "QoS" for SBC > > customer broadband will mean "the speed we advertise so > > long as you are paying us for VoIP/video/whatever, shite > > if you aren't". > > > > [snip] > > > > -- > > "Fergie", a.k.a. Paul Ferguson > > Engineering Architecture for the Internet > > [EMAIL PROTECTED] or [EMAIL PROTECTED] > > ferg's tech blog: http://fergdawg.blogspot.com/ > > > > > > > > pgpJ5goeqt7U8.pgp Description: PGP signature
Re: route-views.routeviews.org down?
>> bummer that. data not being collected. one weeps to think of >> all those announcements lost forever. >> >> is a data gap like a mineshaft gap? Just to be clear: The box that hung was route-views.routeviews.org. We collect 'sh ip bgp' RIBs from this box on 2 hour intervals. So (sadly) there will be a few holes in that data set. However, the MRT format RIB and UPDATE data sets are collected on other boxes, and as a result were not effected by this outage. Please let me know if you have other questions or comments, and again, sorry about the outage. We'll try to tighten up our monitoring/coverage so that we don't get a prolonged outage again. Thanks, Dave pgpyCi2x8CwIb.pgp Description: PGP signature
Re: route-views.routeviews.org down?
On Tue, Nov 22, 2005 at 10:16:11AM +0200, Hank Nussbacher wrote: > > I am unable to telnet or ping route-views.routeviews.org. No event listed > at http://www.routeviews.org/update.html > > Is it just me? Sorry folks, we've been having a memory fragmentation problem. Should be back RSN. Thanks for the report. Dave pgphW3tv2jg6I.pgp Description: PGP signature
Re: the iab simplifies internet architecture!
> but please don't plan yet another "the wonderful things the > ivtf is doing in area x." Actually, that is not at all what I had intened or planned, and if it came across that way then to some extent we failed. In any event, I do appreciate this feedback. > try something more like "what are > the most critical forward problems and what are the deployment, > transition, and use constraints on possible approaches?" Excellent suggestions. Much appreciated. Thanks, Dave pgpFJTwplA8le.pgp Description: PGP signature
Re: the iab simplifies internet architecture!
On Fri, Nov 11, 2005 at 07:39:09AM -0800, Fred Baker wrote: > > None that I have spoken with. What I hear continually is that people > would like operational viewpoints on what they're doing and are > concerned at the fact that operators don't involve themselves in IETF > discussions. Agreed, but it is pretty clear that serious communication/image/respect/etc challenges remain. That is why the current IAB took a step, albeit a small step, towards trying to change that by opening up the communication channels a bit. As I seem to become fond of saying, "its a first step, but you have to start somewhere". I'm hoping (and pushing) that we keep moving in this direction. As always, we can all educate each other a bit, and some of that happened at the NANOG BOF. However, much more is needed. To that end, I've applied for a slot at APRICOT for the IAB so we can keep what momentum we gained from the NANOG BOF going. Finally, if folks have suggestions as to how to make these (communication) channels more useful, work better, etc (including suggestions for issues you'd like to talk to the IAB about or hear the IAB talk about), please let me know. Dave n Nov 11, 2005, at 6:03 AM, Randy Bush wrote: >that's what a number of i* members have publicly stated is their >opinion of talking to us operators. pgpKSTLaEKs5U.pgp Description: PGP signature
Re: shim6 @ NANOG (forwarded note from John Payne)
John, On Thu, Oct 27, 2005 at 02:08:50AM +1000, Geoff Huston wrote: > > From: John Payne <[EMAIL PROTECTED]> > > Subject: shim6 @ NANOG > > Date: Wed, 26 Oct 2005 09:11:45 -0400 > > > Public thanks to Dave, Geoff, Vijay, Ted and Jason for their > involvement in bringing shim6 to the NANOG conference. > > The messages I heard were: > > 1) Traffic engineering, traffic engineering and traffic engineering > - do NOT put this in the hands of the end system, this needs to > be site level, or at the very least the site needs to be able to > override the end system's decisions. > > 2) The first hit is of critical importance to content providers (many > of whom couldn't legitimately justify a /32). Hunting through DNS to > find a locator that works won't fly. > > 3) It was good to hear in a widespread forum that shim6 is not > expected to be THE only multihoming solution. However, we were left > uninformed as to where the other work is going on. Thanks. I'd also like to thank Geoff, Jason, Vijay, Ted, and everyone to participated in the BOF. I found the session to be quite productive, and I hope that it will form the foundation for an ongoing dialog. The IAB is hoping to do the next IAB "BOF" at APRICOT, so with any luck, see you all there. Thanks again all, Dave pgpsscZ7R1Z7A.pgp Description: PGP signature
Re: IPv6 news
On Sun, Oct 16, 2005 at 01:45:40AM -0700, Tony Li wrote: > > > > >Doesn't NAT, or more specifically the most commonly used, NAPT, create > >hard state within the network, which then makes it violate the > >end-to-end argument ? Also, because it has to understand transport and > >application layer protocols, to be able to translate embedded > >addresses, > >doesn't this also make it violate end-to-end ? I've understood the > >fundamental benefit of following the end-to-end argument is that > >you end > >up with a application agnostic network, which therefore doesn't create > >future constraints on which applications can then be used over that > >network. In an end-to-end "compliant" network, any new transport layer > >protocols, such as SCTP or DCCP, and new user applications, only > >require > >an upgrade of the end or edge node software, which can be performed in > >an incremental, per edge node as needed basis. In other words, there > >isn't any whole of network upgrade cost or functionality deployment > >delay to support new applications, which was the drawback of > >application > >specific networks, such as the traditional POTS network. > > > >Have I somehow misunderstood the intent or benefits of the end-to-end > >argument ? > > > Mark, > > This is probably the most common misunderstanding of the end-to-end > principle out there. Someone else can dig up the quote, but > basically, the principle says that the network should not replicate > functionality that the hosts already have to perform. You have to > look at X.25's hop-by-hop data windows to truly grok this point. > > Many people pick this up and twist it into ~the network has to be > application agnostic~ and then use this against NATs or firewalls, > which is simply a misuse of the principle. Really, this is a > separate principle in and of its own right. It's not one that I > subscribe to, but that's a different conversation... Maybe its time to pull out some of Noel's work on both topics. Reasonable introductions to both the e2e principle and locator/id split topics can be found on http://users.exis.net/~jnc/tech/end_end.html and http://users.exis.net/~jnc/tech/endpoints.txt respectively. Dave pgpA3Ia5xQxIC.pgp Description: PGP signature
Re: shim6 (was Re: IPv6 news)
Seems like it might be a good time to update everyone on the IAB IPv6 Multi-homing BOF we're holding Monday afternoon at NANOG. My very draft introduction slides are on http://www.1-4-5.net/~dmm/talks/NANOG35/multihoming. Dave pgpNenCFArWcU.pgp Description: PGP signature
Re: OMB: IPv6 by June 2008
On Thu, Jul 07, 2005 at 09:58:56AM -0700, Alexei Roudnev wrote: > > What's the problem with independent address space for every entity (company, > family, enterprise) which wants it? Big routing tables? Is RT of 1,000,000 > routes BIG? I do not think so. Memory is cheap, modern routing schemas like > CEF are effective. How many entities do we have on earth? It was a problem, > but it IS NOT ANYMORE. One of the problems that is frequently overlooked here is that while the size of the DFZ is more or less bounded (although not as meaningfully so for IPv6 as it is for IPv4), the dynamic nature of the routing table is not bounded. Add to this that the less aggregation you have, the more the DFZ is exposed to those dynamics. The point here being that the memory requirements of the DFZ table is just one of the dimensions that must be considered if we intend the network to scale. Dave pgpqDJUAJZDNI.pgp Description: PGP signature
Re: OMB: IPv6 by June 2008
Andre, On Thu, Jul 07, 2005 at 06:04:22PM +0200, Andre Oppermann wrote: > > Joe Abley wrote: > > > >On 2005-07-07, at 10:23, Andre Oppermann wrote: > > > >>It was about a spot in the global routing table. No matter if one gets > >>PA or PI they get a routing table entry in the DFZ. There is no way > >>around > >>it other than to make the routing protocols more scaleable. > > > >With the hole-punching/CIDR abuse multihoming that is widely used in > >IPv4, a slot in the DFZ gets burned each time an end site adds a > >provider, regardless of whether they are using PA or PI addresses. This > >slot represents state information for the multi-homed site which > >answers the question "how else can this set of addresses be reached?" > > > >The shim6 approach shifts this state from the DFZ to the endpoints > >which are exchanging unicast traffic. The endpoints exchange a set of > >possible locators through a protocol element within the IP layer and > >handle locator migration transparently to the transport layer above. > >Hence the question "how else can this particular remote address be > >reached" is answered using information on the host, not information in > >the network. > > > >With shim6 an end site can multi-home using one PA prefix per provider, > >without taking up additional slots in the DFZ. Hosts within the site > >are given multiple addresses (locators), and the layer-3 shim handles > >any change of locator needed for traffic exchanged between any two hosts. > > > >If one (or both) of the hosts exchanging traffic don't support shim6, > >then the traffic is exchanged without transport-layer stability across > >re-homing events (and, potentially, without any optimisation as to the > >choice of endpoint addresses for the session). > > > >So, the shim6 future of multihoming looks like this: > > > >1. ISPs multi-home exactly as people are used to doing today, using PI > >prefixes, and taking up a slot in the DFZ per transit provider. > >Everybody is familiar with this already. There is no change for ISPs in > >this picture. > > > >2. Multi-homed end sites obtain one PA prefix per upstream ISP, and > >hosts within those end-sites are assigned multiple addresses (in some > >automated, secure and controllable fashion). There are no additional > >slots burned in the DFZ by end site multi-homing. Hosts obtain > >transport-layer reliability across re-homing events using shim6, rather > >than relying on the network to take care of it. > > Ok, you don't think this thing will ever fly, do you? I'm interested in what aspect(s) of shim6 you think might cause it to fail? Is it the technology itself (as much as is specified anyway), it's complexity, the underlying multihoming model, ...? Dave pgpGf42MXHTNL.pgp Description: PGP signature
Re: OMB: IPv6 by June 2008
On Fri, Jul 01, 2005 at 02:54:30PM +, Christopher L. Morrow wrote: > > > On Fri, 1 Jul 2005, Mohacsi Janos wrote: > > > > > > This keeps coming up in each discussion about v6, 'what security measures' > > > is never really defined in any real sense. As near as I can tell it's > > > level of 'security' is no better (and probably worse at the outset, for > > > the implementations not the protocol itself) than v4. I could be wrong, > > > but I'm just not seeing any 'inherent security' in v6, and selling it that > > > way is just a bad plan. > > > > > > > Just name a few: > > - Possibility to end-to-end IPSec. > > exists in v4 > > > - Not feasible scanning of subnets remotely > > eh... maybe, I'm not convinced this matters anyway. > > > - Privacy enhanced addresses - not tracking usage based on addresses > > dhcp can do this for you (v4 has mechanisms for this) > > > - Better ingress filtering > > > > right... because gear that filters so well in v4-land will filter so much > better in v6-land? you == crazy. > > > All those objections aside, I'd love to see v6 more fully deployed. I'm > not sure I see how it's going to get beyond 'research' or 'play' land, > except for some small cases, for quite some time. It's interesting that > the flood gates on ip space are openning at IANA though, that should > hasten the v6 takeup/deployment :) Perhaps paraphrasing what Chris just said: At the end of the day, it is very difficult to make the case that IPv6 offers anything that IPv4 doesn't other than a larger address space. Dave pgpiadOa4oEze.pgp Description: PGP signature
Re: Tracking spoofed routes?
Kevin, >> I am seeking avenues to investigate a possible case of IP address spoofing. >> >> I've recently received complaints which suggest that in the recent >> past (but not right now), somebody may have announced a more specific >> prefix, effectively hijacking "unused" address space within our >> allocated range. >> >> As it happens, the address space is not unused, just not visible on >> the public Internet. >> >> >> I am aware of route reflectors and other options to manually review >> what prefixes are currently announced, but have not been able to find >> a *searchable* archive of historical data, either overall BGP tables >> or just "unusual" announcements. The closest thing I've found so far >> is Route Views (http://www.routeviews.org/), however there is no >> obvious way to search the (huge) archived data files for substring >> matches? We're involved in trying to build database front ends for the data so you can do just this sort of thing. But right now, we're a little stuck. One thing you might try is using BGPlay to watch what happens to your prefix. >> Alternately, are there any existing mechanisms for monitoring route >> announcements which can provide near real-time alerting when any >> prefixes within specific subnet ranges are announced? Not that I know of. You can log into route-views.routeviews.org and use the cli to watch it, but that is a manual process. Hope this helps, Dave
can someone from Savvis and Radianz contact me?
I'm looking for some multicast information. Thanks, Dave
Re: Qwest Utah fiber cut
>> >> I was hoping someone might be able to shed some light on the Utah cut. >> >> The news report said that the cut happened near Monroe Utah, which is several miles >> off of I 70. Yet the cities that were reported effected included St. George, Cedar >> City, and Salt Lake, which all are adjacent to I 15. >> >> The puzzling part is that in our "best effort" database Qwest does not have long >> haul fiber running down I 70, but it does have a lot of fiber running down I 15. >> There is Qwest fiber on I 15, all the cities affected are on I 15 yet the reported >> cut was near Monroe off of I 70. >> >> I'm not familiar with Utah geogrpahy and this comes simply from looking at our >> maps. Just trying to sort out the seeming discrepency. Any insight? >> >> BTW, does anyone know if this is what took out SkyWest Airlines yesterday? (HQ and apparently all databases they need to operate in Utah). They were grounded nation-wide for about 3.5 hours. Dave
Re: route-views.oregon-ix.net
Pete, On Mon, May 10, 2004 at 11:15:46AM -0400, Peter Rohrman wrote: >> >> Is route-views.oregon-ix.net down? I cant get to it. Please use route-views.routeviews.org (we're trying to transition of the exchange addresses as they are not routed everywhere). Thanks, and sorry for the inconvenience. Dave
Re: BGP TTL check in 12.3(7)T
>> The TTL mechanism is just a way to distinguish at low cost between >> good for_us traffic and junk. So more of a classifer than a security >> layer, though it can be argued both ways. And even though it >> does have security in the title, it is _not_ a panacea for "securing" >> bgp or any routing information. >> >> http://www.faqs.org/rfcs/rfc3682.html Just to second what Vijay said here, what GTSM does is close the window a bit; it doesn't shut it. Dave
New route-views collector up at the LINX
Folks, We are now up and running at the LINX (London Internet Exchange) and would like to invite folks at the LINX to peer with route-views. You can get to the open CLI via 'telnet route-views.linx.routeviews.org' (of course, nothing much there yet). Please contact us at [EMAIL PROTECTED] if you would like to contribute your view. In addition, I've included our standard boilerplate below. Thanks, The Route-Views Team - AS : 6447 University of Oregon: route-views : 128.223.60.103(multi-hop IPv4) route-views2: 128.223.60.102(multi-hop IPv4) route-views3: 128.223.60.108(multi-hop IPv4) : 2001:468:d01:3c::80df:3c6c(multi-hop IPv6) route-views6: 128.223.60.194(v6 peering only) : 2001:468:d01:3c::80df:3c6d(multi-hop IPv6) route-views.wide: 202.249.2.166 (WIDE peering only) route-views.paix: 198.32.176.5 (PAIX peering only) route-views.linx: 195.66.225.222(LINX peering only) route-views.linx: 195.66.227.222(LINX peering only) - Route-views does not announce _any_ prefixes. - We would like to receive a full default-free table from all sessions with all peers. - In order for our multihop-ebgp sessions to survive transient network failures, we would like to increase the BGP hold-timer to 10 minutes (600 seconds). A value of zero does not work for several cases. If possible, peers should set their hold-timer to the max value which allows Route-Views to change without your intervention. cisco: neighbor 128.223.60.x timers 21845 65535 juniper: set protocols bgp group routeviews hold-time 65535 - Please send your communities. If possible, please describe the communities you advertise. - Please provide your NOC's email and telephone number(s). - Route information from these sessions is made publicly available in two forms: manufacturer-style "show ip bgp" and MRT format. -- Short questionnaire. These data will only be shared with researchers. - What type of router(s) are we peering with? - We have a (closed) mail list which we use to announce outages to our peers. If you would like your noc added to this list, please let us know. Thanks!
Re: iMPLS benefit
On Fri, Mar 05, 2004 at 10:02:10AM -0800, Yakov Rekhter wrote: >> Dave, >> >> > Hey Suki, >> > >> > On Thu, Mar 04, 2004 at 02:14:20PM -0800, sonet twister wrote: >> > >> Hello, >> > >> >> > >> i heard there is a way to run MPLS for layer3 VPN(2547) >> > >> service without needing to run label switching in the >> > >> core(LDP/TDP/RSVP) but straight IP (aka iMPLS). >> > >> >ftp://ftp.ietf.org/internet-drafts/draft-townsley-l2tpv3-mpls-01.txt >> > >> >See also Mark's talk from the last NANOG >> > >> >http://nanog.org/mtg-0402/townsley.html >> >> That requires to run L2TP. An alternative is to run GRE (or even plain >> IP). The latter (GRE) is implemented by quite a few vendors (and is >> known to be interoperable among multiple vendors). >> >> The spec is draft-ietf-l3vpn-gre-ip-2547-01.txt. Yep, you are correct. Sorry not to cite that one too. Dave
Re: iMPLS benefit
Hey Suki, On Thu, Mar 04, 2004 at 02:14:20PM -0800, sonet twister wrote: >> Hello, >> >> i heard there is a way to run MPLS for layer3 VPN(2547) >> service without needing to run label switching in the >> core(LDP/TDP/RSVP) but straight IP (aka iMPLS). ftp://ftp.ietf.org/internet-drafts/draft-townsley-l2tpv3-mpls-01.txt See also Mark's talk from the last NANOG http://nanog.org/mtg-0402/townsley.html >> Anyone running this in a live network yet? Thanks in advance >> for any information. Yes. Dave >> Suki Lim >> Blacksburg, VA >> ee.VA.TECH >> >> >> - >> Do you Yahoo!? >> Yahoo! Search - Find what you?re looking for faster.
Re: Converged Networks Threat (Was: Level3 Outage)
Petri, >> I think it has been proven a few times that physical fate sharing is >> only a minor contributor to the total connectivity availability while >> system complexity mostly controlled by software written and operated by >> imperfect humans contribute a major share to end-to-end availability. Yes, and at the very least would seem to match our intuition and experience. >> From this, it can be deduced that reducing unneccessary system >> complexity and shortening the strings of pearls that make up the system >> contribute to better availablity and resiliency of the system. Diversity >> works both ways in this equation. It lessens the probablity of same >> failure hitting majority of your boxes but at the same time increases >> the knowledge needed to understand and maintain the whole system. No doubt. However, the problem is: What constitutes "unnecessary system complexity"? A designed system's robustness comes in part from its complexity. So its not that complexity is inherently bad; rather, it is just that you wind up with extreme sensitivity to outlying events which is exhibited by catastrophic cascading failures if you push a system's complexity past some point; these are the so-called "robust yet fragile" systems (think NE power outage). BTW, the extreme sensitivity to outlying events/catastrophic cascading failures property is a signature of class of dynamic systems of which we believe the Internet is an example; unfortunately, the machinery we currently have (in dynamical systems theory) isn't yet mature enough to provide us with engineering rules. >> I would vote for the KISS principle if in doubt. Truly. See RFC 3439 and/or http://www.1-4-5.net/~dmm/complexity_and_the_internet. I also said a few words about this topic at NANOG26 where we has a panel on this topic (my slides on http://www.maoz.com/~dmm/NANOG26/complexity_panel). Dave
Re: Converged Networks Threat (Was: Level3 Outage)
Jared, >> >Is your concern that carrying FR/ATM/TDM over a packet >> >core (IP or MPLS or ..) will, via some mechanism, reduce >> >the resilience of the those services, of the packet core, >> >of both, or something else? >> >> I'm saying that if a network had a FR/ATM/TDM failure in >> the past it would be limited to just the FR/ATM/TDM network. >> (well, aside from any IP circuits that are riding that FR/ATM/TDM >> network). We're now seeing the change from the TDM based >> network being the underlying network to the "IP/MPLS Core" >> being this underlying network. >> >> What it means is that a failure of the IP portion of the network >> that disrupts the underlying MPLS/GMPLS/whatnot core that is now >> transporting these FR/ATM/TDM services, does pose a risk. Is the risk >> greater than in the past, relying on the TDM/WDM network? I think that >> there could be some more spectacular network failures to come. Overall >> I think people will learn from these to make the resulting networks >> more reliable. (eg: there has been a lot learned as a result of the >> NE power outage last year). I think folks can almost certainly agree that when you share fate, well, you share fate. But maybe there is something else here. Many of these services have always shared fate at the transport level; that is, in most cases, I didn't have a separate fiber plant/DWDM infrastructure for FR/ATM/TDM, IP, Service X, etc, so fate was already being/has always been shared in the transport infrastructure. So maybe try this question: Is it that sharing fate in the switching fabric (as opposed to say, in the transport fabric, or even conduit) reduces the resiliency of a given service (in this case FR/ATM/TDM), and as such poses the "danger" you describe? Is this an accurate characterization of your point? If so, why should sharing fate in the switching fabric necessarily reduce the resiliency of the those services that share that fabric (i.e., why should this be so)? I have some ideas, but I'm interested in what ideas other folks have. Thanks, Dave
Re: Converged Networks Threat (Was: Level3 Outage)
Jared, >> I keep hear of Frame-Relay and ATM signaling that is going >> to happen in large providers MPLS cores. That's right, your "safe" TDM >> based services, will be transported over someones IP backbone first. >> This means if they don't protect their IP network, the TDM services could >> fail. These types of CES services are not just limited to Frame and ATM. >> (Did anyone with frame/atm/vpn services from Level3 experience the >> same outage?) Is your concern that carrying FR/ATM/TDM over a packet core (IP or MPLS or ..) will, via some mechanism, reduce the resilience of the those services, of the packet core, of both, or something else? >> We're at (or already past) the dangerous point of network >> convergence. While I suspect that nobody directly died as a result of >> the recent outage, the trend to link together hospitals, doctors >> and other agencies via the Internet and a series of VPN clients continues >> to grow. (I say this knowing how important the internet is to >> the medical community, reading x-rays and other data scans at >> home for the oncall is quite common). Again, I'm unclear as to what constitutes "the dangerous point of network convergence", or for that matter, what constitutes convergence (I'm sure we have close to a common understanding, but its worth making that explicit). In any event, can you be more explicit about what you mean here? Thanks, Dave
Re: Routeviews and possible 0/0 route
On Thu, Dec 18, 2003 at 04:05:56PM -0800, [EMAIL PROTECTED] wrote: >> >> I'm seeing the following in RouteViews (possibly since they started >> getting data from paix): >> >> route-views.oregon-ix.net>sh ip bgp 0.0.0.1 >> BGP routing table entry for 0.0.0.0/, version 19579757 >> Paths: (2 available, best #2, table Default-IP-Routing-Table) >> Not advertised to any peer >> 6939 6461 >> 216.218.252.152 from 216.218.252.152 (216.2t8.252.152) >> Origin IGP, localpref 100, valid, external >> 6939 6461 >> 216.218.252.145 from 216.218.252.145 (216.218.252.145) >> Origin IGP, localpref 100, valid, external, best >> >> Is this routeviews own set default or some other default route improperly >> appearing in there (weren't routeviews filters supposed to filter out this >> kind of all-net advertisements)? Nope to the former. Someone (6461) is advertising it. We haven't traditionally filtered what we receive from our peers. Note also that route views does not use routes from the peers for forwarding traffic. Dave
route-views up at PAIX (Palo Alto)
Folks, We are now up and running at the PAIX (Palo Alto) and would like to invite folks at the PAIX to peer with with Route-Views. Please contact us at [EMAIL PROTECTED] if you would like contribute your view. Thanks, The Route-Views Team
new routeviews mailing lists
Folks, We have set up a few new mailing lists for the routeviews project; see http://routeviews.org/~majordom/rv-lists.html Thanks, Dave
Route-Views peering at PAIX and NSPIXP
As part of the "Route-Views Update" presentation delivered at the NANOG 29 in Chicago, we openly invited participants at the PAIX (install pending) and NSPIXP (WIDE) exchanges to peer with Route-Views (AS6447). For those who may have forgotten or were not present, we thought we would repeat the offer. Those willing to peer, please contact us at [EMAIL PROTECTED] Thanks, The Route-Views Team
Re: Tomatoes for Verisign at NANOG 29
>> I would also suggest that we try to make contact with a second-harvest or >> other organization that may be able to use the tomatoes afterwards. Or just use your time and resources to do some good for those who are less fortunate in the first place. Using food of any kind for such a display is simply unacceptable (and BTW, in no way funny or cute) in a world filled with so much hunger, poverty, and despair. Indeed, such an activity will reflect very poorly on us all, notwithstanding any issue relating to the DNS. Dave
New routeviews service available (Address/Prefix -> AS/ASPATH mappings)
All, In response to requests from many folks asking for prefix to AS mappings, routeviews is now providing 2 new services mapping and address or prefix to its origin AS and to its ASPath. These services are available via two zones: (i).asn.routeviews.org asn.routeviews.org maps an address or prefix into its origin AS, prefix, and prefix length, as seen by route-views2.routeviews.org (the data is held in TXT records). For example, the following command % dig txt 223.128.asn.routeviews.org returns (among other things) 223.128.asn.routeviews.org. 86400 IN TXT "3582" "128.223.0.0" "16" The syntax here is: "AS" "Prefix" "Prefix Length" (ii). aspath.routeviews.org aspath.routeviews.org is similar to asn.routeviews.org, except that it maps an address or prefix into the ASpath (rather than origin AS), prefix, and prefix length, as seen by route-views2.routeviews.org (again, the data is held in TXT records). For example, the following command % dig txt 223.128.aspath.routeviews.org returns (among other things) 223.128.aspath.routeviews.org. 86400 IN TXT "286 209 3356 3701 3582" "128.223.0.0" "16" The syntax here is: "ASPath" "Prefix" "Prefix Length" These zones are built twice per-day, 11:45 and 23:45 UTC. Finally, please let us know ([EMAIL PROTECTED]) if you have questions, comments or suggestions for ways we might otherwise improve this service. One note: note that these zones are quite large, and reloading these produces a period of a few minutes during which the server may not reply. Thanks, Dave
Re: dry pairs
>> It's genrally called a lads circuit. BTW, LADS == Local Area Data Service. Dave >> >> joelja >> >> On Fri, 29 Aug 2003, Pendergrass, Greg wrote: >> >> > >> > Neither do we. Could you include some more details? >> > >> > -Greg >> > >> > -Original Message- >> > From: Austad, Jay [mailto:[EMAIL PROTECTED] >> > Sent: 29 August 2003 17:08 >> > To: [EMAIL PROTECTED] >> > Subject: dry pair >> > >> > >> > >> > Does anyone know to go about getting Qwest or a CLEC to patch through a dry >> > pair between two buildings connected to the same CO? >> > >> > When I called to order one, no one knew what I was talking about. >> > >> > -jay >> > >> > >> > Vodafone Global Content Services Limited >> > Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN >> > >> > Registered in England No. 4064873 >> > >> > This e-mail is for the addressee(s) only. If you are not an addressee, you >> > must not distribute, disclose, copy, use or rely on this e-mail or its >> > contents, and you must immediately notify the sender and delete this e-mail >> > and all copies from your system. Any unauthorised use may be unlawful. The >> > information contained in this e-mail is confidential and may also be legally >> > privileged. >> > >> >> -- >> -- >> Joel JaeggliUnix Consulting [EMAIL PROTECTED] >> GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 >>
Re: dry pair
>> Does anyone know to go about getting Qwest or a CLEC to patch through a dry >> pair between two buildings connected to the same CO? >> >> When I called to order one, no one knew what I was talking about. Try ordering a LADS circuit (they come in 2 or 4 pair). Dave
Re: Sea sponge builds a better glass fiber
>> I'm still waiting for the discovery of its natural enemy, the Backhoeiosaur. All kidding aside, my concern is that it's natural enemy has just found it. >> It's such a wonderful example of how exquisite nature is as a >> designer and builder of complex systems," said Geri Richmond, a >> chemist and materials scientist at the University of Oregon who >> wasn't involved in the study. >> >> "We can draw it on paper and think about engineering it but >> we're in the stone age compared to nature," she said. That much seems clear. Dave
route-views now present at NSPIXPII
Greetings, route-views (AS6447) is pleased to announce our presence at NSPIXPII (202.249.2.166), courtesy of Akira Kato and WIDE. The route-views project operates BGP route collectors that provide global routing data to both operator and research communities. Our web pages (http://www.routeviews.org/) can provide further background on the route-views project, the services we provide, and some of the research that has been based on the data collected. route-views is interested in local BGP peering (non-multi-hop, or so-called) with all of the ASes present at NSPIXPII. Those who would like more information or are willing to provide their view of the global routing table, please contact us at [EMAIL PROTECTED] Note that we do not announce any prefixes or use any received prefixes to route traffic; this is purely a data collection effort and looking glass-like operational tool (via telnet to a cisco-like user interface). Thanks, The route-views staff
Re: dontaing bgp config files [Re: Risk of Internet collapse grows]
Ratul, >> understanding of routing (especially inter-domain) in the research >> community is really primitive. this precludes us from having realistic >> routing models. we recently started working on understanding prevalent >> inter-domain routing policies. the ultimate goal is to improve the >> efficiency, robustness and expressiveness of routing protocols. >> http://www.cs.washington.edu/research/networking/policy-inference/ It is not clear if you mean that tools (e.g. BGP) are primitive, languages to express policy in BGP are primitive, or application of what we have (BGP + whatever language you use) is primitive. Which is it (or which subset)? Thanks, Dave
updates to complexity pages
Many people have asked to to update my complexity pages with a bit of theoretical background to to support some of the material there (in particular, percolation theory). So, as promised, I've updated http://www.maoz.com/~dmm/complexity_and_the_internet with a little (very little) bit of material on percolation theory. Questions and comments on all of this very much welcomed, Dave
Re: Internet Measurement Workshop
I very much agree with Steve. The workshop has been interesting
and relevant.
Dave
On Thu, Nov 07, 2002 at 03:58:10PM +0100, Steve Bellovin wrote:
>>
>> Let me point folk at the Internet Measurement Workshop:
>> http://www.icir.org/vern/imw-2002/ including especially the
>> link to the online proceedings. A fair number of the papers
>> have a lot of operational relevance.
>>
>> --Steve Bellovin, http://www.research.att.com/~smb (me)
>> http://www.wilyhacker.com ("Firewalls" book)
>>
some light reading on complexity and the internet
Many people have asked me to put the references from my complexity panel talk up somewhere. You can find some of the relevant literature on http://www.maoz.com/~dmm/complexity_and_the_internet I will try to keep this up to date, and please let me know if there are other documents that I should have here. Thanks, Dave
Re: Sprint multicast route list
It's there now. route-views.oregon-ix.net>sh ip mbgp sum | inc 1239 144.228.241.81 4 1239 4900318729 114266 170 00:02:34 3975 Dave On Thu, Jul 11, 2002 at 12:01:12PM -0700, David Meyer wrote: >> >> Pete, >> >> >> I'm doing some analysis of who I might be able to reach via >> >> multicast through Sprint. >> >> >> >> Sadly, route-views multicast peering with Sprint is not >> >> working at the moment. >> >> >> My mistake. I'll fix it. >> >> Dave
Re: Sprint multicast route list
Pete, >> I'm doing some analysis of who I might be able to reach via >> multicast through Sprint. >> >> Sadly, route-views multicast peering with Sprint is not >> working at the moment. My mistake. I'll fix it. Dave
Re: multicast (was Re: Readiness for IPV6)
>> the IETF's efforts have been extremely fruitful. That is good to hear. Dave
Re: multicast (was Re: Readiness for IPV6)
>> Even worse, multicast is truly only suitable for live applications; on-demand >> content can't be realistically mcasted, and users will not settle for "the movie >> starts every 15 minutes" when they've been used to live VOD with unicast. The >> only saving grace may be things like TiVo, where an intelligent agent slurps up >> live mcasts in hopes that the user may want to watch it "live" later. Really? What about DF-like technologies? Dave
Re: multicast (was Re: Readiness for IPV6)
Here's my $0.02 on the whole multicast thing. We've been at this for a number of years now, and robust, ubiquitous multicast on the internet is really nowhere in sight. Kind of sounds like QoS, and maybe there's a lesson there (20 years of research and IETF activity, yielding, well, what?). Given the amount of time and resource we've spent on multicast, the question one might ask is "why hasn't multicast succeeded"? My guess is that it is because the demand from any of the potential users of the service just isn't there (not at internet scales, at least not now). Add to this that there are other, possibly simpler mechanisms to accomplish much of the functionality that multicast envisions (e.g. application layer multicast; this even hits dial-up eyes with no modification), problems with billing models, and difficultly in deploying the existing set of protocols (too much complexity, broken architecturally on shared access exchanges, etc), and you might expect just about what we've experienced. Dave On Tue, Jul 09, 2002 at 09:56:34AM -0700, David Sinn wrote: >> >> Cynical/realist, it's a fine line. >> >> While p0rn does drive a lot of the utilization on the net, I doubt that >> the those content providers are going to be happy with sending their >> content un-protected across the net for anyone (paying or not) to see. >> So now you are into a encryption issue where you need to insure the >> receiving end can securely receive the encryption key and not share it. >> Not insurmountable, but not (that I'm aware of) possible with today's >> applications. >> >> The upshot is today's client applications need to grow to add these and >> other discussed features and functions to help the content providers. >> >> David >> >> -Original Message- >> From: Joe St Sauver [mailto:[EMAIL PROTECTED]] >> Sent: Tuesday, July 09, 2002 8:55 AM >> To: David Sinn >> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] >> Subject: Re: multicast (was Re: Readiness for IPV6) >> >> >> Hi, >> >> >There is also a "cart and horse" issue here: Where is the pervasive >> >content? >> >> At the risk of sounding somewhat cynical, I suspect the market driver >> for IP multicast will be what it often is for these sort of things: >> pr0n. >> >> My prediction? When one of the big adult hosting speciality companies >> starts IP multicasting free full length "cable cut" R-rated adult films >> in watchable MPEG1 quality, people will begin lobbying their ISP's for >> IP multicast support. >> >> Evidence supporting this assertion can be found in the popularity of >> events such as the Victoria Secret webcast, which reportedly drew >> more than a million viewers worldwide, even when streaming video was >> being done at postage-stamp-sized resolution. >> >> Of course, at the same time the pr0n channels get rolled out, there will >> >> also need to be something innocuous, like the "Field Hockey Channel" or >> the "Brand-New-Bands-Live!-From-Small-Clubs Channel" so that people will >> >> be able to use those less-embarassing content choices as their nominal >> interest when calling to request IP multicast support: "Um, hi, my >> friends >> who connect via ISP Foo up the street tell me that if you do something >> to >> your network I can get the, uh, Field Hockey channel via IC muteypast. >> I'm, >> uh, a real big field hockey fan, and I'd really love to be able to >> watch, >> uh, field hockey on my PC." >> >> >Most content providers don't want multicast because it breaks their >> >billing model. They can't tell how many viewers they have at a given >> >moment, what the average viewing time is, or any of the other things >> >that unicast allows them to determine and more importantly bill their >> >advertisers for. >> >> That's why they'll go ahead and use it as a tease/for the free publicity >> they'll get if they're the first ones to do it. People have spent a lot >> more on publicity stunts that would get a lot less coverage than this >> sort of thing would. >> >> >There is no Nielsen's Ratings for multicast so that advertisers could >> >get a feel for how many eyeballs they are going to hit. >> >> Some IP multicast products *do* offer the ability to track viewership >> (albeit at the cost of some degradation to IP multicast's otherwise >> essentially perfect scalability). Cisco's StreamWatch is one example >> that >> comes to mind. >> >> Regards, >> >> Joe
Was [Re: Sprint peering policy]
Stephen, >> I think this is the key point. Its common sense that peering >> with the downstreams will improve user quality of service by >> both reducing latency and taking unnecessary points of failure >> out of the network. Is it really common sense? If so, is the common sense correct? In fact, there is a lot of recent work that suggests that there can be a very poor (and as it turns out poorly understood) interaction between richness of interconnection and BGP dynamics; this is due, at least in part, to amplification and coupling effects that appear in some large systems. So many argue that that given the current set of protocols (i.e. BGP and its implementations), increased topological richness beyond some threshold can actually hurt robustness and reliability. And just to be clear about this, this is not a statement about peering policies themselves (I'm explicitly not commenting on that), but rather about our current understanding of some of the dynamics that exist in today's Internet. I've been trying to capture some of this in the following document (with the able help of Randy, Tim, and many others): http://www.ietf.org/internet-drafts/draft-ymbk-arch-guidelines-03.txt On the topic of interconnection richness and its (possibly unanticipated) effects, Craig and Abha's early work on this is maybe the canonical reference. For something a little more recent, see "What is the Sound of One Route Flapping", Timothy G. Griffin, IPAM Workshop on Large-Scale Communication Networks: Topology, Routing, Traffic, and Control, March, 2002. In any event, I guess the bottom line here is that sometimes what looks like common sense (or even what we have a tendency to call "conventional wisdom") may just be wrong. Dave
Re: Routing table in a file
archive.routeviews.org might have what you're looking for. Dave On Fri, Jun 14, 2002 at 11:26:39AM -0700, Roy wrote: >> >> Does anyone dump their copy of the routing table to a flat file >> regularly and make this available? I need do some queries. The web >> based versions don't accept modifiers like "lon" on the show ip bgp >> commands.
