Re: Paying for delivery of packets doesn't work
LOL, the subject was just for amusement since I know I'll get alot of flames. Of course paying for delivery of packets works... settlement based peering is what doesn't work. Mike. ps. sorry, long week and a too private sense of humor. +--- H U R R I C A N E - E L E C T R I C ---+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | [EMAIL PROTECTED] http://www.he.net | +---+
KPNQwest to be shut down ?
http://www.cbronline.com/cbr.nsf/latestnews/3D7D494A2E3C728A80256BF4001084B0?Opendocument 07/12/2002 Curtain Being Drawn on KPNQwest Network The future of the KPNQwest network looks bleak, after the Customer Support KPNQwest foundation decided to withdraw its support for the operation from 23.00 hours tonight. The foundation was co-founded by Dutch carrier KPN NV to enable the bankrupt network to continue operating while possible buyers were found. Yesterday KPN said that much of the network had already been sold off and customers had found alternative options. Consequently, traffic had dropped and the foundation sees no reason to continue supporting the network. Dutch incumbent KPN added that the receivers and banks have still not responded positively to KPN's offer to take over the remaining sections of rings 1,2 and 3 in of the KPNQwest network in Northwestern Europe. KPN added that as far as it was aware, its offer was the only concrete one. It said, whether the Foundation's decision to stop support of the network leads to its closure depends on the receivers and the banks. - André Chapuis IP+ Engineering Swisscom Ltd Genfergasse 14 3050 Bern +41 31 893 89 61 [EMAIL PROTECTED] CCIE #6023 -
sbc pbi routing
IF there is a SBC PBI routing enginer reading this can you please contact me privately. Thanks, Michael
Re: Paying for delivery of packets (was about Sprint Peering, and Importance of Content)
JC Dill [EMAIL PROTECTED] wrote: My premise is that in the end, content providers want to send lots of packets more than end users want to pay to receive them. Joe is not willing to pay an equally high rate to get the packets that content providers are willing to pay to send them. Thus, settlements. In the end, I think the cost must be borne by the end user in some way, shape or form. The first Internet boom is over. People providing content realise it isn't cheap and in the current financial climate are no longer willing to throw money away. Bandwidth is getting cheaper but employees are not. I think your ISP subscription will take care of it in the future. They will buy in content or access for their users. Perhaps AOLs model of value added services was a little premature? -- Tim
Re: No one behind the wheel at WorldCom
so I'm wrong and the two /10's can't be aggregated? On Sat, 13 Jul 2002, Stephen J. Wilcox wrote: I beg to differ... c/o Tony Bates, UU are only kept off the top spot by Telstra's apparent policy of deaggregating! 1) Gains by aggregating at the origin AS level --- 05Jul02 --- ASnumNetsNow NetsCIDR NetGain % Gain Description AS701 1234 987 247 20.0% UUNET Technologies, Inc. AS7046 313 230 83 26.5% UUNET Technologies, Inc. AS702519 473 468.9% UUNET Technologies, Inc. On Sat, 13 Jul 2002, Christopher L. Morrow wrote: Hmm.. I MIGHT be wrong here, but both: 63.0.0.0/10 and 63.64.0.0/10 are registered to UUNET (arin blocks: NETBLK-NETBLK-UUNET97DU NETBLK-UUNET63 ) These add up to 63.0.0.0/9, right? I mean, we DO want to aggregate this, right? --Chris ([EMAIL PROTECTED]) ### ## UUNET Technologies, Inc. ## ## Manager ## ## Customer Router Security Engineering Team ## ## (W)703-886-3823 (C)703-338-7319 ## ### On Fri, 12 Jul 2002, Phil Rosenthal wrote: BGP routing table entry for 63.0.0.0/9, version 7001923 Paths: (5 available, best #1, table Default-IP-Routing-Table) Advertised to peer-groups: customer Advertised to non peer-group peers: 209.123.37.30 701 157.130.9.141 (metric 65024) from 209.123.11.10 (209.123.12.59) Origin IGP, localpref 300, valid, internal, best Community: 8001:666 8001:701 701 157.130.9.141 (metric 65024) from 209.123.11.245 (209.123.12.59) Origin IGP, localpref 300, valid, internal Community: 8001:666 8001:701 8001 7911 3561 701 64.200.86.149 from 64.200.86.149 (64.200.87.10) Origin IGP, localpref 200, valid, external Community: 8001:666 8001:7911 7911 3561 701, (received-only) 64.200.86.149 from 64.200.86.149 (64.200.87.10) Origin IGP, localpref 100, valid, external 15036 16631 174 701 209.123.37.30 from 209.123.37.30 (209.123.132.181) Origin IGP, localpref 100, valid, external Community: 8001:666 8001:16631 15036:0 15036:666 15036:16631 16631:1000 From: http://eng.nac.net/lookingglass/nyc.html Bgp: 63.0.0.0 Uunet has been announcing this for more than 2 days now. (not sure when since I cleared my bgp tables 2 days ago). --Phil
Re: No one behind the wheel at WorldCom
I beg to differ... c/o Tony Bates, UU are only kept off the top spot by Telstra's apparent policy of deaggregating! I don't speak for UUNET, not a shareholder, don't have any say over their routing policies; that said, there are a couple reasons that might be the case: 1. Deaggregation to help spread out traffic flow. As someone who used to send a lot of traffic toward some big providers, it can be hard to balance traffic efficiently when all you get is one short prefix at multiple peering points. Having more-specifics, and possibly even MEDs that make sense, can help with decisions regarding which part of a /9 can be reached best via which peering point. (And that's peering as in BGP, not peering as in settlements.) 2. Cut-outs for those pesky dot-coms; you know, the ones with the most compelling content on the Internet jumping up and down in your face with a need to multi-home their /24 to satisfy the crushing global demand for such essentials as the hamster dance. I can easily imagine that when you have a lot of customers (as UUNET is purported to have), you'd have the above two situations in spades, plus more that we'll no doubt discuss at great length for the next week. Let's consider the converse, though - what if AS701 were to suddenly become a paragon of routing table efficiency, and collapse all their announcements into one (not possible, I know, but indulge me, please)? First, some decrease in revenue because all the more-specifics for multi-homed customers would be preferred over the one big AS701 announcement. Second, a traffic balancing nightmare as everyone who touches AS701 in multiple places tries to figure out how to deliver traffic to AS701 efficiently. While Tony's report certainly indicates that things could be better, it is also true that they could be a lot worse. Stephen
Re: No one behind the wheel at WorldCom
Just having my saturday afternoon stir really but .. : On Sat, 13 Jul 2002, Stephen Stuart wrote: I beg to differ... c/o Tony Bates, UU are only kept off the top spot by Telstra's apparent policy of deaggregating! I don't speak for UUNET, not a shareholder, don't have any say over their routing policies; that said, there are a couple reasons that might be the case: 1. Deaggregation to help spread out traffic flow. As someone who used to send a lot of traffic toward some big providers, it can be hard to balance traffic efficiently when all you get is one short prefix at multiple peering points. Having more-specifics, and possibly A slight exaggeration, large providers have more than one assignment of IPs and according to the RIR info they are used regionally anyway even MEDs that make sense, can help with decisions regarding which part of a /9 can be reached best via which peering point. (And that's peering as in BGP, not peering as in settlements.) 2. Cut-outs for those pesky dot-coms; you know, the ones with the most compelling content on the Internet jumping up and down in your face with a need to multi-home their /24 to satisfy the crushing global demand for such essentials as the hamster dance. Overlap the more specific with the main block? (I assume) Tony's report shows originating AS, in which case the sub-assignments wont show towards UUs count. I can easily imagine that when you have a lot of customers (as UUNET is purported to have), you'd have the above two situations in spades, plus more that we'll no doubt discuss at great length for the next week. Let's consider the converse, though - what if AS701 were to suddenly become a paragon of routing table efficiency, and collapse all their announcements into one (not possible, I know, but indulge me, please)? First, some decrease in revenue because all the more-specifics for multi-homed customers would be preferred over the one big AS701 announcement. They will still announce the customer's BGP more specifics tho? Second, a traffic balancing nightmare as everyone who touches AS701 in multiple places tries to figure out how to deliver traffic to AS701 efficiently. As above, it is at least as far as I can tell assigned per country. Steve While Tony's report certainly indicates that things could be better, it is also true that they could be a lot worse. Stephen
Re: No one behind the wheel at WorldCom
On Sat, 13 Jul 2002, Stephen Stuart wrote: 1. Deaggregation to help spread out traffic flow. As someone who used to send a lot of traffic toward some big providers, it can be hard to balance traffic efficiently when all you get is one short prefix at multiple peering points. Having more-specifics, and possibly even MEDs that make sense, can help with decisions regarding which part of a /9 can be reached best via which peering point. (And that's peering as in BGP, not peering as in settlements.) Legend speaks of a well known BGP community referred to as 'no export', which causes people with no direct connections to $carrier to not have to listen to all that extra junk while still engineering inbound traffic w/ more specifics for people who peer directly in diverse locations. Amazing! 2. Cut-outs for those pesky dot-coms; you know, the ones with the most compelling content on the Internet jumping up and down in your face with a need to multi-home their /24 to satisfy the crushing global demand for such essentials as the hamster dance. Ignoring inconsistent-as for a moment, the hamster dance multihoming doesn't make the parent upstream need to _originate_ anything of the sort. Paul
Re: No one behind the wheel at WorldCom
1. Deaggregation to help spread out traffic flow. As someone who used to send a lot of traffic toward some big providers, it can be hard to balance traffic efficiently when all you get is one short prefix at multiple peering points. Having more-specifics, and possibly A slight exaggeration, large providers have more than one assignment of IPs and according to the RIR info they are used regionally anyway Yes, but as the prefix length gets shorter, you lose visibility into how traffic might efficiently be divided up among the points at which a prefix is offered (whether you listen to MEDs or manipulate metrics yourself). Treating North America as a region, a provider might announce a /8 at five different places in that region. For any given point, you might be trying to reach a more-specific that's in the same city, or across the continent. To the extent that providers announce longer prefixes because that's what the RIRs gave them, and practice allocation policies that concentrate use of that space topologically within their network, yes, your comment is a sensible refinement of mine. The practice of announcing more-specifics to help peers with traffic engineering is certainly in use today (just as the practice of not doing so is in use today); the extent to which that puts AS701 where it is on Tony's list is something I don't know. I'm assuming, though, that application of that practice by AS701 would cause them to be higher on Tony's list than if they did not engage in that practice. Whether AS701 thinks that way or not is up to AS701 folks to say (or not). 2. Cut-outs for those pesky dot-coms; you know, the ones with the most compelling content on the Internet jumping up and down in your face with a need to multi-home their /24 to satisfy the crushing global demand for such essentials as the hamster dance. Overlap the more specific with the main block? (I assume) Tony's report shows originating AS, in which case the sub-assignments wont show towards UUs count. I was making the assumption that longer prefixes within a shorter one did contribute to what Tony is counting. Let's consider the converse, though - what if AS701 were to suddenly become a paragon of routing table efficiency, and collapse all their announcements into one (not possible, I know, but indulge me, please)? First, some decrease in revenue because all the more-specifics for multi-homed customers would be preferred over the one big AS701 announcement. They will still announce the customer's BGP more specifics tho? You're applying reality to the example. This is a contrived example to illustrate the end of the spectrum where AS701 emits one very short prefix - kind of like some IPv6 people seem to think that inter-provider routing should work (to use a current analogy). Second, a traffic balancing nightmare as everyone who touches AS701 in multiple places tries to figure out how to deliver traffic to AS701 efficiently. As above, it is at least as far as I can tell assigned per country. What do countries have to do with this? AS701 is UUNET's North American (for the most part) AS number. It is possible to have a handful of attachments to it within the United States alone. As noted above, if AS701 were to announce a short prefix with no more-specifics at several points, your options to efficiently balance traffic among those points are less than if you were supplied with more-specific prefixes that give you clues as to how the short prefix is partitioned internally (say, east-coast US vs. west-coast US). Stephen
Re: No one behind the wheel at WorldCom
On Sat, 13 Jul 2002, Stephen Stuart wrote: Indeed, I know from personal experience the heartbreak of supplying no-export to a BGP peer who does not honor it, and propagates the more-specific prefixes that I give them globally. I'm wondering how many folks out there choose not to honor this community and why. If anyone on the list chooses not to I'd be interested to hear (either on-list or off) the reasonings behind it. Paul
Re: Paying for delivery of packets (was about Sprint Peering, and Importance of Content)
As a telco we see a number of these services, based around premium rate dialup access. I have to say that so far none appears to have worked even ones we have done that were advertised as part of the largest TV shows at the time. For most applications, eg sports, porn it can only work if the information is i) unique to this site ii) worth paying for .. point (i) seems to be the biggest issue stopping success thus far. For value add to really work you have to be offering a product/service that cannot be obtained for free anywhere else on the Internet, as most services on offer are just one of a number of competitors doing the same thing then most of the competitors need to go down the value add road if they are to succeed. Steve On Sat, 13 Jul 2002, Tim Thorne wrote: JC Dill [EMAIL PROTECTED] wrote: My premise is that in the end, content providers want to send lots of packets more than end users want to pay to receive them. Joe is not willing to pay an equally high rate to get the packets that content providers are willing to pay to send them. Thus, settlements. In the end, I think the cost must be borne by the end user in some way, shape or form. The first Internet boom is over. People providing content realise it isn't cheap and in the current financial climate are no longer willing to throw money away. Bandwidth is getting cheaper but employees are not. I think your ISP subscription will take care of it in the future. They will buy in content or access for their users. Perhaps AOLs model of value added services was a little premature? -- Tim
Re: QoS/CoS in the real world?
Well, end of the week and the responses dried up pretty quickly, I think thats a response in itself to my question! Okay, heres a summary which was requested by a few people: Other people too are interested in my questions, they dont implement QoS in any saleable manner and wonder how it can be done and whats actually required. A number of people think QoS was interesting for a while but that its never either found its true use or is dead. There are unresolved questions from a customer point of view as to what they are actually going to get, what difference it will make and how they can measure their performance and the improvements from QoS. There is a real demand for guaranteed bandwidth, however this tends to be in the form of absolute guarantees rather than improvements above normal hence ATM remaining a popular solution. There is a requirement to differentiate voice traffic, however this is necessarily done by the network anyway in order to offer the service, this being the case the customer doesnt pay extra or gets to know much about how all the fancy bits are done. On the face of it this is all negative. Nobody has responded saying there are genuine requirements for services to be offered to customers. Nor has anybody responded with any descriptions of implementations. I conclude either the people doing this are successful and keep their secret safe or the world is yet to sell largescale QoS across IP. Steve On Mon, 8 Jul 2002, Stephen J. Wilcox wrote: Hi all, I've been looking through the various qos/cos options available, my particular area was in how IP (MPLS perhaps) compares and can be a substitute for ATM. Well, theres lots of talk and hype out there, from simple IP queuing eg cisco priority queuing, rsvp, diffserv, mpls traffic engineering etc But two things are bugging me.. 1. To what extent have providers implemented QoS for their customers 2. Hype aside, to what extent do customers actually want this (and by this I dont just mean that they want the latest QoS because its the 'latest thing', there has to be a genuine reason for them to want it). And this takes me back to my ATM reference where there is a clear major market still out there of ATM users and what would it take to migrate them to an IP solution? Also, how are people implementing bandwidth on demand (dynamic allocation controlled by the customer) solutions to customers Cheers Steve
Re: KPNQwest to be shut down ?
Well our transit BGP just this minute went along with the circuit to KPNQ. I cant confirm as theres no NOC but looks like it may be it .. ? Steve On Sat, 13 Jul 2002, Andre Chapuis wrote: http://www.cbronline.com/cbr.nsf/latestnews/3D7D494A2E3C728A80256BF4001084B0?Opendocument 07/12/2002 Curtain Being Drawn on KPNQwest Network The future of the KPNQwest network looks bleak, after the Customer Support KPNQwest foundation decided to withdraw its support for the operation from 23.00 hours tonight. The foundation was co-founded by Dutch carrier KPN NV to enable the bankrupt network to continue operating while possible buyers were found. Yesterday KPN said that much of the network had already been sold off and customers had found alternative options. Consequently, traffic had dropped and the foundation sees no reason to continue supporting the network. Dutch incumbent KPN added that the receivers and banks have still not responded positively to KPN's offer to take over the remaining sections of rings 1,2 and 3 in of the KPNQwest network in Northwestern Europe. KPN added that as far as it was aware, its offer was the only concrete one. It said, whether the Foundation's decision to stop support of the network leads to its closure depends on the receivers and the banks. - André Chapuis IP+ Engineering Swisscom Ltd Genfergasse 14 3050 Bern +41 31 893 89 61 [EMAIL PROTECTED] CCIE #6023 -
Re: KPNQwest to be shut down ?
Hi I Could confirm that the AS286 is dead in Spain (286 2845249 754590 00 1d17hActive) The national AS2134 appears to be live but announce only 14 prefix. They announce to us 100 prefix before of their financial crash. Regards, Daniel On Sunday 14 July 2002 02:48, Stephen J. Wilcox wrote: Well our transit BGP just this minute went along with the circuit to KPNQ. I cant confirm as theres no NOC but looks like it may be it .. ? Steve
RE: No one behind the wheel at WorldCom
What vendor by default does not take action on no-export??? Certainly cisco and juniper both honor it by default. To get back to the original question of 63/9 being announced it can be entertaining to watch for other fishy routes to show up in the routing table, like 63/8. I know of at least one outage caused because someone advertised a route like that. The underlying problem, is that there are no good widely deployed solutions for controlling what the large backbones inject into the routing table at peering points. A large tier 1 deaggregates towards another bad things happen. It would be nice if there was a supportable way to only allow one isp to advertise appropriate routes to another. The IRR stuff is a neat idea but I dont think many ISPs trust it enough to use it to build ACLs. -Original Message- From: Stephen Stuart [mailto:[EMAIL PROTECTED]] Sent: Sat 7/13/2002 7:00 PM To: [EMAIL PROTECTED] Cc: Paul Schultz Subject:Re: No one behind the wheel at WorldCom I'm wondering how many folks out there choose not to honor this community and why. If anyone on the list chooses not to I'd be interested to hear (either on-list or off) the reasonings behind it. Please also respond if you weren't aware that you have to explicitly implement the policy of honoring no-export - while the community vaue is well-known, the policy is not built-in.
Re: No one behind the wheel at WorldCom
On Sat, Jul 13, 2002 at 09:21:16PM -0400, Frank Scalzo wrote: The underlying problem, is that there are no good widely deployed solutions for controlling what the large backbones inject into the routing table at peering points. A large tier 1 deaggregates towards another bad things happen. It would be nice if there was a supportable way to only allow one isp to advertise appropriate routes to another. The IRR stuff is a neat idea but I dont think many ISPs trust it enough to use it to build ACLs. If everyone maintained current IRR entries, it would work just fine. The real problem is there are still a lot of networks who's idea of filtering their customers is a prefix-limit or a filter you have to call or email in manually. The only people who actually maintain accurate IRR entries (other than the occational net kook) are those whose transit depends on it. Trying to convert an existing customer base to IRR is a nightmarish task, some of these large established providers will probably NEVER do it unless there is some actual motivation. Supposidly Level 3 requires IRR filtering on their peers, but do they actually try to enforce this? I know they do an excellent job maintaining their own IRR entries, but I'm certain they peer with people who don't have a current db. Probably not, since the vast majority of their current peers don't meet their current peering requirements. :) -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: No one behind the wheel at WorldCom
On Sat, Jul 13, 2002 at 10:20:01PM -0400, Richard A Steenbergen wrote: Supposidly Level 3 requires IRR filtering on their peers, but do they actually try to enforce this? I know they do an excellent job maintaining their own IRR entries, but I'm certain they peer with people who don't have a current db. Probably not, since the vast majority of their current peers don't meet their current peering requirements. :) Hehehe ok someone answered this question for me privately... For example: whois -h whois.radb.net 64.206.3.0/20 ... route: 64.206.3.0/24 descr: Proxy-registered route object for Sprint :-) origin:AS7136 remarks: auto-generated route object remarks: this next line gives the robot something to recognize remarks: The quick brown fox jumped over the lazy dog. remarks: remarks: This route object is for a Sprint customer route remarks: which is being exported under this origin AS. remarks: remarks: This route object was created because no existing remarks: route object with the same origin was found, and remarks: we really just wanted to help out those poor Sprint remarks: folks who have an aversion to registering routes. remarks: remarks: We hope they have a sense of humor. remarks: remarks: Please contact [EMAIL PROTECTED] remarks: if you have any questions regarding this object. mnt-by:SPRINT-MNT changed: [EMAIL PROTECTED] 20020626 source:LEVEL3 -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: No one behind the wheel at WorldCom
On Sat, Jul 13, 2002 at 04:00:42PM -0700, Stephen Stuart wrote: Please also respond if you weren't aware that you have to explicitly implement the policy of honoring no-export - while the community vaue is well-known, the policy is not built-in. If you do not wipe out the communities that you receive, then no-export works as expected. But if you have a route-map or import policy that explicately removes or overwrites all received communities, then no-export is deleted as well, and thus does not do anything. --asp
Re: No one behind the wheel at WorldCom
On Sat, Jul 13, 2002 at 04:00:42PM -0700, Stephen Stuart wrote: Please also respond if you weren't aware that you have to explicitly implement the policy of honoring no-export - while the community vaue is well-known, the policy is not built-in. If you do not wipe out the communities that you receive, then no-export works as expected. But if you have a route-map or import policy that explicately removes or overwrites all received communities, then no-export is deleted as well, and thus does not do anything. Hmm. Okay, but I'm looking at a route-map clause that does a comm-list NNN delete where the no-export community would be permitted by comm-list NNN ... and shucks, that's it, isn't it? Since the no-export community would get permitted by the list, it's getting deleted (I saw deny and delete and put them together instead of permit and delete). Time to open a ticket, I guess. :-/ Thanks. Stephen
