RE: U.S. officials deny technical takedown of WikiLeaks
Nathan Eisenberg nat...@atlasnetworks.us wrote: As someone who was personally connected to this (http://www.komonews.com/ne= ws/local/78088192.html), and this, http://www.komonews.com/news/local/68320= 537.html I feel pretty justified in telling you to keep this 'shoot a pig' = crap off the list. To all uniformed dudes reading this: if you don't want the people you serve to feel like shooting you, perhaps you should consider going on strike, immediately stopping enforcing any and all man-made laws that go against the natural law of Universe, against common sense and against basic humanity; immediately stopping following any and all orders telling you to do things that are morally wrong, and finally, switching over to our side, helping defend America and the American People against USA. In the timeless words of The Internationale: No more deluded by reaction, On tyrants only we'll make war; The soldiers too will take strike action, They'll break ranks and fight no more! And if those cannibals keep trying To sacrifice us to their pride, They soon will hear the bullets flying: We'll shoot the generals on our own side! MS Hold the Heathen Hammer High! With a battle cry! For the pagan past I live and one day will die.
Re: U.S. officials deny technical takedown of WikiLeaks
Jorge Amodio jmamo...@gmail.com wrote: If you get a court order I guess you have two choices, one is to comply with it and the other get used to wear a nice pair of matching bracelets until your attorney shows up. Option 3: unleash your full firepower against the miscreants who have dared to invade your soil despite the sign at the gate which reads in plain English: THIS FACILITY IS EXTRATERRITORIAL AND IS NOT PART OF ANY COUNTRY NO MAKERS OR ENFORCERS OF ANY FORM OF MAN-MADE LAW ARE ALLOWED ON THE PREMISES DEADLY FORCE WILL BE USED AGAINST ANY NATIONAL AUTHORITIES TRESPASSING PAST THIS BOUNDARY! Factoid: we outnumber the pigs by 1000 to 1. Even if only 1% of us were to go out and shoot a pig, we would still outnumber them 10 to 1! We *CAN* win -- wake up, people! American People vs. USA -- let's see who is stronger. MS Hold the Heathen Hammer High! With a battle cry! For the pagan past I live and one day will die. http://www.youtube.com/watch?v=fu2bgwcv43o
Re: Token ring? topic hijack: was Re: Mystery open source switching
Jacob Broussard shadowedstran...@gmail.com wrote: Wow... Reading this thread I feel like some sort of time traveler, what with my cable internet, multicore processor, and smartphone. Just in case it isn't clear, I use all of my ancient computing and network technology by a *very* deliberate choice. Just take the case of the hardware gadget I've designed and built myself that goes from SDSL/ATM to V.35-nee-EIA-530: I've only built and deployed it in the summer of this year, although I had wanted one since late 2004 and had been developing it as a hobby open source hardware project since 2006. MS
Re: Token ring? topic hijack: was Re: Mystery open source switching
Gary Baribault g...@baribault.net wrote: And you live in a cabin in the woods, pedal a generator to get the router up and the router is connected to a 56K Dial-up morem? I have never used those 56K dial-up modems because they are asymmetric: it's only 56K in the downstream direction, and I oppose that on principle. Prior to switching to my current 384 kbps SDSL (served by a V.35 CPE device of my own design and make, see earlier messages in this thread), I was using an always-on (immediate redial on disconnect) analog modem connection at 31200 bps. One of the 4.3BSD-Quasijarus MicroVAXen acted as the router, and the PPP implementation in the kernel was written by me from scratch: the original non-Quasijarus 4.3BSD only had SLIP. MS
Re: Token ring? topic hijack: was Re: Mystery open source switching
Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote: Not only token ring. I know of some coaxial ethernets that were running as late as 2007. The network I am using to compose and post this message right now is a coaxial Ethernet. MS
Re: Token ring? topic hijack: was Re: Mystery open source switching
Carlos Martinez-Cagnazzo carlosm3...@gmail.com wrote: Hats off!! You should post some pictures! As in ASCII art pictures? Because my life revolves around ASCII text and I abhor anything that isn't ASCII text, I do not own a camera of any kind, never have and likely never will. MS
Re: Token ring? topic hijack: was Re: Mystery open source switching
Michael Painter tvhaw...@shaka.com wrote: Thick or Thin? Thin. I *so* wish I had thick coaxial Ethernet, but alas, my present physical facility is just too small for that: my present coax Ethernet network is contained within a single machine room which is a converted bedroom. MS
Re: Token ring? topic hijack: was Re: Mystery open source switching
I wrote: : Thin. I *so* wish I had thick coaxial Ethernet, but alas, my present : physical facility is just too small for that: my present coax Ethernet : network is contained within a single machine room which is a converted : bedroom. Forgot to add: this thin coax Ethernet interconnects several MicroVAXen (including ivan.Harhan.ORG, the machine on which my mail lives and from which I am sending this post) running 4.3BSD-Quasijarus, and a Cisco 2500 router which connects my retrocomputing centre to ARPANET^H^H^H^H^H^H^HSDSL. The SDSL connection is made via a device of my very own design and make that connects to the copper pair, handles the physics of 2-wire full-duplex transmission, and converts SDSL/ATM to V.35, or more precisely EIA-530, which then goes to the Cisco 2500. MS
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
Leo Bicknell bickn...@ufp.org wrote: There really isn't a lot of choice, 2 providers, and some minor choice in how much speed you want to pay for with each one. Does that mean no CLECs like Covad or DSL.net who colocate in the ATT CO, rent unbundled dry copper pairs and take it up from there themselves? Does that mean no ISPs who buy/rent last+middle mile transport from ATT ADSL network at Layer 2 (ATM) and provide their own IP layer? MS
Re: Did Internet Founders Actually Anticipate Paid, Prioritized Traffic?
Leo Bicknell bickn...@ufp.org wrote: Part of the reason for this is U-Verse is FTTN, Fiber to the Node. ATT has run fiber to my neighborhood, I believe the node in my case is about 1000 feet away (I drive past it on the way out). The electronics sit there, so the old model of colocating in the CO and getting the dry pair is no longer possible, the copper stops at the node and it's a largeish (6' wide, 3' deep, 5' tall) cabinet, so there's no colo. We have that exact same stuff in my area too: I've actually talked to the ATT tech who was setting that cabinet up on one of our streets. The explanation he gave me was that even though they want everyone to go to this new-fangled fiber thing, they still have to maintain a small number of copper pairs running all the way to the real CO like it used to be. The reason is that if some kooky customer like me wants a service like ISDN that's only available from the real Class 5 switch and not from the U-Verse remote terminal, they are still required to provide that as a regulated telco. Ditto with CLECs like Covad-now-MegaPath: even though they don't get access to the FTTN infrastructure, no telco is evicting their legacy CO presence. Therefore, if a kooky customer like me wishes to forego fiber speeds and prefers the slower all-copper solution, I can still get SDSL from the CLEC, and the ILEC (ATT) will be required to provide a direct copper pair from that CLEC's cage inside the CO to the customer premise, no matter how much they wish for these copper pairs to die. Long live copper! MS
Re: Mikrotik OC-3 Connection
OK, I'll bite and add my 2 Russian kopecks to the Cisco vs. Linux router thread. To make it clear where I'm coming from, I see the networking world from the viewpoint of non-Ethernet WAN interfaces. A world consisting of nothing but Ethernet is too bland and boring for me to live in, and I choose not to live in such an Ethernet-only world. I do indeed like the good old ifconfig route better than Cisco IOS stuff: it's simpler, makes more sense to me, and fits my simple needs. However, this model works well for Ethernet because it's very simple: with Ethernet one generally has a 1:1 correspondence between the physical hardware unit and the logical network interface unit visible to ifconfig and the rest of the BSD/Linux network stack. But that is most definitely not the case for non-Ethernet WAN interfaces, and that is where I see a big shortcoming in what's currently available in the Linux router world. With non-Ethernet WAN interfaces one really needs an extra layer of highly configurable software functionality sandwiched in between the hardware interface unit and the ifconfig layer. The physical hardware interface is a synchronous serial bit stream processor that sends and receives either HDLC frames or ATM cells, and that is where the hardware-dictated part ends. Let's take the case of HDLC as it's more pleasant than ATM: in the case of HDLC the software layer between the HDLC controller and the ifconfig layer needs to do the following: * Let the user choose the encapsulation, and there are many choices: Cisco HDLC, straight PPP (RFC 1662), Frame Relay, PPP over FR (RFC 1973), ATM FUNI, etc. * If it's a Frame Relay encapsulation, let the user configure DLCIs. Oh, and there can be more than one, hence there may be multiple ifconfig-able entities on the same FR interface. * RFC 1490 (FR) and RFC 1483 (ATM) both allow bridged/MAC-encapsulated and true routed circuits; our software layer should support both, as as well as the possibility of mixing the two on different FR interfaces or different DLCIs on the same interface. These two modes need to look different to the ifconfig layer: if it's a bridged encapsulation, ifconfig needs to see a virtual Ethernet interface (virteth0 or macwan0); if it's a true routed encapsulation, ifconfig needs to see a MAC-less and ARP-less point-to-point interface like ipwan0. * Now let's support both HDLC and serial ATM (bit-by-bit cell delineation) if the underlying hardware is capable of both (like Freescale MPC862 and MPC866). Let's provide a user to switch between the two with a simple software command, and let's provide as much commonality as possible between the two configurations: let's support all RFC 1483 encapsulations on HDLC via FUNI, but make the configuration commands look just like ATM. Let's also support FRF.5 by allowing one to take an ATM PVC and treat its payload as a virtual HDLC interface, with possibly many FR DLCIs inside. I would love to be corrected on this, but I am not aware of anyone having implemented all of the above for Linux (or for any BSD variant) in a clean and generalized manner. Instead what we see is that each vendor of a PCI card for some non-Ethernet WAN interface has their own ad hoc solution which typically comes nowhere close to what I've outlined above in terms of generality and flexibility. Now here is something I'd like to build which will attempt to solve this mess. I'd like to build a modular WAN router based on the MPC866 chip from Freescale, former Motorola. MPC866 is a PowerPC with one very neat twist: it has 4 serial communication controller (SCC) cores on chip. Each SCC has a traditional 7-wire serial interface coming out of it (Rx data, Rx clock, Tx data, Tx clock, RTS, CTS and CD) and supports both HDLC and serial ATM. (The serial ATM mode supports both bit-by-bit cell delineation for a raw bit stream and octet-by-octet cell delineation for use with a framer that provides octet boundaries.) My modular router would be rather unique in that the interface to the pluggable WAN modules would not be PCI or anything of that sort, instead it would be the 7-wire serial interface coming from an MPC866 SCC, and there would be 4 possible daughtercard slots corresponding to the 4 SCCs. When the interface for pluggable WAN modules is something like PCI, the HDLC or ATM (including SAR) core has to be reimplemented anew by everyone who wants to build a new WAN module for a different flavor of Layer 1 physical interface, and I find it wasteful. The proliferation of such reinvented-wheel HDLC/ATM reimplementations is precisely the reason why there is no universally-accepted standardized framework for non-Ethernet WAN interfaces in Linux or *BSD. But if the cores implementing HDLC and ATM SAR reside inside the CPU chip like they do with MPC86x processors, we can have ONE well-written generic driver for these cores, and it will work exactly the same way and provide exactly the
Re: Mikrotik OC-3 Connection
Adrian Chadd adr...@creative.net.au wrote: FreeBSD netgraph. It's clean, it's generalised, it's just not very well documented. [...] Have a chat to the FreeBSD community. There's a powerpc port. Shoehorn FreeBSD into it somehow, help tidy up the code to do whateveer you need and start leveraging the very powerful network stack FreeBSD has. Thanks for the tip - that sounds very nice indeed, very much like what I had in mind. It's nice to know that *someone* in the generic free OS world has had the foresight to design this thing right. (Just to be clear, I have no political preferences between Linux and FreeBSD; to me it's all a matter of what works and what I'm familiar with.) But it won't matter until I build the hardware: I want to build the hardware first, the HW itself will be totally open source as in free schematics and full docs etc, and then we'll think about which free OS(es) we want to run on it. I still want to build my MPC866 router platform though: even if the software part has been solved by the fine FreeBSD folks, with the present situation (PCI as the expansion interface on FreeBSD/Linux-based routers) one still has the issue that the HDLC interface or the ATM SAR block has to be wheel-reinvented each time someone wants a different flavor of Layer 1 physical interface. The situation is even more pronounced when a given Layer 1 medium type (say, T1 or SDSL) exists in both HDLC and ATM flavors. I would really like to be able to have a single hardware card that supports both: it is trivial with MPC86x, but I expect it to be cost-prohibitive to do that on a PCI card. MS
Re: What is The Internet TCP/IP or UNIX-to-UNIX ?
Jim Mercer j...@reptiles.org wrote: if the script determined an email was X bytes (100k?), the message body was rewritten with: Contents removed at LSUC, email is not a file transport protocol. and the mail was left to continue on its path. i kinda feel like adding the same script back into my servers. I have my Sendmail configured to cut off anything past 256 KB in the collect phase. At first I had it configured to reject the whole message (close the SMTP connection while the junk is still spewing), but people started assuming that my E-mail address was bad instead of realizing that they were sending oversize junk, so I've changed it to cut off and discard the excess fat, but still let the first 256 KB through so I at least see that someone tried to send me something. Files are meant to be FTPed, not E-mailed. If someone is too stupid to use a real command line FTP client to upload a file to my FTP drop box, I make them use www.yousendit.com. MS
Juniper's artificial feature blocking (was legacy /8)
Tore Anderson tore.ander...@redpill-linpro.com wrote: Juniper. If you want to run OSPFv3 on their layer 3 switches, you need a quite expensive advanced licence. OSPFv2, on the other hand, is included in the base licence. Really? My level of respect for Juniper has just dropped a few notches after reading this NANOG post - I didn't know that they were engaged in such DRM-like feature blocking practices. Where can I find more information about Juniper's stance on such practices (having some feature X present in both HW and SW, but artificially blocked until one buys an unlock key from them) and the exact degree to which they engage in such? The reason I ask is because I've been considering building my own PIM for their J-series, a PIM that would terminate Nokia/Covad's flavor of SDSL/2B1Q at the physical layer and present an ATM interface to JunOS, optionally supporting NxSDSL bonding with MLPPPoA. I have no love for routers that aren't 100% FOSS, but I couldn't find any other existing router platform which could be extended with 3rd-party physical interface modules, and designing and building my own base router chassis is not a viable option if I want to actually have something built before the Sun swells into a red giant and engulfs the Earth. So I thought that even though it isn't 100% FOSS, JunOS ought to be at least tolerable given that it appears to be based on FreeBSD and I've heard that it even allows the user to get direct access to the underlying Unix shell (does it really?) - but hearing about DRM-like artificial feature blocking seems to negate that. I mean, how could their disabled-until-you-pay blocking of premium features be effective if a user can get to the underlying Unix OS, shell, file system, processes, etc? Wouldn't such access allow smart users to unblock whatever feature is artificially blocked? Someone please educate me... MS
Re: what about 48 bits?
Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: Has anybody considered lobbying the IEEE to do a point to point version of Ethernet to gets rid of addressing fields? [...] Actually the minimum 64 byte packet size could probably go too, as that was only there for collision detection. And maybe rename it to something else while you are at it? All those people who have hijacked the name Ethernet for PtP links (all those Ethernet UTP media are really PtP at the physical level, unlike real coaxial Ethernet) are despicable thieves - now those of us who are still using the original coaxial Ethernet in the shared bus mode are left without a clear, unique and distinctive name we once had to refer to what we use. MS
Re: Is TDM going the way of dial-up?
Kevin Oberman ober...@es.net wrote: And, if you are using a 1988 TCP stack on a 4.3 system, you are not likely to ever efficiently utilize a higher speed link What higher speed link? I'm very happy with 384 kbps symmetric, using SDSL as ARPANET replacement. I have designed and built my own SDSL to EIA-530 CSU/DSU so I can use a Cisco 2500 router instead of that nasty new-fangled Netopia which has (oh horror!) RJ45 Ethernet instead of proper AUI. Oh, did I forget to mention that my Ethernet is coaxial? To me all that UTP stuff isn't true Ethernet. and will not behave well on any link. TCP has come a long way in the past 12 years. (Of course, I can't guess what mostly unchanged means.) Backward compatibility rules! MS
Re: Is TDM going the way of dial-up?
Rick Ernst na...@shreddedmail.com wrote: I've noticed over the last 3 years or so that TDM, specifically T-1, access and transport has been in a steady decline. Customers are moving to FTTH and cable, or going WiMAX and Metro-Ethernet. Ethernet seems to have taken an even bigger bite out of DS-3. The bigger pipes seem to favor ethernet. A recent upgrade from OC-3 to GigE transport actually saved us a large chunk of money. I'm wondering if others are seeing the same behavior, if it's market-dependant, or if I'm just imagining things. Unfortunately what you are seeing is indeed where the world is going, and it is extremely painful to watch. My personal preference is the direct opposite of that: Ethernet for non-LAN use is my very antithesis, I hate it to the core of my being. V.35/HDLC forever for me! I will continue using HDLC over traditional synchronous serial WAN media for as long as I am alive. MS P.S. This message is being sent from a VAX running a variant of 4.3BSD (Quasijarus). Almost the entire ARPA Internet software stack that's running on my VAXen is mostly unchanged from how it was in 1988.
Re: CSIRT - Backbone Security : Runtime Monitoring and DynamicReconfiguration for Intrusion Detection Systems
My spammy sense is going nuts just at the whole ALL CAPS of this guy's last name. I thought all-uppercase last names were a traditional French convention... This guy is French, isn't he? - judging by his name. His habit of addressing everyone as Mister is peculiar indeed, but maybe he is really just very new to the customs and conventions of the Anglophone Internet community? Just wondering... MS
Any old Nokia DSLAMs gathering dust?
Hello NANOGers, I wonder, would anyone here happen to have an unused Nokia / Diamond Lane Speedlink DSLAM chassis that's laying around gathering dust and which you wouldn't mind donating to an open source xDSL CPE project? Just wondering if anyone here might perchance have one they are trying to get rid of - after all, one man's garbage is another man's treasure... MS
SDSL vs T1 (was Locations with no good Internet)
Patrick Giagnocavo patr...@zill.net wrote: Isn't this really an issue (political) with tariffed T1 prices rather than a technical problem? Yes, of course. It's even worse if you are tied to one particular ISP (VZB) by non-portable IP addresses. I wanted service from AS701 with a V.35 hand-off; both requirements (the ISP choice and the hand-off type) were/are for sentimental reasons. Speed was/is a lower-priority concern, i.e., I was/am willing to live with sub-T1 speeds if it allows me to keep my 701-assigned IP addresses for a lower monthly extortion payment. My choices were: 1. Get a T1, enjoy the bandwidth (I live in an alternate Universe in which T1 bandwidth is almost infinity) and the SLA, and getting a V.35 hand-off would have been as easy as pulling an Adtran DSU out of my junk pile. But it was something like $650/month, probably before adding taxes and other extortions. 2. Opt for SDSL instead. I'm within a short walk of my CO, but I opt for only 384 kbps to reduce the monthly extortion payment. And since I still want V.35 hand-off, add the expense of designing and building my own CPE for it - but it's a one-time expense, and I have learned a *lot* in the process - as they say, happiness is a journey, not a destination. I was told that most T1s are provisioned over a DSLAM these days anyways, and that the key difference between T1 and DSL was the SLA (99.99% guarantee vs. when we get it fixed). My situation is different because I am deliberately opting for a lower- speed service than what's available. At sub-T1 speeds SDSL has one advantage: the actual electrical signaling rate on the circuit is lowered to match the subscription data rate, unlike the fractional T1 kludge. But if you are specifically looking for a 1.5 Mbps service and are prepared to pay for 1.5 Mbps, the T1 vs. SDSL trade-off starts to look murkier: * With a T1 regardless of who serves it to you and how, you still get the classic HDLC encapsulation supported by every decent WAN router; with SDSL served out of a Covad DSLAM you get ATM cells on the line, wrapped in a wacky frame format: http://ifctfvax.Harhan.ORG/OpenWAN/2B1Q/flavors/nokia.html * Prior to my invention of the OSDCU gadget, it was not possible to connect a Covad SDSL line to a real router like Cisco (or Juniper or a BSD/Linux box or whatever), only to some very inferior router brands supplied as the standard CPE. And as far as my gadget goes, I've built the hardware, but I haven't finished the firmware part yet, so it's still technically vaporware. * ATM is much less bit-efficient than HDLC, so a Covad SDSL circuit sold as 1.5 Mbps actually has a little less real data carrying capacity than a T1. * I don't know off the top of my head what the monthly price is for Covad SDSL at 1.5 Mbps, and there probably is some variability between different ISPs who go through Covad, but I assume that even with a good deal it would still be a bit more than what I pay to VZB for 384 kbps. T1 prices have been coming down OTOH, at least for those who aren't tied to VZB. But I still expect T1 to be at least a little more expensive than SDSL @ 1.5 Mbps. I don't know how big this price delta is right now though - would anyone here have a better idea? The magnitude of this price delta ought to have a critical impact on whether or not it is worth putting up with all the quirks of SDSL listed above. For my peculiar situation (willing to live with 384 kbps and tied to VZB) the price delta (3x increase in the monthly payment) is most definitely worth the one-time expense of finishing my OSDCU gadget, but I don't know how the cards would fall for someone who is looking for full 1.5 Mbps (or more with bonding) and who has a choice of ISPs. And T3/DS3 can run over what, 4 copper pairs? Yet how much is the typical tariffed rate for that? DS3 over 4 copper pairs? ~11 Mbps symmetric on each pair? That seems like squeezing a lot out of a copper pair to me. Over what distance? William Herrin b...@herrin.us wrote: The major difference between using HDSL smart jacks and classic smart jacks is that the HDSL ones don't need wire that's in quite as good shape and they don't need repeaters between you and the CO as often. They're still very much a T1 service. Yup. Even though at the transceiver chipset level HDSL and SDSL are very much alike, the powers that be configure them very very differently at the higher layers. HDSL units are configured to pass the entire T1 frame structure (SF/ESF) unaltered, and within that T1 frame structure you get the good old familiar HDLC. Covad SDSL uses the same 2B1Q line code as HDSL and even the same transceiver chip (Bt8970 or RS8973), but stuffs the bit stream with ATM cells in a wacky non-standard frame structure instead of HDLC or T1 frames. One can either pay a monthly premium for a more standards-based bit stream format, or pay less per month for the hoary
Re: SDSL vs T1 (was Locations with no good Internet)
Roy r.engehau...@gmail.com wrote: You missed an option. Just change to another ISP. I know of at least one AS701 address block still attached to a company that hasn't been their customer for ten years or so. How is that possible? AFAIK no local politician has passed an IP address portability law yet. If my circuit from VZB were disconnected, wouldn't they release the address block for reuse by other customers just like any other ISP? I'm kinda guessing that you're suggesting that VZB's business practices are lax and that I may slip through the cracks? But there is no guarantee of any kind, is there? If they were to release/reuse my address block like they would have every right to, what recourse could I possibly have as a voluntarily disconnected customer? And even if the block remained unused / not reassigned after I left VZB, how could I possibly get it routed to me while connected through another ISP? I just don't get it - I don't see how this could be done without some local politician passing an IP address portability law like has been discussed recently. MS
Re: Locations with no good Internet (was ISP in Johannesburg)
Charles N Wyble char...@knownelement.com wrote: The biggest problem is middle mile. That is where the money needs to go. You need something to back haul to the interwebz. There is a lot of fiber in the ground already, Another possible way to solve the middle mile issue would again be to use the copper plant that's already in the ground. Unlike fiber, the copper plant is *ubiquitous*: I don't know of any place in the 1st or 2nd worlds that doesn't have copper pairs going to it. Also AFAIK T1s are available everywhere too: if you order a T1, they'll deliver it to you regardless of how deep you are in the middle of nowhere, although I suppose there likely are extra surcharges involved. Granted, a T1 at 1.5 Mbps may not be much for backhaul, but what about bonded T1s? Bond 4 of them to get 6 Mbps symmetric - not too bad in my book for a rural community. And again using SDSL instead of T1 offers a cost reduction opportunity. One could get that 6 Mbps symmetric for much cheaper by bonding 4 SDSL circuits running at 1.5 Mbps each instead of T1s. There is a Covad DSLAM with SDSL capability in virtually every CO in the country, but they serve out a whacky flavor of SDSL/2B1Q. I have good reason to suspect that I may be the last person alive on Earth who knows how to make CPE for this flavor *and* who cares about such things. but there are numerous layer 8 issues with getting to it most of the time. Solving those is an exercise left for the reader. Layer 8? Assuming that layers 8, 9 and 10 are management, financial and political, respectively, the issues that keep me from being able to build that Covad-compatible bonded NxSDSL CPE device lie at Layer 9. Anyone interested in helping me solve those issues? MS
Locations with no good Internet (was ISP in Johannesburg)
Daniel Senie d...@senie.com wrote: Better than western Massachusetts, where there's just no connectivity at = all. Even dialup fails to function over crappy lines. Hmm. Although I've never been to Western MA and hence have no idea what the telecom situation is like over there, I'm certainly aware of quite a few places in first world USA where DSL is still a fantasy, let alone fiber. As a local example, I have a friend in a rural area of Southern California who can't get any kind of high-speed Internet. I've run a prequal on her address and it tells me she is 31 kft from the CO. The CO in question has a Covad DSLAM in it, but at 31 kft those rural residents' options are limited to either IDSL at 144 kbps (not much point in that) or a T1 starting at ~$700/month. The latter figure is typically well out of range for the kind of people who live in such places. That got me thinking: ISDN/IDSL and T1 can be extended infinitely far into the boondocks because those signal formats support repeaters. What I'm wondering is how can we do the same thing with SDSL - and I mean politically rather than technically. The technical part is easy: some COs already have CLECs in them that serve G.shdsl (I've been told that NEN does that) and for G.shdsl repeaters are part of the standard (searching around shows a few vendors making them); in the case of SDSL/2B1Q (Covad and DSL.net) there is no official support for repeaters and hence no major vendors making such, but I can build such a repeater unofficially. The difficulty is with the political part, and that's where I'm seeking the wisdom of this list. How would one go about sticking a mid-span repeater into an ILEC-owned 31 kft rural loop? From what I understand (someone please correct me if I'm wrong!), when a CLEC orders a loop from an ILEC, if it's for a T1 or IDSL, the CLEC actually orders a T1 or ISDN BRI transport from the ILEC rather than a dry pair, and any mid-span repeaters or HDSLx converters or the like become the responsibility of the ILEC rather than the CLEC, right? So how could one extend this model to provide, say, repeatered G.shdsl service to far-outlying rural subscribers? Is there some political process (PUC/FCC/etc) by which an ILEC could be forced to allow a third party to stick a repeater in the middle of their loop? Or would it have to work by way of the ILEC providing a G.shdsl transport service to CLECs, with the ILEC being responsible for the selection, procurement and deployment of repeater hardware? And what if the ILEC is not interested in providing such a service - any PUC/FCC/etc political process via which they could be forced to cooperate? Things get even more complicated in those locations where the CO has a Covad DSLAM in it serving out SDSL/2B1Q, but no other CLEC serving G.shdsl. Even if the ILEC were to provide a G.shdsl transport service with repeaters, it wouldn't help with SDSL/2B1Q. My idea involves building a gadget in the form factor of a standard mid-span repeater that would function as a converter from SDSL/2B1Q to G.shdsl: if the loop calls for one mid-span repeater, stick this gadget in as if it were that repeater; if the loop calls for 2 or more repeaters, use my gadget as the first repeater and then standard G.shdsl repeaters after it. But of course this idea is totally dependent on the ability of a third party to stick these devices in the middle of long rural loops, perhaps in the place of loading coils which are likely present on such loops. Any ideas? MS
Re: Locations with no good Internet (was ISP in Johannesburg)
Brandon Galbraith brandon.galbra...@gmail.com wrote: Get dry loops from the ILEC and place repeaters at strategic points? I guess I need a little more education on how the process of ordering dry pairs from an ILEC works. I thought it works like this: 1. You have to be colocated in the CO to begin with. 2. You give the ILEC the address of an end site and they run a dry pair from your cage within their CO to that address. 3. You don't get access to any intermediate points. As far as placing the repeaters at strategic points, yeah, that's exactly what I meant, but my point was that these strategic points are owned by the ILEC, and I was/am wondering how to go about making it possible for a third party to stick repeater equipment in there. I envision the following picture: * There is a CO in a town, and there is a Covad DSLAM in that CO, serving those folks who are located in the town itself. * There is a winding mountain road going out of town into the countryside, and there are phone wires running alongside that road, several miles long. * There gotta be a bunch of cyan-colored cross-connect boxes on the side of the road, manholes and other places where the ILEC has mid-span access to those lng loops. They also very likely have loading coils on loops like that, and although I confess that I've never seen one of those coils with my own eyes, I've heard that they are rather bulky in terms of physical dimensions, probably bigger than a repeater PCB. The problem is that these mid-span access points are property of the ILEC along with the rest of the loop plant, and although there probably exists an ILEC-internal procedure for installing mid-span repeaters for T1s and maybe ISDN BRI, that is most certainly done by the ILEC itself, not by any third parties. Making it possible for a third party to access those intermediate points to install repeater equipment which the ILEC won't understand (handling Covad's non-standard flavor of SDSL/2B1Q) is the problem I'm trying to solve. MS
Re: Locations with no good Internet (was ISP in Johannesburg)
Brandon Galbraith brandon.galbra...@gmail.com wrote: http://www.rric.net/ I'm very familiar with those folks of course, they've been an inspiration to me for a long time. However, my needs are different. RRIC's model basically involves a specific community with a well-defined boundary: bring the bandwidth into the community via a bulk feed, then sublet inside the community. But I don't have a specific community in mind - I'm trying to develop a more generic solution. (The case of my friend who is at 31 kft from a Covad-enabled CO is only an example and nothing more.) Again, consider a town with a Covad-enabled CO plus an outlying countryside. The people in the town proper already have Covad xDSL available to them, and if we could stick my SDSL/2B1Q repeater in the middle of some longer loops, it would enable the people in the countryside to get *exactly the same* Covad (or ISP-X-via-Covad) services as those in the town proper. My repeater approach would also allow me to stay out of ISP or ISP-like business which I really don't want to get into - I would rather just make hardware and let someone else operate it. A repeater is totally unlike a router, it is not IP-aware, it just makes the loop seem shorter, allowing farther-outlying users to connect to *existing* ISPs with an already established business structure. Anyway, I just saw a post on NANOG about an area deprived of high-speed Internet services and thought I would post my idea in the hope that someone would have some ideas that would actually be *helpful* to what I'm trying to do. If not - oh well, I'll just put the idea back on the dusty shelf in the back of my mind until I'm ready to try presenting it to the folks who own the CO-colocated DSLAMs it would have to work with - gotta finish a few other things before I open that can of worms in the earnest. MS
Re: Using /31 for router links
Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: What about NAT, ATM cell tax, unnecessary addressing fields in PTP protocols (including your beloved HDLC), SSAP, DSAP fields not being big enough in 802.2 necessitating SNAP, IPX directly over 802.3, AAL1 through AAL4, PPPoE dumbell MTUs and MSS hacks? Some of those are far worse sins in my opinion. Hmm. PPPoE: this kludge is a direct fallout of abusing Ethernet for WAN/PTP. If all those xDSL users were willing to stick V.35 cards in their PCs and use modems that put out V.35 instead of Ethernet, the whole PPPoE kludge with all of its attendant MTU issues would have been completely unnecessary. Want PPP for authentication etc? Just run straight PPP (RFC 1662) over V.35 instead of Ethernet/PPPoE, HDLC has no fixed MTU unlike Ethernet (jogging my memory, all HDLC controllers which I recall working with allowed maximum frame size up to just a little under 2^16 octets or so), and one can thus have the standard MTU of 1500 octets on that PPP link! Oh, and yet another soapbox of mine, an xDSL modem that puts out V.35 instead of goddamn Ethernet would be a true modem: a modulator/demodulator that modulates/demodulates the bits at the electrical level without caring about what's in those bits. What everyone else in this fubared world calls an xDSL modem (a black box that puts Ethernet out) is not a modem at all (i.e., total misappropriation of the term), it is actually a bastardized router! These boxes forward packets between two network interfaces: the presented Ethernet interface and the internal (often horrendously non-standard and proprietary) HDLC or ATM interface on the actual line. A device that forwards packets between two different network interfaces is by definition a router, hence what everyone calls a modem is actually a bastardized router - bastardized because its routing (packet forwarding) function is something incomprehensible. The Ethernet-to-Ethernet NAT boxes that everyone else calls routers should be called NATters or something like that, anything but a router! A true router is a box with a few AUIs and a few V.35 ports sticking out of it, running some very capable, flexible and totally user-configurable packet forwarding software stack that supports all networking models: IP routing, MAC bridging, VC cross-connect. As for ATM... The part that totally baffles me about the use of ATM on xDSL lines is that I have never, ever, ever seen an xDSL line carrying more than one ATM VC. OK, there may be someone out there who has set up a configuration like that just for fun, but 99.999% of all ATM'd xDSL lines out there carry a single PVC at 0*35 or 0*38. So what then is the point of running ATM?!?! All the hyped benefits of ATM (a little cell can squeeze in the middle of a big packet without waiting for it to finish, yadda yadda yadda) are contingent upon having more than one VPI/VCI going across the interface! If every single non-idle cell going across that ATM interface is 0*35 or 0*38, the interface will never carry anything other a direct succession of cells making up an AAL5 packet, strictly in sequence and without interruption. So what's the point of ATM then? Why chop that packet up into cells only to transmit those cells in direct sequence one after another? Why not simply send that same packet in plain HDLC over the same copper pairs/fiber? OK, the backhaul network upstream of the DSLAM may be ATM and that one does have many VCs, so ATM *might* be of use there, but even in that case why not do FRF.8 in the DSLAM and keep the ATM strictly on the backhaul, sending HDLC down the copper pairs? off the soapbox for the moment MS
Re: Using /31 for router links
Stephen Sprunk step...@sprunk.org wrote: Ah, but who's to say that all PTP links are WANs? Are you really going to run an OC-48 from one router to another _in the same building_ when you need 1Gb/s between them? Can't say - I have never needed that much bandwidth. :) I still live in an alternate Universe where 10 Mbps coaxial Ethernet for LANs is near- infinity and 2 Mbps or so makes for a *very* sweet WAN. The facility housing the mail server from which I am sending this message is connected to the outside Inet via a 384 kbps SDSL pipe which I am using basically as ARPANET replacement - I miss the ARPANET. If I wanted a PTP link between two routers in the same building that runs at the same speed as my Ethernet (10 Mbps), I would use EIA-422 (which is rated up to 10 Mbps) and run something HDLC-based over it. Even for MANs or WANs, the price of a pipe (plus equipment at each end) will still often be significantly lower for Ethernet than for real circuits Wait a moment here. With a MAN/WAN involving wires/fiber running over public property, what one is paying for is the right to use those wires for your data, right? The wires themselves do NOT run Ethernet at the electrical level, so if you have some MAN/WAN Ethernet service, there is a black box of some kind that converts the native electrical signal format to Ethernet. Why not take that black box out of service, use it for baseball practice (Office Space style), and use the exact same wires/fiber (rented at exactly the same monthly recurring price) in its native non-Ethernet form? IOW, if you are renting dry copper / dark fiber, you have a choice to use it either through a stinky black box Ethernet converter or in the native non-Ethernet form directly, but the monthly recurring cost remains exactly the same. Well, it'd certainly be nice if someone would make something even cheaper than Ethernet for that purpose (which would squeeze out a few more bits of payload), but so far nobody has. It's hard to beat Ethernet on volume, and that's the main determinant of cost/price... But that's non-recurring equipment cost only, and at least in my case the little investment in V.35 etc hardware is a much lower cost than the price of pain and suffering with Ethernet for a purist like me. MS
Re: Using /31 for router links
Brielle Bruns br...@2mbit.com wrote: Back in the days of Rhythms and Copper Mountain gear, Netopia had the D series routers which were actually xDSL to DSU units. Yes, I am very familiar with them: http://ifctfvax.Harhan.ORG/OpenSDSL/existing_cpe/netopia/dsu.html As that page explains, they are only pseudo-DSUs though. I much much prefer a true bit-transparent DSU: http://ifctfvax.Harhan.ORG/OpenSDSL/existing_cpe/xsb2000.html I have also designed and built an SDSL to EIA-530 DSU of my very own: http://ifctfvax.Harhan.ORG/OpenSDSL/OSDCU/ On the latter I have the hardware (the page above has a photo of the board), but the operational software (or firmware if you will) remains to be finished. Though, I'm not sure they'd work these days, Only in the very limited geographic footpring of what used to be DSL.net - they are the last remaining semi-major operator of CM DSLAMs: http://ifctfvax.Harhan.ORG/OpenSDSL/megapath.html My big goal is to make my own DSU which I have just mentioned function as a Layer 2 converter (FRF.8 and friends) from Nokia SDSL/ATM served by Covad to HDLC. nor do I think they came in ADSL models either. I don't think anyone have *ever* used V.35 friends with ADSL - probably because those who would want V.35 (i.e., people like me) would find ADSL morally offensive. :-) MS
Re: Using /31 for router links
Nathan Ward na...@daork.net wrote: ARP is still required on ethernet links, so that the MAC address can be = discovered for use in the ethernet frame header. /31 does not change the = behavior of ARP at all. soapbox That is why I hate Ethernet with a passion. Ethernet should be for LANs only; using Ethernet for WANs and PTP links is the vilest invention in the entire history of data networking in my opinion. My medium of choice for PTP links (WAN) is HDLC over a synchronous serial bit stream, with a V.35 or EIA-530 interface between the router and the modem/DSU. Over HDLC I then run either RFC 1490 routed mode or straight PPP (RFC 1662); in the past I used Cisco HDLC (0F 00 08 00 IP header follows...). My 4.3BSD router (or I should better say gateway as that's the proper 80s/90s term) then sees a PTP interface which has no netmask at all, hence the near and far end IP addresses don't have to have any numerical relationship between them at all. No netmask, no MAC addresses, no ARP, none of that crap, just a PTP IP link. /soapbox MS
RE: Bonded SDSL (was RE: ITU G.992.5 Annex M - ADSL2+M Questions)
Frank Bulk - iName.com frnk...@iname.com wrote: It's being done by Actelis, Hatteras, and Zhone. More exactly SHDSL or ^ similar variants. The market is being well-served. ^ The highlighted sentence is precisely the difference between what they are doing and what I am doing. The SHDSL folks seem to live in some kind of fantasy world where they think that all major network operators are going to throw out all their SDSL/2B1Q infrastructure and install SHDSL DSLAMs across the country instead. My SDSL work on the other hand is oriented toward working with the existing SDSL/2B1Q infrastructure massily deployed across USA by networks like Covad and what used to be DSL.net (now part of MegaPath). My Open SDSL Connectivity Project has successfully reverse-engineered the proprietary SDSL/2B1Q flavors used by the DSLAM brands deployed by the two networks named above, and I want to build bonded SDSL CPE for those flavors/networks. And yes, I have already had discussions with some people at both of the named companies. It wasn't even necessary for me to initiate contact with them as both of them have sought my open source project out and contacted me on their own about this very idea of SDSL bonding. However, despite lots of excited talk, both dialogues have ended with a mutter. Apparently there is some kind of wall of arrogance that prevents those folks from even considering getting their CPE from a mosquito like me, even though I can deliver it for one-tenth to one-hundredth of what the big vendors would want for the same thing if they would even consider building such - those big vendors have plenty of their own arrogance! Therefore, my next angle of approach is to see if there are any ISPs who go through Covad or through MegaPath's ex-DSL.net component as their Layer 2 transport (I know that at least in Covad's case there is a huge number of ISPs large and small who do that) and who want bonded SDSL badly enough to punch through that wall of arrogance. If you are an ISP who rents Layer 2 transport from Covad and I were to supply you the CPE, I think you should be able to serve bonded SDSL to your customers without having to beg Covad to descend from the heavens and give that service its blessing. Just order 2 (or 3 or 4 or however many loops you want to bond) ATM transport pipes from Covad terminating at your customer's address on one end and at your DS3/ATM interconnection point on the other end. Have your Cisco/Redback/whatever router run PPPoA on each of those ATM pipes and do MLPPP bonding between them. All that would be needed then is the CPE, and that's what the Open SDSL Connectivity Project is for... MS
Bonded SDSL (was RE: ITU G.992.5 Annex M - ADSL2+M Questions)
Frank Bulk - iName.com frnk...@iname.com wrote: We offer it, but practically speaking we haven't gotten much higher than 1.5 Mbps on the upstream. Sorry that I'm coming into this thread late (I have just subscribed), but since I see people discussing DSL with beefy upstream, I thought I would be brave and ask: do you esteemed high-end network op folks think that there may be anyone in the world who might be interested in bonded SDSL or not? I have spent the past 5 years of my life learning everything there is to know about SDSL. Don't ask me why, I don't really know the answer to that question myself. I won't waste the bandwidth of this elite list with dirty details of just what I've done with SDSL over the past 5 y, but I'll give a link to an open source project that contains the body of SDSL knowledge amassed over those years: http://ifctfvax.Harhan.ORG/OpenSDSL/ To make the long story short, for most of those years I kept trudging on my project, treating it as an ultra-weird hobby that no one else in the world could possibly have any interest in. That persisted until 2009 when my project got noticed by two fairly major North American DSL network operators. (Well, one very major and one semi-major, but I'll spare the names.) Both of those had contacted me via my Open SDSL Connectivity Project expressing interest in SDSL bonding. Both companies were telling me how much interest they had in SDSL bonding, how much it would help their business to be able to offer bonded SDSL services at 3 or 6 Mbps, how many customers they would be able to sign up for these services, etc. But when I asked them to back their verbally-expressed interest with the tiniest amount of money or even no money at all but a letter of intent which I could show to SBA etc, they both went silent. We've been playing a game of cat-and-mouse ever since. As far as I could understand the existing situation is that the SDSL infrastructure already deployed en masse by the major North American DSL network operators already has the capability to serve out bonded SDSL circuits, bonding either in the DSLAM or somewhere upstream of it, using MLPPP, Multilink Frame Relay or whatever else one can think of, but the problem is with CPE. Apparently bonding-capable multiport SDSL CPE devices are quite scarce. Considering everything I've done with SDSL over the past 5 y, I believe I have a right to say with confidence that I am more than capable of designing and building a bonding-capable multiport SDSL CPE device for any existing SDSL flavor with any desired number of ports (2, 4 or whatever). But what I don't know, and what I'm asking this highly esteemed list for advice with, is this question: is there anyone at all in the world who might have a real serious interest in such a thing? If there is someone in the world who would truly appreciate having a bonded SDSL solution, I would be delighted to work on developing such a thing. I would see it as a service to humanity whereby more use would be made out of existing copper infrastructure in the ground instead of having to dig more ditches to bury more fiber or whatever. But if there is no one in the world who would be interested in bonded SDSL (or at least interested enough to invest one dime into development), then why bother... MS
