From brandon at rd.bbc.co.uk Fri Feb 1 00:36:43 2013 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Fri, 1 Feb 2013 00:36:43 GMT Subject: Muni fiber: L1 or L2? Message-ID: <201302010036.AAA08295@sunf10.rd.bbc.co.uk> > I'm saying you put the splitter next to the OLT and then > run multiple fibers from there to the subscribers IN THE MMR That's the way I'd expect it to be done if planning ahead, GPON is today technology and new things always come I can see why they don't do this though 1. reduced build cost today - smaller MMR, fewer fibres to the roadside. 2. gpon makes it harder for competing unbundlers to get share in your investment 3. no home run fibres means no competitors running their own GPON or Ethernet. Why invest in making it easier for the competition brandon From rps at maine.edu Fri Feb 1 01:08:07 2013 From: rps at maine.edu (Ray Soucy) Date: Thu, 31 Jan 2013 20:08:07 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> Message-ID: > 1. Must sell dark fiber to any purchaser. > 2. Must sell dark fiber to all purchasers on equal terms. > (There must be a published price list and there cannot be deviations > from that price list. If the price list is modified, existing customers > receive the new pricing at the beginning of their next billing cycle.) > 3. May provide value-added L2 services > 4. If L2 services are provided, they are also subject to rule 2. > 5. May not sell L3 or higher level services. > 6. May not hold ownership or build any form of alliance or affiliation with > a provider of L3 or higher level services. I think rule #3 is the kind of thing that sounds like a good idea, but ends up being abused in practice. My personal view is that you really want that separation in place. You don't want a situation where the dark fiber provider gives priority to their L2 outages and get's around to their competitors later. Businesses are in the business of profit. Nothing wrong with that, but if you want it to be a fair playing field you need to avoid this kind of conflict of interest. We've seen the same behavior with ILECs and small ISPs. They were required to open up their network to competing ISPs, but did everything they could to make it as difficult as possible. You really want to create a situation where that temptation isn't even there. We've also seen that when left up to the private sector even last-mile solutions suffer from the same cherry-picking of "profitable" locations to service: example would be an apartment complex having fiber delivered vs. a house next door not having fiber delivered. You can't really blame the private sector for it, but if you want the idea of FTTH to be a universal service, you really need to apply the public utility model to it. P.S.Fletcher Kittredge is the "private" side of the public-private partnership that made Maine Fiber Company possible and deserves at least 50% of the credit if not more (Google him). Great to see him on-list. P.P.S. I should also note that my boss, Jeff, would be the "public" side of that, and he isn't quite on board with my position on extending FTTH as a public utility. He still has faith in the private sector to take care of it. ;-) I mostly stand on the sidelines and provide commentary, I'm not suited for the level of political involvement it actually takes to make the magic happen. -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net From owen at delong.com Fri Feb 1 02:06:40 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 31 Jan 2013 18:06:40 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: <201302010036.AAA08295@sunf10.rd.bbc.co.uk> References: <201302010036.AAA08295@sunf10.rd.bbc.co.uk> Message-ID: <7A022BFE-A3D3-4E72-991A-F4791D8D9A1B@delong.com> On Jan 31, 2013, at 4:36 PM, Brandon Butterworth wrote: >> I'm saying you put the splitter next to the OLT and then >> run multiple fibers from there to the subscribers IN THE MMR > > That's the way I'd expect it to be done if planning ahead, > GPON is today technology and new things always come > > I can see why they don't do this though > > 1. reduced build cost today - smaller MMR, fewer fibres to the > roadside. Tradeoff: It only works for one provider and a competitive provider has to put in their own full build of fiber. > > 2. gpon makes it harder for competing unbundlers to get share > in your investment > Which is why this whole discussion is about ways to implement an MMR and take the L1 out of the service provider picture and make it an independent municipal service. > 3. no home run fibres means no competitors running their own > GPON or Ethernet. Why invest in making it easier for the > competition > The point here is to eliminate that problem. Thank you for making my point. Owen From owen at delong.com Fri Feb 1 02:10:20 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 31 Jan 2013 18:10:20 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> Message-ID: On Jan 31, 2013, at 5:08 PM, Ray Soucy wrote: >> 1. Must sell dark fiber to any purchaser. >> 2. Must sell dark fiber to all purchasers on equal terms. >> (There must be a published price list and there cannot be deviations >> from that price list. If the price list is modified, existing customers >> receive the new pricing at the beginning of their next billing cycle.) >> 3. May provide value-added L2 services >> 4. If L2 services are provided, they are also subject to rule 2. >> 5. May not sell L3 or higher level services. >> 6. May not hold ownership or build any form of alliance or affiliation with >> a provider of L3 or higher level services. > > I think rule #3 is the kind of thing that sounds like a good idea, but > ends up being abused in practice. > Certainly without rule 4, yes. However, with rules 4,5,6, I think that overcomes most of the issues that result from rule 3. If you don't have rule 3, there are a lot of areas where it simply won't be cost effective for ANYONE to come to the MMR and thus you don't get any benefit. > My personal view is that you really want that separation in place. > You don't want a situation where the dark fiber provider gives > priority to their L2 outages and get's around to their competitors > later. > Ideally, I agree with you, but to cover all cases, you also have to make sure that you have some set of L2 providers before you can do that. Further, I'm suggesting that the natural place for this in most cases is to be operated by the muni not a business. > Businesses are in the business of profit. Nothing wrong with that, > but if you want it to be a fair playing field you need to avoid this > kind of conflict of interest. Agreed. > We've seen the same behavior with ILECs and small ISPs. They were > required to open up their network to competing ISPs, but did > everything they could to make it as difficult as possible. You really > want to create a situation where that temptation isn't even there. Except this kind of chicanery has always involved L3+ services in the past. > We've also seen that when left up to the private sector even last-mile > solutions suffer from the same cherry-picking of "profitable" > locations to service: example would be an apartment complex having > fiber delivered vs. a house next door not having fiber delivered. You > can't really blame the private sector for it, but if you want the idea > of FTTH to be a universal service, you really need to apply the public > utility model to it. Yep. Owen From dan at beanfield.com Fri Feb 1 02:28:13 2013 From: dan at beanfield.com (Dan Armstrong) Date: Thu, 31 Jan 2013 21:28:13 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> Message-ID: <16BB3633-7F3D-453D-B944-96BCF4C72E65@beanfield.com> Sorry for jumping into this discussion so late?. and I apologize if this has already been talked about (this has been a long thread) But the most successful municipal undertaking to support telecom I have ever seen is a municipally owned conduit system?. Any infrastructure L1, L2, or anything is too complex to be commercially viable if owned by one entity. Putting everybody on a level playing field removes the value from everybody, and therefore removes the commercial interest to DO anything, so nothing happens. Unless somebody is able to build a product that everybody can't just have without any obstacles, nobody is going to do anything, and we end up with nothing. A city owned conduit system is the best balance between fairness for the consumer, and supporting a competitive environment for service providers to offer something John Q public can't get on his own. On 2013-01-31, at 9:10 PM, Owen DeLong wrote: > > On Jan 31, 2013, at 5:08 PM, Ray Soucy wrote: > >>> 1. Must sell dark fiber to any purchaser. >>> 2. Must sell dark fiber to all purchasers on equal terms. >>> (There must be a published price list and there cannot be deviations >>> from that price list. If the price list is modified, existing customers >>> receive the new pricing at the beginning of their next billing cycle.) >>> 3. May provide value-added L2 services >>> 4. If L2 services are provided, they are also subject to rule 2. >>> 5. May not sell L3 or higher level services. >>> 6. May not hold ownership or build any form of alliance or affiliation with >>> a provider of L3 or higher level services. >> >> I think rule #3 is the kind of thing that sounds like a good idea, but >> ends up being abused in practice. >> > > Certainly without rule 4, yes. However, with rules 4,5,6, I think that > overcomes most of the issues that result from rule 3. > > If you don't have rule 3, there are a lot of areas where it simply won't > be cost effective for ANYONE to come to the MMR and thus you don't get > any benefit. > >> My personal view is that you really want that separation in place. >> You don't want a situation where the dark fiber provider gives >> priority to their L2 outages and get's around to their competitors >> later. >> > > Ideally, I agree with you, but to cover all cases, you also have to make > sure that you have some set of L2 providers before you can do that. > > Further, I'm suggesting that the natural place for this in most cases > is to be operated by the muni not a business. > >> Businesses are in the business of profit. Nothing wrong with that, >> but if you want it to be a fair playing field you need to avoid this >> kind of conflict of interest. > > Agreed. > >> We've seen the same behavior with ILECs and small ISPs. They were >> required to open up their network to competing ISPs, but did >> everything they could to make it as difficult as possible. You really >> want to create a situation where that temptation isn't even there. > > Except this kind of chicanery has always involved L3+ services in the past. > >> We've also seen that when left up to the private sector even last-mile >> solutions suffer from the same cherry-picking of "profitable" >> locations to service: example would be an apartment complex having >> fiber delivered vs. a house next door not having fiber delivered. You >> can't really blame the private sector for it, but if you want the idea >> of FTTH to be a universal service, you really need to apply the public >> utility model to it. > > Yep. > > Owen > > From apishdadi at gmail.com Fri Feb 1 03:08:56 2013 From: apishdadi at gmail.com (Ameen Pishdadi) Date: Thu, 31 Jan 2013 21:08:56 -0600 Subject: Ddos mitigation service In-Reply-To: References: Message-ID: <8FA1E710-E860-460F-AE8C-1216E61CDA6D@gmail.com> Hi Matt , Are you still looking for ddos protection? Thanks, Ameen Pishdadi On Jan 31, 2013, at 12:13 PM, matt kelly wrote: > Can anyone recommended ddos mitigation companies with US east coast > presence that provide the services via bgp? We are not interested in an > appliance but rather offloading the traffic. > > Thanks. From brunner at nic-naa.net Fri Feb 1 03:18:17 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 31 Jan 2013 19:18:17 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: <16BB3633-7F3D-453D-B944-96BCF4C72E65@beanfield.com> References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <16BB3633-7F3D-453D-B944-96BCF4C72E65@beanfield.com> Message-ID: <510B33F9.2050401@nic-naa.net> On 1/31/13 6:28 PM, Dan Armstrong wrote: > But the most successful municipal undertaking to support telecom I have ever seen is a municipally owned conduit system?. Could you be a bit more specific? What is the muni, and where can the business model data be found? Also, what was the muni's ROW compensation prior to doing the right-of-way buildout, and after? Eric From khelms at zcorum.com Fri Feb 1 03:21:23 2013 From: khelms at zcorum.com (Scott Helms) Date: Thu, 31 Jan 2013 22:21:23 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> Message-ID: Fletcher nailed it, if you want the architecture you're describing then you simply don't want PON. Its built around lower cost and a big part of that lower cost is minimizing the fiber costs by serving splitters (and thus many homes) from a single fiber that back hauls to the CO. The other reason PON won't work for what you want is the splitters are passive and completely static in their operation. Here's an image of one that may make this clearer: http://media.wholesale-electrical-electronics.com/product/imgage/Electrical&Electronics/2010101220/6dc7c82d59d9fd931bfba560a3e85031.jpg If you have to either run several (or more) fibers to a neighborhood or have managed neighborhood elements then you've simply destroyed the use case for PON. Luckily this use case matches pretty exactly for Ethernet, but you must do your wholesale play at layer 2 IMO to work economically. On Thu, Jan 31, 2013 at 6:28 PM, Owen DeLong wrote: > > On Jan 31, 2013, at 13:57 , Fletcher Kittredge wrote: > > > > > On Thu, Jan 31, 2013 at 4:36 PM, Owen DeLong wrote: > >> If you have an MMR where all of the customers come together, then you >> can cross-connect all of $PROVIDER_1's customers to a splitter provided >> by $PROVIDER_1 and cross connect all of $PROVIDER_2's customers to >> a splitter provided by $PROVIDER_2, etc. >> >> If the splitter is out in the neighborhood, then $PROVIDER_1 and >> $PROVIDER_2 >> and... all need to build out to every neighborhood. >> >> If you have the splitter next to the PON gear instead of next to the >> subscribers, >> then you remove the relevance of the inability to connect a splitter to >> multiple >> OLTs. The splitter becomes the provider interface to the open fiber plant > > > Owen; > > Interesting. Do you then lose the cost advantage because you need home > run fiber back to the MMR? Do you have examples of plants built with this > architecture (I know of one such plant, but I am hoping you will turn up > more examples.) > > > I don't know of any. Yes, it would eliminate part of the theoretical cost > savings of the PON architecture, but the point is that it would provide a > technology agnostic last mile infrastructure that could easily be used by > multiple competing providers and would not prevent a provider from using > PON if they chose to do so for other reasons. > > Owen > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From dan at beanfield.com Fri Feb 1 03:43:25 2013 From: dan at beanfield.com (Dan Armstrong) Date: Thu, 31 Jan 2013 22:43:25 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <510B33F9.2050401@nic-naa.net> References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <16BB3633-7F3D-453D-B944-96BCF4C72E65@beanfield.com> <510B33F9.2050401@nic-naa.net> Message-ID: <4219F0BA-538D-4A11-A9AD-7A98AFA4EC14@beanfield.com> I don't have specific data to point you to. I am speaking from my experience, in large cities. Totally different story in rural or suburban areas. In general, if a municipality builds an L1 or L2 network it removes so many barriers of competition that many idiots get into the business. The consumer ends up suffering, because the market is overwhelmed with inferior products. The few that do things 'right' get lost in the sea of bottom feeders looking for a quick buck. Unlike a hamburger, or a t-shirt - telecom is a complex product that most consumers are unable to appreciate the details of. They aren't going to educate themselves on the nuances of quality, so the people offering a better product have no way of getting ahead in this near-perfect competitive situation. A city government benefits from economic prosperity, which comes from businesses within it's boundaries being prosperous. Access to great telecom services is one factor in that prosperity. That is the business model for a municipality to want good telecom. A municipality can lease out conduits, for a small fee - there is still a reasonable barrier to entry. People have to pull cable, splice it, manage it, light it, sell it, and do all the stuff a telco has to do before they receive revenue. This filters out (most) of the opportunists? but makes it easy enough for entrepreneurs with a great idea to get started without having to come up with billions of $ in capital to open-trench the streets in the entire city. In the case of a growing municipality, if they play their cards right they can pay for the entire conduit system from development fees collected from land or re-zoning deals, which furthers the virtuous circle of growth. On 2013-01-31, at 10:18 PM, Eric Brunner-Williams wrote: > On 1/31/13 6:28 PM, Dan Armstrong wrote: >> But the most successful municipal undertaking to support telecom I have ever seen is a municipally owned conduit system?. > > Could you be a bit more specific? What is the muni, and where can the > business model data be found? > > Also, what was the muni's ROW compensation prior to doing the > right-of-way buildout, and after? > > Eric > > From owen at delong.com Fri Feb 1 03:48:16 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 31 Jan 2013 19:48:16 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> Message-ID: <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> On Jan 31, 2013, at 19:21 , Scott Helms wrote: > Fletcher nailed it, if you want the architecture you're describing then you simply don't want PON. Its built around lower cost and a big part of that lower cost is minimizing the fiber costs by serving splitters (and thus many homes) from a single fiber that back hauls to the CO. The other reason PON won't work for what you want is the splitters are passive and completely static in their operation. Here's an image of one that may make this clearer: > > http://media.wholesale-electrical-electronics.com/product/imgage/Electrical&Electronics/2010101220/6dc7c82d59d9fd931bfba560a3e85031.jpg > I know what a splitter is and how they work. I understand PON really quite a bit better than you imagine I do. Bottom line, you've got OLT -> FIBER(of length n) -> splitter -> fiber-drops to each house -> ONT. All I'm proposing is making n really short and making "fiber-drops to each house" really long. I'm not proposing changing the fundamental architecture. Yes, I recognize this changes the economics and may well make PON less attractive than other alternatives. I don't care. That's not a primary concern. The question is "can PON be made to work in this environment?" It appears to me that it can. It will work as I've described, but, yes, it's very suboptimal from a cost perspective if your only goal is to deploy PON for a single provider. If, OTOH, your goal is to have a fiber infrastructure in the neighborhoods that can support a multitude of possible services of which PON from a number of providers is just one such possible service, then, the PON operators can, in fact, install in the MMR and do the splitting at the MMR end of the subscriber fiber with home-runs from the MMR to each home. True, PON is probably not the best technology fit for this. Ethernet probably makes more sense in most cases. However, if you have providers that do PON everywhere else and they don't want to support "exception equipment" for your facility, then it allows them to install PON just like their other deployments, only the splitter is next to the OLT instead of out near a collection of ONTs. > If you have to either run several (or more) fibers to a neighborhood or have managed neighborhood elements then you've simply destroyed the use case for PON. Luckily this use case matches pretty exactly for Ethernet, but you must do your wholesale play at layer 2 IMO to work economically. > I disagree. If you have home-run fiber to a large bank of patch panels in an MMR that can serve a ~8km radius of subscribers and providers can colocate whatever L2+ equipment they want to in said MMR with said fibers available for lease on equal footing to all providers, then the providers can deploy whatever makes the most sense to them whether that's SONET, Ethernet, PON, or optical tin cans over your fiber-string. Yes, this is more expensive for the fiber deployment than running FTTH from the local BBox and having splitters in the BBox, but if it's being done intelligently, especially in areas of greenfield deployment, then it doesn't have to be a lot more expensive. I get roughly 201 Sq. Km. as the area of an 8km radius circle (For the metrically challenged, that's roughly 77 Sq. Mi. or an area a little larger than Washington DC (68.3 sq. mi according to wikipedia). If you're willing to require more expensive optics, you could go to a larger area served to accommodate lower population densities and for higher density areas, it might make economic sense to make the service radius smaller and have more centers. I don't know what the economically ideal subscriber volume per center would be. That would have to be calculated. Owen > > On Thu, Jan 31, 2013 at 6:28 PM, Owen DeLong wrote: > > On Jan 31, 2013, at 13:57 , Fletcher Kittredge wrote: > >> >> >> >> On Thu, Jan 31, 2013 at 4:36 PM, Owen DeLong wrote: >> If you have an MMR where all of the customers come together, then you >> can cross-connect all of $PROVIDER_1's customers to a splitter provided >> by $PROVIDER_1 and cross connect all of $PROVIDER_2's customers to >> a splitter provided by $PROVIDER_2, etc. >> >> If the splitter is out in the neighborhood, then $PROVIDER_1 and $PROVIDER_2 >> and... all need to build out to every neighborhood. >> >> If you have the splitter next to the PON gear instead of next to the subscribers, >> then you remove the relevance of the inability to connect a splitter to multiple >> OLTs. The splitter becomes the provider interface to the open fiber plant >> >> Owen; >> >> Interesting. Do you then lose the cost advantage because you need home run fiber back to the MMR? Do you have examples of plants built with this architecture (I know of one such plant, but I am hoping you will turn up more examples.) >> > > I don't know of any. Yes, it would eliminate part of the theoretical cost savings of the PON architecture, but the point is that it would provide a technology agnostic last mile infrastructure that could easily be used by multiple competing providers and would not prevent a provider from using PON if they chose to do so for other reasons. > > Owen > > > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- From teun at teun.tv Fri Feb 1 12:56:42 2013 From: teun at teun.tv (Teun Vink) Date: Fri, 01 Feb 2013 13:56:42 +0100 Subject: AS30424 Message-ID: <1359723402.5716.39.camel@moridin> Hi all, While examining some routing table entries one of my coworkers stubled upon a number of prefixes which is are somewhat strange (or maybe even suspicious). The ASN originating these prefixes is AS30424, which is part of a block of ASN's assigned to ARIN. However, there's no entry in the ARIN database (or peeringdb, radb, etc) for AS30424. This ASN originates a number of IPv4 and IPv6 prefixes (64.186.208.0/20, 66.246.201.0/24, 66.246.202.0/24, 66.246.203.0/24, 66.246.204.0/24, 68.68.48.0/20, 98.143.176.0/20 and 2001:450:202a::/48). The IPv6 prefix (no entries in any routing database I checked) is part of 2001:450::/32, which is assigned to Level3 (AS3549), there's no route originating from AS3549 for the /32 or /48 though. The only transit for AS30424 (both IPv4 and IPv6) seems to be Cogent (AS174). The IPv4 prefixes all have entries in the ARIN database which indicate that they may be used from multiple ASNs: OriginAS: AS30424, AS36241, AS33065 The other two ASNs are registerd in the ARIN database to Megatechie. I'm mostly curious if I'm looking at an administrative error or if there's something really wrong with AS30424. Anyone have any insights? Best regards, Teun From nanog at hostleasing.net Fri Feb 1 13:05:51 2013 From: nanog at hostleasing.net (Randy Epstein) Date: Fri, 01 Feb 2013 08:05:51 -0500 Subject: AS30424 In-Reply-To: <1359723402.5716.39.camel@moridin> Message-ID: On 2/1/13 7:56 AM, "Teun Vink" wrote: >Hi all, > >While examining some routing table entries one of my coworkers stubled >upon a number of prefixes which is are somewhat strange (or maybe even >suspicious). The ASN originating these prefixes is AS30424, which is >part of a block of ASN's assigned to ARIN. However, there's no entry in >the ARIN database (or peeringdb, radb, etc) for AS30424. AS30424 was assigned to "Super Networks" of Columbia, MD on March 18, 2008. It's possible they didn't pay their ARIN invoice, and they also didn't renew their domain "supernetworks.net", as that has lapsed as well. Have you tried contacting Megatechie? Randy From dsparro at gmail.com Fri Feb 1 14:26:05 2013 From: dsparro at gmail.com (Dave Sparro) Date: Fri, 01 Feb 2013 09:26:05 -0500 Subject: Muni network ownership and the Fourth In-Reply-To: <20130130220300.40036.qmail@joyce.lan> References: <20130130220300.40036.qmail@joyce.lan> Message-ID: <510BD07D.3000107@gmail.com> On 1/30/2013 5:03 PM, John Levine wrote: > The muni power companies around here provide service every bit as good > as NYSEG, the private power company, at literally half the price. The muni providers have a bunch of cost advantages that help them keep the price lower. municipal utilities: - sell bonds cheaper (holders get tax-advantaged rates in interest income, and are ultimately backed by the muni taxpayers) - don't pay property tax on real-estate or sales tax on equipment used. - can force sale of property to collect unpaid bills - leverage municipal employees for customer support (can pay my water bill at the city clerk's office) From pierre at userid.org Fri Feb 1 14:57:44 2013 From: pierre at userid.org (Pierre Lamy) Date: Fri, 01 Feb 2013 09:57:44 -0500 Subject: Ddos mitigation service In-Reply-To: References: Message-ID: <510BD7E8.4010805@userid.org> The 3 major scrubbing vendors: Prolexic Verisign Akamai Prolexic has the ability to announce a /24 for you, and scrub the whole thing, then pipe it back to you via a GRE tunnel or dedicated circuit. All of the companies mentioned do this for a living, and are pretty good at what they do. There are other vendors as well that do FQDN scrubbing for you (which is the normal way to do it). You swing the DNS A record to point to their provisioned VIP, and they proxy back the traffic to you. This doesn't do anything to prevent attacks against IP addresses rather than resolved FQDNs. It's important to note that all mitigation techniques can have a negative impact and should be tested first. The scrubbing centers are only one solution and you should equip yourself with multiple layers of defense, separated by where they live: Beyond the carrier perimeter - Scrubbing farms in IP-routed mode - Scrubbing farms in DNS-routed mode - CDNs to deliver high value target pages, like main corporate pages and login windows - Globally Anycast DNS auth slaves through a CDN Beyond your perimeter (carriers) - Geoblocks - Zombie detection and rate limits - Flowspec routes via monitoring tools like Arbor's - Various other carrier-specific security offerings - Provision a secondary circuit to carry non-public IP space, for corporate web/out, phones, VPN etc. If the main pipe comes under attack, you can still carry out some critical business and B2B functions Within the perimeter - Load balancers - Firewalls - IPS - WAF - Reverse proxies - Blackhole routes - Flowspec routes (ie Arbor) - A span tap on the internet feed(s) connected to a tcpdump box (silly and cheap, but highly useful to generate sigs and collect intel) Not all DDoS are created equal, and there can always be some leakage by protections further out; the protections closer in allow for a faster and more granular response, but you're really limited to the circuit sizes, session limits etc. I would highly recommend that you also join industry specific cyberintelligence organizations, like any of the -ISACs, and/or a cyberintel provider if you don't have access to an -ISAC. The 3 major areas of infosec business focus in 2013 that I see will be insourcing malware analysis + automation of IOC generation, cyberintelligence, and DDoS mitigations. Businesses have realized that relying solely in external vendors to provide these services in a generic way results in good service but slower turnaround times; the insourced components become both a first tier of defense, and also a specialized set of incident responders that understand the business. Pierre On 31/01/2013 1:13 PM, matt kelly wrote: > Can anyone recommended ddos mitigation companies with US east coast > presence that provide the services via bgp? We are not interested in an > appliance but rather offloading the traffic. > > Thanks. From paul at paulstewart.org Fri Feb 1 15:02:01 2013 From: paul at paulstewart.org (Paul Stewart) Date: Fri, 1 Feb 2013 10:02:01 -0500 Subject: Ddos mitigation service In-Reply-To: <510BD7E8.4010805@userid.org> References: <510BD7E8.4010805@userid.org> Message-ID: <2ba901ce008d$1993d2f0$4cbb78d0$@paulstewart.org> Akamai (CDN) does scrubbing??? Paul -----Original Message----- From: Pierre Lamy [mailto:pierre at userid.org] Sent: February-01-13 9:58 AM To: matt kelly Cc: nanog at nanog.org Subject: Re: Ddos mitigation service The 3 major scrubbing vendors: Prolexic Verisign Akamai .... From jim at nimblesec.com Fri Feb 1 15:48:58 2013 From: jim at nimblesec.com (James Thomas) Date: Fri, 01 Feb 2013 10:48:58 -0500 Subject: Ddos mitigation service In-Reply-To: <510BD7E8.4010805@userid.org> References: <510BD7E8.4010805@userid.org> Message-ID: <510BE3EA.1010009@nimblesec.com> Hi Pierre, Thank you for your interesting note. On 01/02/2013 09:57, Pierre Lamy wrote: > The 3 major scrubbing vendors: > > Prolexic > Verisign > Akamai IIRC, CloudFlare claims to the same capcity of DDOS mitigation as Prolexic (500gb) and also has a free option with fewer scrubbing features. Do you have experience with it, or is there some other reason to have excluded it from your list? I apologize for my noobish question. Cheers, James From patrick at ianai.net Fri Feb 1 16:06:54 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 1 Feb 2013 11:06:54 -0500 Subject: Ddos mitigation service In-Reply-To: <2ba901ce008d$1993d2f0$4cbb78d0$@paulstewart.org> References: <510BD7E8.4010805@userid.org> <2ba901ce008d$1993d2f0$4cbb78d0$@paulstewart.org> Message-ID: On Feb 01, 2013, at 10:02 , "Paul Stewart" wrote: > Akamai (CDN) does scrubbing??? I'm sure there are other things Akamai does in the security sector as well. -- TTFN, patrick > -----Original Message----- > From: Pierre Lamy [mailto:pierre at userid.org] > Sent: February-01-13 9:58 AM > To: matt kelly > Cc: nanog at nanog.org > Subject: Re: Ddos mitigation service > > The 3 major scrubbing vendors: > > Prolexic > Verisign > Akamai > > .... > > > From pierre at userid.org Fri Feb 1 16:22:42 2013 From: pierre at userid.org (Pierre Lamy) Date: Fri, 01 Feb 2013 11:22:42 -0500 Subject: Ddos mitigation service In-Reply-To: <510BE3EA.1010009@nimblesec.com> References: <510BD7E8.4010805@userid.org> <510BE3EA.1010009@nimblesec.com> Message-ID: <510BEBD2.4000002@userid.org> I'm aware that they exist but don't have any knowledge or experience with CloudFlare. if you're considering using them, I would ask them for a list (under NDA) of what large enterprises use them, what their POPs are - global is good - and for any analytical product they have relating to DDoS that they have mitigated and investigated. Also a procedure guide on how you would engage them in event of a DDoS. You should really be asking a lot of questions before signing anything with anyone, and once you select one - TEST IT!!! A lot of orgs do not test their mitigation processes. The total time to mitigation if you're not already swung to a provider, should be down to 30 mins to an hour, this is reasonable for detection to full mitigation in large companies. Without running through an exercise, companies will find that mitigation takes 1-4 hours. It's also highly recommended that you have incident handlers who are able to make big decisions. -Pierre On 01/02/2013 10:48 AM, James Thomas wrote: > Hi Pierre, > > Thank you for your interesting note. > > On 01/02/2013 09:57, Pierre Lamy wrote: >> The 3 major scrubbing vendors: >> >> Prolexic >> Verisign >> Akamai > IIRC, CloudFlare claims to the same capcity of DDOS mitigation as > Prolexic (500gb) and also has a free option with fewer scrubbing > features. Do you have experience with it, or is there some other reason > to have excluded it from your list? I apologize for my noobish question. > > Cheers, > > James > From l-nanog at iodi.se Fri Feb 1 16:28:15 2013 From: l-nanog at iodi.se (Joseph Chin) Date: Fri, 1 Feb 2013 16:28:15 -0000 Subject: Ddos mitigation service In-Reply-To: <510BE3EA.1010009@nimblesec.com> References: <510BD7E8.4010805@userid.org> <510BE3EA.1010009@nimblesec.com> Message-ID: <011201ce0099$23b47b70$6b1d7250$@iodi.se> >From my personal experience, I am a fan of pure-play DDoS mitigation service providers (e.g. Prolexic, Dosarrest) because they are the least likely to give up on you when things get real difficult. Read the SLA careful to make sure it is fit for your purpose. -----Original Message----- From: James Thomas [mailto:jim at nimblesec.com] Sent: Friday, February 01, 2013 3:49 PM To: nanog at nanog.org Subject: Re: Ddos mitigation service Hi Pierre, Thank you for your interesting note. On 01/02/2013 09:57, Pierre Lamy wrote: > The 3 major scrubbing vendors: > > Prolexic > Verisign > Akamai IIRC, CloudFlare claims to the same capcity of DDOS mitigation as Prolexic (500gb) and also has a free option with fewer scrubbing features. Do you have experience with it, or is there some other reason to have excluded it from your list? I apologize for my noobish question. Cheers, James From johnl at iecc.com Fri Feb 1 16:36:05 2013 From: johnl at iecc.com (John R. Levine) Date: 1 Feb 2013 11:36:05 -0500 Subject: Muni network ownership and the Fourth In-Reply-To: <510BD07D.3000107@gmail.com> References: <20130130220300.40036.qmail@joyce.lan> <510BD07D.3000107@gmail.com> Message-ID: > The muni providers have a bunch of cost advantages that help them keep the > price lower. Yes, but: A) NYSEG customers are still paying off boondoggles due to incompetent current and former management that have nothing to do with their for-profit status B) So what? The customers get better service at lower price. FWIW, I can report that as municipal water and sewer commissioner, although technically we could foreclose, we never have. The threat of disconnection is quite adequate to get people to pay. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From brunner at nic-naa.net Fri Feb 1 17:33:00 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 01 Feb 2013 09:33:00 -0800 Subject: Muni network ownership and the Fourth In-Reply-To: <510BD07D.3000107@gmail.com> References: <20130130220300.40036.qmail@joyce.lan> <510BD07D.3000107@gmail.com> Message-ID: <510BFC4C.2000607@nic-naa.net> On 2/1/13 6:26 AM, Dave Sparro wrote: > municipal utilities: > - sell bonds cheaper (holders get tax-advantaged rates in interest > income, and are ultimately backed by the muni taxpayers) Tangential to the private vs public screed: The ability to issue (and sell) tax exempt (T-E) bonds for any purpose is a given for governments in the US -- unless the government is that of a Federally Recognized Indian Tribal government -- where an "essential government interest" test applies. The history of the "essential government interest" test is rather sordid, but it resulted in only two bonds issued by any tribal governments for any purpose in 2010, none in 2011, and none in the first half of 2012. In any event, the "cost advantage" Dave cited, is not restricted to network buildouts by public entities funded by T-E bonds. Eric From cscora at apnic.net Fri Feb 1 18:33:52 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 2 Feb 2013 04:33:52 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201302011833.r11IXqu7010599@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 02 Feb, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 440794 Prefixes after maximum aggregation: 181771 Deaggregation factor: 2.42 Unique aggregates announced to Internet: 216723 Total ASes present in the Internet Routing Table: 43204 Prefixes per ASN: 10.20 Origin-only ASes present in the Internet Routing Table: 34128 Origin ASes announcing only one prefix: 15925 Transit ASes present in the Internet Routing Table: 5738 Transit-only ASes present in the Internet Routing Table: 143 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 44 Max AS path prepend of ASN ( 28730) 25 Prefixes from unregistered ASNs in the Routing Table: 386 Unregistered ASNs in the Routing Table: 132 Number of 32-bit ASNs allocated by the RIRs: 3721 Number of 32-bit ASNs visible in the Routing Table: 3338 Prefixes from 32-bit ASNs in the Routing Table: 9176 Special use prefixes present in the Routing Table: 17 Prefixes being announced from unallocated address space: 211 Number of addresses announced to Internet: 2614575756 Equivalent to 155 /8s, 215 /16s and 66 /24s Percentage of available address space announced: 70.6 Percentage of allocated address space announced: 70.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.2 Total number of prefixes smaller than registry allocations: 155465 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 105955 Total APNIC prefixes after maximum aggregation: 33038 APNIC Deaggregation factor: 3.21 Prefixes being announced from the APNIC address blocks: 107002 Unique aggregates announced from the APNIC address blocks: 43739 APNIC Region origin ASes present in the Internet Routing Table: 4815 APNIC Prefixes per ASN: 22.22 APNIC Region origin ASes announcing only one prefix: 1240 APNIC Region transit ASes present in the Internet Routing Table: 807 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 418 Number of APNIC addresses announced to Internet: 717823104 Equivalent to 42 /8s, 201 /16s and 28 /24s Percentage of available APNIC address space announced: 83.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 155383 Total ARIN prefixes after maximum aggregation: 78669 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 155986 Unique aggregates announced from the ARIN address blocks: 70782 ARIN Region origin ASes present in the Internet Routing Table: 15445 ARIN Prefixes per ASN: 10.10 ARIN Region origin ASes announcing only one prefix: 5839 ARIN Region transit ASes present in the Internet Routing Table: 1592 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 17 Number of ARIN addresses announced to Internet: 1075851136 Equivalent to 64 /8s, 32 /16s and 47 /24s Percentage of available ARIN address space announced: 56.9 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 113324 Total RIPE prefixes after maximum aggregation: 58515 RIPE Deaggregation factor: 1.94 Prefixes being announced from the RIPE address blocks: 116432 Unique aggregates announced from the RIPE address blocks: 74751 RIPE Region origin ASes present in the Internet Routing Table: 17049 RIPE Prefixes per ASN: 6.83 RIPE Region origin ASes announcing only one prefix: 8156 RIPE Region transit ASes present in the Internet Routing Table: 2777 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 44 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2160 Number of RIPE addresses announced to Internet: 653059940 Equivalent to 38 /8s, 236 /16s and 231 /24s Percentage of available RIPE address space announced: 94.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 46480 Total LACNIC prefixes after maximum aggregation: 9100 LACNIC Deaggregation factor: 5.11 Prefixes being announced from the LACNIC address blocks: 50224 Unique aggregates announced from the LACNIC address blocks: 23555 LACNIC Region origin ASes present in the Internet Routing Table: 1794 LACNIC Prefixes per ASN: 28.00 LACNIC Region origin ASes announcing only one prefix: 512 LACNIC Region transit ASes present in the Internet Routing Table: 335 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 736 Number of LACNIC addresses announced to Internet: 123135528 Equivalent to 7 /8s, 86 /16s and 230 /24s Percentage of available LACNIC address space announced: 73.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 10337 Total AfriNIC prefixes after maximum aggregation: 2397 AfriNIC Deaggregation factor: 4.31 Prefixes being announced from the AfriNIC address blocks: 10939 Unique aggregates announced from the AfriNIC address blocks: 3709 AfriNIC Region origin ASes present in the Internet Routing Table: 590 AfriNIC Prefixes per ASN: 18.54 AfriNIC Region origin ASes announcing only one prefix: 178 AfriNIC Region transit ASes present in the Internet Routing Table: 127 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 17 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 7 Number of AfriNIC addresses announced to Internet: 44281856 Equivalent to 2 /8s, 163 /16s and 176 /24s Percentage of available AfriNIC address space announced: 44.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2932 11557 922 Korea Telecom (KIX) 17974 2475 829 53 PT TELEKOMUNIKASI INDONESIA 7545 1824 301 87 TPG Internet Pty Ltd 4755 1681 382 188 TATA Communications formerly 9829 1425 1150 45 BSNL National Internet Backbo 9583 1207 90 502 Sify Limited 7552 1164 1070 12 Vietel Corporation 4808 1101 2040 315 CNCGROUP IP network: China169 9498 1054 310 75 BHARTI Airtel Ltd. 24560 1044 385 160 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3093 3699 115 bellsouth.net, inc. 7029 2288 1265 211 Windstream Communications Inc 18566 2081 382 183 Covad Communications 22773 1965 2931 128 Cox Communications, Inc. 1785 1949 678 123 PaeTec Communications, Inc. 20115 1688 1608 625 Charter Communications 4323 1598 1155 394 Time Warner Telecom 30036 1345 287 698 Mediacom Communications Corp 7018 1298 10550 859 AT&T WorldNet Services 7011 1200 315 682 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1848 544 16 Corbina telecom 2118 1114 97 13 EUnet/RELCOM Autonomous Syste 34984 974 231 205 BILISIM TELEKOM 13188 842 99 22 Educational Network 12479 836 778 65 Uni2 Autonomous System 31148 755 39 18 FreeNet ISP 20940 742 252 589 Akamai Technologies European 8551 714 367 39 Bezeq International 6830 713 2313 434 UPC Distribution Services 58113 633 70 378 LIR DATACENTER TELECOM SRL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 2308 395 224 TVCABLE BOGOTA 28573 2215 1315 81 NET Servicos de Comunicao S.A 7303 1679 1147 206 Telecom Argentina Stet-France 8151 1539 2892 379 UniNet S.A. de C.V. 6503 1473 435 67 AVANTEL, S.A. 14754 909 114 72 Telgua S. A. 27947 774 85 95 Telconet S.A 18881 756 716 18 Global Village Telecom 3816 676 306 85 Empresa Nacional de Telecomun 11172 604 86 67 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1286 80 4 MOBITEL 24863 896 275 36 LINKdotNET AS number 8452 529 958 13 TEDATA 6713 499 602 20 Itissalat Al-MAGHRIB 24835 329 80 8 RAYA Telecom - Egypt 3741 266 906 224 The Internet Solution 12258 193 28 67 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 190 696 90 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3093 3699 115 bellsouth.net, inc. 4766 2932 11557 922 Korea Telecom (KIX) 17974 2475 829 53 PT TELEKOMUNIKASI INDONESIA 10620 2308 395 224 TVCABLE BOGOTA 7029 2288 1265 211 Windstream Communications Inc 28573 2215 1315 81 NET Servicos de Comunicao S.A 18566 2081 382 183 Covad Communications 22773 1965 2931 128 Cox Communications, Inc. 1785 1949 678 123 PaeTec Communications, Inc. 8402 1848 544 16 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 2475 2422 PT TELEKOMUNIKASI INDONESIA 28573 2215 2134 NET Servicos de Comunicao S.A 10620 2308 2084 TVCABLE BOGOTA 7029 2288 2077 Windstream Communications Inc 4766 2932 2010 Korea Telecom (KIX) 18566 2081 1898 Covad Communications 22773 1965 1837 Cox Communications, Inc. 8402 1848 1832 Corbina telecom 1785 1949 1826 PaeTec Communications, Inc. 7545 1824 1737 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.60.0/23 57417 INTERNET TASMANIA SRL 128.0.62.0/23 57417 INTERNET TASMANIA SRL 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.96.0/21 12886 LEWTelNet GmbH 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 27.112.114.0/24 23884 Proimage Engineering and Comm 31.210.16.0/22 15657 Neural Networks ASN 41.222.80.0/21 37110 Moztel LDA 62.12.96.0/19 38478 SunnyVision Limited 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:17 /9:13 /10:29 /11:88 /12:246 /13:481 /14:865 /15:1548 /16:12551 /17:6601 /18:10967 /19:21729 /20:31101 /21:33241 /22:45078 /23:40752 /24:231230 /25:1364 /26:1742 /27:858 /28:183 /29:73 /30:17 /31:0 /32:20 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2031 2081 Covad Communications 6389 1769 3093 bellsouth.net, inc. 7029 1643 2288 Windstream Communications Inc 8402 1577 1848 Corbina telecom 22773 1292 1965 Cox Communications, Inc. 36998 1280 1286 MOBITEL 30036 1238 1345 Mediacom Communications Corp 11492 1158 1195 Cable One 1785 1031 1949 PaeTec Communications, Inc. 6503 983 1473 AVANTEL, S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:684 2:749 3:3 4:13 5:737 6:3 8:490 12:1927 13:3 14:719 15:11 16:3 17:8 20:25 23:237 24:1799 27:1471 31:1127 32:54 33:2 34:5 36:10 37:1230 38:845 39:2 40:139 41:2649 42:180 44:4 46:1725 47:1 49:547 50:643 52:12 54:28 55:7 57:28 58:1078 59:556 60:251 61:1320 62:999 63:2027 64:4338 65:2158 66:4265 67:2018 68:1119 69:3228 70:858 71:535 72:1879 74:2544 75:421 76:291 77:1061 78:1034 79:552 80:1209 81:981 82:639 83:534 84:578 85:1147 86:477 87:969 88:370 89:1740 90:285 91:5389 92:616 93:1708 94:2013 95:1614 96:489 97:333 98:1052 99:52 100:30 101:305 103:2059 105:519 106:131 107:208 108:508 109:1751 110:848 111:1005 112:482 113:740 114:683 115:932 116:877 117:788 118:978 119:1263 120:343 121:702 122:1731 123:1178 124:1320 125:1306 128:545 129:200 130:312 131:645 132:327 133:143 134:254 135:62 136:213 137:237 138:340 139:155 140:216 141:314 142:509 143:365 144:474 145:90 146:527 147:332 148:730 149:341 150:159 151:328 152:399 153:190 154:25 155:367 156:241 157:395 158:258 159:708 160:334 161:415 162:370 163:202 164:581 165:462 166:465 167:571 168:1007 169:131 170:1012 171:164 172:4 173:1543 174:616 175:422 176:1002 177:1624 178:1703 180:1375 181:222 182:1157 183:323 184:642 185:197 186:2262 187:1464 188:1935 189:1547 190:6557 192:6221 193:5671 194:4648 195:3657 196:1283 197:808 198:4108 199:5194 200:6005 201:2177 202:8803 203:8732 204:4463 205:2545 206:2798 207:2789 208:4076 209:3528 210:2912 211:1563 212:1982 213:1886 214:906 215:93 216:5073 217:1581 218:591 219:326 220:1267 221:548 222:337 223:415 End of report From khelms at zcorum.com Fri Feb 1 20:29:32 2013 From: khelms at zcorum.com (Scott Helms) Date: Fri, 1 Feb 2013 15:29:32 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> Message-ID: Owen, You're basing your math off of some incorrect assumptions about PON. I'm actually sympathetic to your goal, but it simply can't work the way you're describing it in a PON network. Also, please don't base logic for open access on meet me rooms, this works in colo spaces and carrier hotels but doesn't in broadband deployments because of economics. If you want to champion this worthy goal you've got to accept that economics is a huge reason why this hasn't happened in the US and is disappearing where it has happened globally. > Bottom line, you've got OLT -> FIBER(of length n) -> splitter -> > fiber-drops to each house -> ONT. > So far you're correct. > > All I'm proposing is making n really short and making "fiber-drops to each > house" really long. > I'm not proposing changing the fundamental architecture. Yes, I recognize > this changes the economics and may well make PON less attractive than other > alternatives. I don't care. That's not a primary concern. The question is > "can PON be made to work in this environment?" It appears to me that it can. > Here is where you're problems start. The issue is that the signal *prior to being split* can go 20km if you're splitting it 32 ways (or less) or 10km if you're doing a 64 way split. AFTER the splitter you have a MAX radius of about 1 mile from the splitter. Here is a good document that describes the problem in some detail: http://www.ofsoptics.com/press_room/media-pdfs/FTTH-Prism-0909.pdf Also, here is a proposed spec that would allow for longer runs post splitter with some background on why it can't work in today's GPON deployments. http://www.ericsson.com/il/res/thecompany/docs/publications/ericsson_review/2008/3_PON.pdf -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jason at thebaughers.com Fri Feb 1 21:03:33 2013 From: jason at thebaughers.com (Jason Baugher) Date: Fri, 1 Feb 2013 15:03:33 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> Message-ID: I disagree. Loss is loss, regardless of where the splitter is placed in the equation. Distance x loss + splitter insertion loss = total loss for purposes of link budget calculation. The reason to push splitters towards the customer end is financial, not technical. On Fri, Feb 1, 2013 at 2:29 PM, Scott Helms wrote: > Owen, > > You're basing your math off of some incorrect assumptions about PON. I'm > actually sympathetic to your goal, but it simply can't work the way you're > describing it in a PON network. Also, please don't base logic for open > access on meet me rooms, this works in colo spaces and carrier hotels but > doesn't in broadband deployments because of economics. If you want to > champion this worthy goal you've got to accept that economics is a huge > reason why this hasn't happened in the US and is disappearing where it has > happened globally. > > > > Bottom line, you've got OLT -> FIBER(of length n) -> splitter -> > > fiber-drops to each house -> ONT. > > > > So far you're correct. > > > > > > All I'm proposing is making n really short and making "fiber-drops to > each > > house" really long. > > I'm not proposing changing the fundamental architecture. Yes, I recognize > > this changes the economics and may well make PON less attractive than > other > > alternatives. I don't care. That's not a primary concern. The question is > > "can PON be made to work in this environment?" It appears to me that it > can. > > > > > Here is where you're problems start. The issue is that the signal *prior > to being split* can go 20km if you're splitting it 32 ways (or less) or > 10km if you're doing a 64 way split. AFTER the splitter you have a MAX > radius of about 1 mile from the splitter. > > Here is a good document that describes the problem in some detail: > > http://www.ofsoptics.com/press_room/media-pdfs/FTTH-Prism-0909.pdf > > > Also, here is a proposed spec that would allow for longer runs post > splitter with some background on why it can't work in today's GPON > deployments. > > > http://www.ericsson.com/il/res/thecompany/docs/publications/ericsson_review/2008/3_PON.pdf > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > From jason at thebaughers.com Fri Feb 1 21:04:18 2013 From: jason at thebaughers.com (Jason Baugher) Date: Fri, 1 Feb 2013 15:04:18 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> Message-ID: I should clarify: Distance x loss/km + splitter loss. = link loss. On Fri, Feb 1, 2013 at 3:03 PM, Jason Baugher wrote: > I disagree. Loss is loss, regardless of where the splitter is placed in > the equation. Distance x loss + splitter insertion loss = total loss for > purposes of link budget calculation. > > The reason to push splitters towards the customer end is financial, not > technical. > > > On Fri, Feb 1, 2013 at 2:29 PM, Scott Helms wrote: > >> Owen, >> >> You're basing your math off of some incorrect assumptions about PON. I'm >> actually sympathetic to your goal, but it simply can't work the way you're >> describing it in a PON network. Also, please don't base logic for open >> access on meet me rooms, this works in colo spaces and carrier hotels but >> doesn't in broadband deployments because of economics. If you want to >> champion this worthy goal you've got to accept that economics is a huge >> reason why this hasn't happened in the US and is disappearing where it has >> happened globally. >> >> >> > Bottom line, you've got OLT -> FIBER(of length n) -> splitter -> >> > fiber-drops to each house -> ONT. >> > >> >> So far you're correct. >> >> >> > >> > All I'm proposing is making n really short and making "fiber-drops to >> each >> > house" really long. >> > I'm not proposing changing the fundamental architecture. Yes, I >> recognize >> > this changes the economics and may well make PON less attractive than >> other >> > alternatives. I don't care. That's not a primary concern. The question >> is >> > "can PON be made to work in this environment?" It appears to me that it >> can. >> > >> >> >> Here is where you're problems start. The issue is that the signal *prior >> to being split* can go 20km if you're splitting it 32 ways (or less) or >> 10km if you're doing a 64 way split. AFTER the splitter you have a MAX >> radius of about 1 mile from the splitter. >> >> Here is a good document that describes the problem in some detail: >> >> http://www.ofsoptics.com/press_room/media-pdfs/FTTH-Prism-0909.pdf >> >> >> Also, here is a proposed spec that would allow for longer runs post >> splitter with some background on why it can't work in today's GPON >> deployments. >> >> >> http://www.ericsson.com/il/res/thecompany/docs/publications/ericsson_review/2008/3_PON.pdf >> >> -- >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> > > From khelms at zcorum.com Fri Feb 1 21:09:12 2013 From: khelms at zcorum.com (Scott Helms) Date: Fri, 1 Feb 2013 16:09:12 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> Message-ID: Jason, Loss is loss, but that's not all that we have to deal with here inside of how PON works. I can tell you that not a single manufacturer I've worked with says anything differently. On Fri, Feb 1, 2013 at 4:03 PM, Jason Baugher wrote: > I disagree. Loss is loss, regardless of where the splitter is placed in > the equation. Distance x loss + splitter insertion loss = total loss for > purposes of link budget calculation. > > The reason to push splitters towards the customer end is financial, not > technical. > > > On Fri, Feb 1, 2013 at 2:29 PM, Scott Helms wrote: > >> Owen, >> >> You're basing your math off of some incorrect assumptions about PON. I'm >> actually sympathetic to your goal, but it simply can't work the way you're >> describing it in a PON network. Also, please don't base logic for open >> access on meet me rooms, this works in colo spaces and carrier hotels but >> doesn't in broadband deployments because of economics. If you want to >> champion this worthy goal you've got to accept that economics is a huge >> reason why this hasn't happened in the US and is disappearing where it has >> happened globally. >> >> >> > Bottom line, you've got OLT -> FIBER(of length n) -> splitter -> >> > fiber-drops to each house -> ONT. >> > >> >> So far you're correct. >> >> >> > >> > All I'm proposing is making n really short and making "fiber-drops to >> each >> > house" really long. >> > I'm not proposing changing the fundamental architecture. Yes, I >> recognize >> > this changes the economics and may well make PON less attractive than >> other >> > alternatives. I don't care. That's not a primary concern. The question >> is >> > "can PON be made to work in this environment?" It appears to me that it >> can. >> > >> >> >> Here is where you're problems start. The issue is that the signal *prior >> to being split* can go 20km if you're splitting it 32 ways (or less) or >> 10km if you're doing a 64 way split. AFTER the splitter you have a MAX >> radius of about 1 mile from the splitter. >> >> Here is a good document that describes the problem in some detail: >> >> http://www.ofsoptics.com/press_room/media-pdfs/FTTH-Prism-0909.pdf >> >> >> Also, here is a proposed spec that would allow for longer runs post >> splitter with some background on why it can't work in today's GPON >> deployments. >> >> >> http://www.ericsson.com/il/res/thecompany/docs/publications/ericsson_review/2008/3_PON.pdf >> >> -- >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From owen at delong.com Fri Feb 1 21:16:45 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Feb 2013 13:16:45 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> Message-ID: Actually, this is an issue? I should have seen it. You have 3 loss components? Power out = (Power in - loss to splitter - splitter loss) / nOut - loss-to-customer So, if the loss to the splitter is 3db and you have 20db (effective 320db on a 16x split) loss on each customer link, that's a radically worse proposition than 20db loss to the splitter and 3db loss to each customer (which is effectively 48db loss on a 16x split). It's still do-able, but you either need amplifier(s) or very short distances between the customer and the MMR. Given this consideration, I think the situation can still be addressed. Put the splitters in the B-Box and allow for the possibility that each subscriber can be XC to either a splitter or an upstream dedicated fiber. The provider side of each splitter would be connected to an upstream fiber to the MMR. So, each B-Box contains however many splitters are required and each splitter is connected upstream to a single provider, but you can still have multiple competitive providers in the MMR. This setup could support both PON and Ethernet as well as other future technologies. Owen On Feb 1, 2013, at 1:04 PM, Jason Baugher wrote: > I should clarify: Distance x loss/km + splitter loss. = link loss. > > > On Fri, Feb 1, 2013 at 3:03 PM, Jason Baugher wrote: > I disagree. Loss is loss, regardless of where the splitter is placed in the equation. Distance x loss + splitter insertion loss = total loss for purposes of link budget calculation. > > The reason to push splitters towards the customer end is financial, not technical. > > > On Fri, Feb 1, 2013 at 2:29 PM, Scott Helms wrote: > Owen, > > You're basing your math off of some incorrect assumptions about PON. I'm > actually sympathetic to your goal, but it simply can't work the way you're > describing it in a PON network. Also, please don't base logic for open > access on meet me rooms, this works in colo spaces and carrier hotels but > doesn't in broadband deployments because of economics. If you want to > champion this worthy goal you've got to accept that economics is a huge > reason why this hasn't happened in the US and is disappearing where it has > happened globally. > > > > Bottom line, you've got OLT -> FIBER(of length n) -> splitter -> > > fiber-drops to each house -> ONT. > > > > So far you're correct. > > > > > > All I'm proposing is making n really short and making "fiber-drops to each > > house" really long. > > I'm not proposing changing the fundamental architecture. Yes, I recognize > > this changes the economics and may well make PON less attractive than other > > alternatives. I don't care. That's not a primary concern. The question is > > "can PON be made to work in this environment?" It appears to me that it can. > > > > > Here is where you're problems start. The issue is that the signal *prior > to being split* can go 20km if you're splitting it 32 ways (or less) or > 10km if you're doing a 64 way split. AFTER the splitter you have a MAX > radius of about 1 mile from the splitter. > > Here is a good document that describes the problem in some detail: > > http://www.ofsoptics.com/press_room/media-pdfs/FTTH-Prism-0909.pdf > > > Also, here is a proposed spec that would allow for longer runs post > splitter with some background on why it can't work in today's GPON > deployments. > > http://www.ericsson.com/il/res/thecompany/docs/publications/ericsson_review/2008/3_PON.pdf > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > From jason at thebaughers.com Fri Feb 1 21:43:20 2013 From: jason at thebaughers.com (Jason Baugher) Date: Fri, 1 Feb 2013 15:43:20 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> Message-ID: It's still a 23dB loss for each customer from the CO to the ONT. I have an OLT that launches at +5dBm. At 1490nm, I should see about a .26dB loss per km. My 1x32 splitter is going to add about 16dB more loss. Assuming we ignore connector losses, and also assume that the customer is 10km away: CO-based splitter: +5dBm - 16dB - (10km x .26dB) = -13.6 Splitter at 9km: +5dBm - (9km x .26dB) - 16dB - (1km x .26dB) = -13.6 If someone can explain why this math would be wrong, I'd love to hear it and I'd be happy to run it past our vendor to see if they agree. On Fri, Feb 1, 2013 at 3:16 PM, Owen DeLong wrote: > Actually, this is an issue? I should have seen it. > > > You have 3 loss components? Power out = (Power in - loss to splitter - > splitter loss) / nOut - loss-to-customer > > So, if the loss to the splitter is 3db and you have 20db (effective 320db > on a 16x split) loss on each customer link, that's > a radically worse proposition than 20db loss to the splitter and 3db loss > to each customer (which is effectively 48db > loss on a 16x split). > > It's still do-able, but you either need amplifier(s) or very short > distances between the customer and the MMR. > > Given this consideration, I think the situation can still be addressed. > > Put the splitters in the B-Box and allow for the possibility that each > subscriber can be XC to either a splitter or > an upstream dedicated fiber. The provider side of each splitter would be > connected to an upstream fiber > to the MMR. > > So, each B-Box contains however many splitters are required and each > splitter is connected upstream to a > single provider, but you can still have multiple competitive providers in > the MMR. > > This setup could support both PON and Ethernet as well as other future > technologies. > > Owen > > On Feb 1, 2013, at 1:04 PM, Jason Baugher wrote: > > I should clarify: Distance x loss/km + splitter loss. = link loss. > > > On Fri, Feb 1, 2013 at 3:03 PM, Jason Baugher wrote: > >> I disagree. Loss is loss, regardless of where the splitter is placed in >> the equation. Distance x loss + splitter insertion loss = total loss for >> purposes of link budget calculation. >> >> The reason to push splitters towards the customer end is financial, not >> technical. >> >> >> On Fri, Feb 1, 2013 at 2:29 PM, Scott Helms wrote: >> >>> Owen, >>> >>> You're basing your math off of some incorrect assumptions about PON. I'm >>> actually sympathetic to your goal, but it simply can't work the way >>> you're >>> describing it in a PON network. Also, please don't base logic for open >>> access on meet me rooms, this works in colo spaces and carrier hotels but >>> doesn't in broadband deployments because of economics. If you want to >>> champion this worthy goal you've got to accept that economics is a huge >>> reason why this hasn't happened in the US and is disappearing where it >>> has >>> happened globally. >>> >>> >>> > Bottom line, you've got OLT -> FIBER(of length n) -> splitter -> >>> > fiber-drops to each house -> ONT. >>> > >>> >>> So far you're correct. >>> >>> >>> > >>> > All I'm proposing is making n really short and making "fiber-drops to >>> each >>> > house" really long. >>> > I'm not proposing changing the fundamental architecture. Yes, I >>> recognize >>> > this changes the economics and may well make PON less attractive than >>> other >>> > alternatives. I don't care. That's not a primary concern. The question >>> is >>> > "can PON be made to work in this environment?" It appears to me that >>> it can. >>> > >>> >>> >>> Here is where you're problems start. The issue is that the signal *prior >>> to being split* can go 20km if you're splitting it 32 ways (or less) or >>> 10km if you're doing a 64 way split. AFTER the splitter you have a MAX >>> radius of about 1 mile from the splitter. >>> >>> Here is a good document that describes the problem in some detail: >>> >>> http://www.ofsoptics.com/press_room/media-pdfs/FTTH-Prism-0909.pdf >>> >>> >>> Also, here is a proposed spec that would allow for longer runs post >>> splitter with some background on why it can't work in today's GPON >>> deployments. >>> >>> >>> http://www.ericsson.com/il/res/thecompany/docs/publications/ericsson_review/2008/3_PON.pdf >>> >>> -- >>> Scott Helms >>> Vice President of Technology >>> ZCorum >>> (678) 507-5000 >>> -------------------------------- >>> http://twitter.com/kscotthelms >>> -------------------------------- >>> >> >> > > From cidr-report at potaroo.net Fri Feb 1 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Feb 2013 22:00:01 GMT Subject: The Cidr Report Message-ID: <201302012200.r11M01kr081341@wattle.apnic.net> This report has been generated at Fri Feb 1 21:13:15 2013 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 25-01-13 442636 254436 26-01-13 442936 254309 27-01-13 442378 254385 28-01-13 442959 254504 29-01-13 443056 254707 30-01-13 443192 255293 31-01-13 443138 254917 01-02-13 443327 255033 AS Summary 43308 Number of ASes in routing system 17978 Number of ASes announcing only one prefix 3093 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 116126432 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 01Feb13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 443569 254987 188582 42.5% All ASes AS6389 3093 119 2974 96.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2323 82 2241 96.5% NET Servicos de Comunicao S.A. AS4766 2932 939 1993 68.0% KIXS-AS-KR Korea Telecom AS17974 2475 485 1990 80.4% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS22773 1965 261 1704 86.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2081 425 1656 79.6% COVAD - Covad Communications Co. AS10620 2308 678 1630 70.6% Telmex Colombia S.A. AS7303 1679 407 1272 75.8% Telecom Argentina S.A. AS4323 1602 399 1203 75.1% TWTC - tw telecom holdings, inc. AS4755 1681 578 1103 65.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1114 83 1031 92.5% RELCOM-AS OOO "NPO Relcom" AS7029 2288 1264 1024 44.8% WINDSTREAM - Windstream Communications Inc AS7552 1161 181 980 84.4% VIETEL-AS-AP Vietel Corporation AS36998 1286 381 905 70.4% SDN-MOBITEL AS18101 1016 170 846 83.3% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8151 1548 745 803 51.9% Uninet S.A. de C.V. AS1785 1950 1165 785 40.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS4808 1101 354 747 67.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS18881 756 26 730 96.6% Global Village Telecom AS14754 910 184 726 79.8% Telgua AS13977 843 118 725 86.0% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS7545 1830 1120 710 38.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS855 709 53 656 92.5% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS9808 683 50 633 92.7% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS22561 1065 443 622 58.4% DIGITAL-TELEPORT - Digital Teleport Inc. AS17676 718 97 621 86.5% GIGAINFRA Softbank BB Corp. AS24560 1044 429 615 58.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3356 1105 498 607 54.9% LEVEL3 Level 3 Communications AS3549 1046 447 599 57.3% GBLX Global Crossing Ltd. AS19262 1001 405 596 59.5% VZGNI-TRANSIT - Verizon Online LLC Total 45313 12586 32727 72.2% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 27.112.114.0/24 AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd. 31.210.16.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH 41.222.80.0/21 AS37110 moztel-as 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 74.200.96.0/24 AS46271 74.200.98.0/24 AS46250 74.200.100.0/24 AS25854 WEBALG-COM - WebALG.com 74.200.102.0/24 AS46271 74.200.107.0/24 AS46250 74.200.108.0/24 AS35937 MARQUISNET - MarquisNet 74.200.114.0/24 AS2828 XO-AS15 - XO Communications 74.200.118.0/24 AS25854 WEBALG-COM - WebALG.com 74.200.119.0/24 AS25854 WEBALG-COM - WebALG.com 74.200.120.0/24 AS25854 WEBALG-COM - WebALG.com 74.200.126.0/24 AS21867 DEALERTRACKCANADA - DealerTrack Canada Inc. 74.200.127.0/24 AS12188 Q9-AS - Q9 Networks Inc. 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 91.217.250.0/24 AS43108 GARM-AS Garm Technologies Ltd. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.11.148.0/24 AS58452 103.11.149.0/24 AS58452 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.252.0/22 AS2386 INS-AS - AT&T Data Communications Services 208.89.253.0/24 AS2386 INS-AS - AT&T Data Communications Services 208.89.254.0/24 AS2386 INS-AS - AT&T Data Communications Services 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 1 22:00:02 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Feb 2013 22:00:02 GMT Subject: BGP Update Report Message-ID: <201302012200.r11M026Q081355@wattle.apnic.net> BGP Update Report Interval: 24-Jan-13 -to- 31-Jan-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 71162 3.6% 84.3 -- BSNL-NIB National Internet Backbone 2 - AS8402 63909 3.3% 28.0 -- CORBINA-AS OJSC "Vimpelcom" 3 - AS3909 43016 2.2% 14338.7 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - AS9498 41793 2.1% 77.7 -- BBIL-AP BHARTI Airtel Ltd. 5 - AS24560 33680 1.7% 74.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 6 - AS29256 32286 1.6% 872.6 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 7 - AS7552 18766 1.0% 19.8 -- VIETEL-AS-AP Vietel Corporation 8 - AS18207 17586 0.9% 57.3 -- YOU-INDIA-AP YOU Broadband & Cable India Ltd. 9 - AS17762 17248 0.9% 55.1 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 10 - AS28573 15781 0.8% 14.3 -- NET Servicos de Comunicao S.A. 11 - AS3816 15463 0.8% 30.9 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 12 - AS32847 14884 0.8% 14884.0 -- LMGINC-ORL - LMG, Inc 13 - AS18002 13932 0.7% 85.0 -- WORLDPHONE-IN AS Number for Interdomain Routing 14 - AS5976 13878 0.7% 90.1 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 15 - AS31148 13124 0.7% 17.3 -- FREENET-AS Freenet Ltd. 16 - AS19361 12850 0.7% 377.9 -- Atrium Telecomunicacoes Ltda 17 - AS2708 12795 0.7% 175.3 -- Universidad de Guanajuato 18 - AS22561 12604 0.7% 182.7 -- DIGITAL-TELEPORT - Digital Teleport Inc. 19 - AS45528 11256 0.6% 26.5 -- TDN Tikona Digital Networks Pvt Ltd. 20 - AS7303 11026 0.6% 12.0 -- Telecom Argentina S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32847 14884 0.8% 14884.0 -- LMGINC-ORL - LMG, Inc 2 - AS3909 43016 2.2% 14338.7 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - AS6629 7367 0.4% 7367.0 -- NOAA-AS - NOAA 4 - AS2033 4180 0.2% 4180.0 -- PANIX - Panix Network Information Center 5 - AS19406 3994 0.2% 3994.0 -- TWRS-MA - Towerstream I, Inc. 6 - AS6174 5835 0.3% 2917.5 -- SPRINTLINK8 - Sprint 7 - AS27594 5419 0.3% 2709.5 -- UTSA - University of Texas at San Antonio 8 - AS22140 4921 0.2% 2460.5 -- T-MOBILE-AS22140 - T-Mobile USA, Inc. 9 - AS6197 2259 0.1% 2259.0 -- BATI-ATL - BellSouth Network Solutions, Inc 10 - AS57918 2021 0.1% 2021.0 -- ACOD-AS ACOD CJSC 11 - AS17293 3782 0.2% 1891.0 -- VTXC - VTX Communications 12 - AS14680 5519 0.3% 1839.7 -- REALE-6 - Auction.com 13 - AS2 5872 0.3% 633.0 -- DEFOE-AS-AP Defoe Chan & Company (Hong Kong) Limited 14 - AS40931 1115 0.1% 1115.0 -- MOBITV - MobiTV, Inc 15 - AS29256 32286 1.6% 872.6 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 16 - AS9950 4134 0.2% 826.8 -- PUBNETPLUS2-AS-KR DACOM 17 - AS19886 4261 0.2% 710.2 -- BOFABROKERDEALERSVCS - Bank of America 18 - AS40968 707 0.0% 707.0 -- DSC Professional Protection Electronic Ltd. 19 - AS4 674 0.0% 51.0 -- COMUNICALO DE MEXICO S.A. DE C.V 20 - AS8657 583 0.0% 583.0 -- CPRM CPRM Autonomous System TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 173.227.147.0/24 14884 0.7% AS32847 -- LMGINC-ORL - LMG, Inc 2 - 151.118.18.0/24 14391 0.7% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - 151.118.254.0/24 14313 0.7% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - 151.118.255.0/24 14312 0.7% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 5 - 184.159.130.0/23 12001 0.6% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 6 - 192.58.232.0/24 7367 0.3% AS6629 -- NOAA-AS - NOAA 7 - 37.112.48.0/22 7276 0.3% AS57044 -- BRYANSK-AS CJSC "ER-Telecom Holding" 8 - 208.14.186.0/24 4919 0.2% AS22140 -- T-MOBILE-AS22140 - T-Mobile USA, Inc. 9 - 194.63.9.0/24 4849 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 10 - 41.160.115.0/24 4653 0.2% AS6453 -- GLOBEINTERNET TATA Communications 11 - 12.139.133.0/24 4613 0.2% AS14680 -- REALE-6 - Auction.com 12 - 209.48.168.0/24 4180 0.2% AS2033 -- PANIX - Panix Network Information Center 13 - 202.41.70.0/24 4166 0.2% AS2697 -- ERX-ERNET-AS Education and Research Network 14 - 58.184.229.0/24 4122 0.2% AS9950 -- PUBNETPLUS2-AS-KR DACOM 15 - 69.38.178.0/24 3994 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 16 - 123.252.208.0/24 3910 0.2% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 17 - 203.17.90.0/24 3709 0.2% AS4802 -- ASN-IINET iiNet Limited 18 - 49.248.72.0/21 3621 0.2% AS17762 -- HTIL-TTML-IN-AP Tata Teleservices Maharashtra Ltd 19 - 5.0.32.0/19 3421 0.2% AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment 20 - 5.0.160.0/19 2945 0.1% AS29256 -- INT-PDN-STE-AS Syrian Telecommunications Establishment Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From owen at delong.com Fri Feb 1 21:59:54 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Feb 2013 13:59:54 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> Message-ID: <569198EE-5E0D-4D2B-A1DA-33057148BCC4@delong.com> On Feb 1, 2013, at 1:43 PM, Jason Baugher wrote: > It's still a 23dB loss for each customer from the CO to the ONT. > > I have an OLT that launches at +5dBm. At 1490nm, I should see about a .26dB loss per km. My 1x32 splitter is going to add about 16dB more loss. Assuming we ignore connector losses, and also assume that the customer is 10km away: > Nope? The power going into each fiber out of the splitter is 1/16th that of what went into the splitter. Yes, your total in-line loss is still 10km, but you are forgetting about the fact that you lost 15/16th of the power effectively going to the fiber when you went through the splitter (in addition to the splitter loss itself). So: CO Based splitter: Each customer gets (IN - 16dB - (10km x .26db))/32 Splitter at 9km: Each customer gets (IN - (9km x .26dB) -16db)/32-(1km x .26db) If we use 5dBm as our input, this works out: CO: (5db - 16db - (10km x .26db) / 32 /32 is effectively -15 db (-3db = ? power, 32 = 2^5) Substituting: (5db - 16db - 2.6db) -15db = -28.6db to each customer. Spitter at 9km: (5db - (9km x .26db) -16db)/32-(1km x .26db) Substituting: (5db - 2.34db -16db)-15db-.26db = -28.08db to each customer So there is a difference, but it seems rather negligible now that I've run the numbers. However, it's entirely possible that I got this wrong somewhere, so I invite those more expert than I to review the calculations and tell me what I got wrong. Owen > CO-based splitter: > +5dBm - 16dB - (10km x .26dB) = -13.6 > > Splitter at 9km: > +5dBm - (9km x .26dB) - 16dB - (1km x .26dB) = -13.6 > > > If someone can explain why this math would be wrong, I'd love to hear it and I'd be happy to run it past our vendor to see if they agree. > > > On Fri, Feb 1, 2013 at 3:16 PM, Owen DeLong wrote: > Actually, this is an issue? I should have seen it. > > > You have 3 loss components? Power out = (Power in - loss to splitter - splitter loss) / nOut - loss-to-customer > > So, if the loss to the splitter is 3db and you have 20db (effective 320db on a 16x split) loss on each customer link, that's > a radically worse proposition than 20db loss to the splitter and 3db loss to each customer (which is effectively 48db > loss on a 16x split). > > It's still do-able, but you either need amplifier(s) or very short distances between the customer and the MMR. > > Given this consideration, I think the situation can still be addressed. > > Put the splitters in the B-Box and allow for the possibility that each subscriber can be XC to either a splitter or > an upstream dedicated fiber. The provider side of each splitter would be connected to an upstream fiber > to the MMR. > > So, each B-Box contains however many splitters are required and each splitter is connected upstream to a > single provider, but you can still have multiple competitive providers in the MMR. > > This setup could support both PON and Ethernet as well as other future technologies. > > Owen > > On Feb 1, 2013, at 1:04 PM, Jason Baugher wrote: > >> I should clarify: Distance x loss/km + splitter loss. = link loss. >> >> >> On Fri, Feb 1, 2013 at 3:03 PM, Jason Baugher wrote: >> I disagree. Loss is loss, regardless of where the splitter is placed in the equation. Distance x loss + splitter insertion loss = total loss for purposes of link budget calculation. >> >> The reason to push splitters towards the customer end is financial, not technical. >> >> >> On Fri, Feb 1, 2013 at 2:29 PM, Scott Helms wrote: >> Owen, >> >> You're basing your math off of some incorrect assumptions about PON. I'm >> actually sympathetic to your goal, but it simply can't work the way you're >> describing it in a PON network. Also, please don't base logic for open >> access on meet me rooms, this works in colo spaces and carrier hotels but >> doesn't in broadband deployments because of economics. If you want to >> champion this worthy goal you've got to accept that economics is a huge >> reason why this hasn't happened in the US and is disappearing where it has >> happened globally. >> >> >> > Bottom line, you've got OLT -> FIBER(of length n) -> splitter -> >> > fiber-drops to each house -> ONT. >> > >> >> So far you're correct. >> >> >> > >> > All I'm proposing is making n really short and making "fiber-drops to each >> > house" really long. >> > I'm not proposing changing the fundamental architecture. Yes, I recognize >> > this changes the economics and may well make PON less attractive than other >> > alternatives. I don't care. That's not a primary concern. The question is >> > "can PON be made to work in this environment?" It appears to me that it can. >> > >> >> >> Here is where you're problems start. The issue is that the signal *prior >> to being split* can go 20km if you're splitting it 32 ways (or less) or >> 10km if you're doing a 64 way split. AFTER the splitter you have a MAX >> radius of about 1 mile from the splitter. >> >> Here is a good document that describes the problem in some detail: >> >> http://www.ofsoptics.com/press_room/media-pdfs/FTTH-Prism-0909.pdf >> >> >> Also, here is a proposed spec that would allow for longer runs post >> splitter with some background on why it can't work in today's GPON >> deployments. >> >> http://www.ericsson.com/il/res/thecompany/docs/publications/ericsson_review/2008/3_PON.pdf >> >> -- >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> > > From frnkblk at iname.com Fri Feb 1 22:14:17 2013 From: frnkblk at iname.com (Frank Bulk (iname.com)) Date: Fri, 1 Feb 2013 16:14:17 -0600 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: <23294966.4289.1359597671189.JavaMail.root@benjamin.baylink.com> References: <51089FDE.507@vaxination.ca> <23294966.4289.1359597671189.JavaMail.root@benjamin.baylink.com> Message-ID: <000701ce00c9$7a443540$6ecc9fc0$@iname.com> What's missing in this dialogue is the video component of an offering. Many customers like a triple (or quad) play because the price points are reasonable comparable to getting unbundled pricing from more than one provider, and they have just throat to choke and bill to pay. But few IP TV providers will claim good profitability. And I don't believe any vendor has ActiveE and RFoG going down one strand. Frank -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Wednesday, January 30, 2013 8:01 PM To: NANOG Subject: Re: Will wholesale-only muni actually bring the boys to your yard? ----- Original Message ----- > From: "Jean-Francois Mezei" > A good layer 2 deployment can support DHCP or PPPoE and thus be > compatible with incumbents infrastructure. However, a good layer2 > deployment won't have "RFoG" support and will prefer IPTV over the data > channel (the australian model supports multicast). So cable companies > without IPTV services may be at a disadvantage. I think this depends on what handoffs my TE can provide at the customer prem. > In Canada, Rogers (cableco) has announced that they plan to go all > IPTV instead of conventional TV channels. Well, the MythTV people will be happy to hear that. Or they would, if the content people would quit holding a gun to the heads of the transport people. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jfmezei_nanog at vaxination.ca Fri Feb 1 22:17:26 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 01 Feb 2013 17:17:26 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> Message-ID: <510C3EF6.5060905@vaxination.ca> On 13-02-01 16:03, Jason Baugher wrote: > The reason to push splitters towards the customer end is financial, not > technical. It also has to do with existing fibre infrastructure. If a Telco has already adopted a "fibre to a node" philosophy, then it has a;ready installed a limited number of strands between CO and many neighbouhoods. It makes sense to standardise on one technology. And if that technology, because it is used by many, ends up much cheaper due to economies of scale, it makes sense to adopt it. And remember that it isn't just the cable. You need to consider the OLT cards. An OLT card can often support a few GPON systems each passing 32 homes. With 1 strand per home, you take up one port per home served. (possibly per home passed depending on deployment philosophy). So you end up needing far more cards in an OLT to serve the same number of people. More $$$ needed. GPON isn't suited for trunks. But for last mile, is it really so bad ? 2.mumble gpbs of capacity for 32 homes yields 62mbps of sustained download for each home. (assuming you have 32 homes conected and using it at same time) If you have multicast and everyone is watching superbowl at same time, you're talking up very little bandwidth on that 2.mumble GPON link. From bygg at cafax.se Fri Feb 1 23:33:40 2013 From: bygg at cafax.se (Johnny Eriksson) Date: Fri, 1 Feb 2013 23:33:40 WET Subject: Muni fiber: L1 or L2? In-Reply-To: Your message of Fri, 1 Feb 2013 13:59:54 -0800 Message-ID: Owen DeLong wrote: > Nope The power going into each fiber out of the splitter is 1/16th > that of what went into the splitter. ... which is 12 dB loss. > Yes, your total in-line loss is still 10km, but you are forgetting > about the fact that you lost 15/16th of the power effectively going > to the fiber when you went through the splitter (in addition to the > splitter loss itself). > > So: CO Based splitter: > > Each customer gets (IN - 16dB - (10km x .26db))/32 Each customer gets IN - ~0dB - 12 dB - 2.6 dB = IN - 14.6 dB. > Splitter at 9km: > > Each customer gets (IN - (9km x .26dB) -16db)/32-(1km x .26db) Each customer gets IN - 2.34 dB - 12 dB - 0.26 dB = IN - 14.6 dB. > If we use 5dBm as our input, this works out: > > CO: (5db - 16db - (10km x .26db) / 32 > /32 is effectively -15 db (-3db = ? power, 32 = 2^5) > Substituting: (5db - 16db - 2.6db) -15db = -28.6db to each customer. > > Spitter at 9km: (5db - (9km x .26db) -16db)/32-(1km x .26db) > Substituting: (5db - 2.34db -16db)-15db-.26db = -28.08db to each customer > > So there is a difference, but it seems rather negligible now that I've > run the numbers. > > However, it's entirely possible that I got this wrong somewhere, > so I invite those more expert than I to review the calculations > and tell me what I got wrong. You are multiplying logarithmic values. > Owen --Johnny From jason at thebaughers.com Fri Feb 1 22:38:18 2013 From: jason at thebaughers.com (Jason Baugher) Date: Fri, 1 Feb 2013 16:38:18 -0600 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: <000701ce00c9$7a443540$6ecc9fc0$@iname.com> References: <51089FDE.507@vaxination.ca> <23294966.4289.1359597671189.JavaMail.root@benjamin.baylink.com> <000701ce00c9$7a443540$6ecc9fc0$@iname.com> Message-ID: Management has asked us why we can't do RF overlay on our AE system. :) We've had to explain a few times why that would be too expensive even if it were available because of the high cost of the amps/splitters/combiners to insert 1550nm onto every AE fiber. On Fri, Feb 1, 2013 at 4:14 PM, Frank Bulk (iname.com) wrote: > What's missing in this dialogue is the video component of an offering. > Many customers like a triple (or quad) play because the price points are > reasonable comparable to getting unbundled pricing from more than one > provider, and they have just throat to choke and bill to pay. > > But few IP TV providers will claim good profitability. And I don't > believe any vendor has ActiveE and RFoG going down one strand. > > Frank > > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: Wednesday, January 30, 2013 8:01 PM > To: NANOG > Subject: Re: Will wholesale-only muni actually bring the boys to your yard? > > ----- Original Message ----- > > From: "Jean-Francois Mezei" > > > > > A good layer 2 deployment can support DHCP or PPPoE and thus be > > compatible with incumbents infrastructure. However, a good layer2 > > deployment won't have "RFoG" support and will prefer IPTV over the data > > channel (the australian model supports multicast). So cable companies > > without IPTV services may be at a disadvantage. > > I think this depends on what handoffs my TE can provide at the customer > prem. > > > In Canada, Rogers (cableco) has announced that they plan to go all > > IPTV instead of conventional TV channels. > > Well, the MythTV people will be happy to hear that. > > Or they would, if the content people would quit holding a gun to the > heads of the transport people. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > > > > From frnkblk at iname.com Fri Feb 1 22:48:42 2013 From: frnkblk at iname.com (Frank Bulk (iname.com)) Date: Fri, 1 Feb 2013 16:48:42 -0600 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: References: <51089FDE.507@vaxination.ca> <23294966.4289.1359597671189.JavaMail.root@benjamin.baylink.com> <000701ce00c9$7a443540$6ecc9fc0$@iname.com> Message-ID: <001501ce00ce$491551c0$db3ff540$@iname.com> IIRC, there is some issue with bleedover of either the forward or return (optically modulated) RF wavelength with the data wavelength. Perhaps with better lasers this could be overcome in the future. Frank From: Jason Baugher [mailto:jason at thebaughers.com] Sent: Friday, February 01, 2013 4:38 PM To: Frank Bulk (iname.com) Cc: Jay Ashworth; NANOG Subject: Re: Will wholesale-only muni actually bring the boys to your yard? Management has asked us why we can't do RF overlay on our AE system. :) We've had to explain a few times why that would be too expensive even if it were available because of the high cost of the amps/splitters/combiners to insert 1550nm onto every AE fiber. On Fri, Feb 1, 2013 at 4:14 PM, Frank Bulk (iname.com) wrote: What's missing in this dialogue is the video component of an offering. Many customers like a triple (or quad) play because the price points are reasonable comparable to getting unbundled pricing from more than one provider, and they have just throat to choke and bill to pay. But few IP TV providers will claim good profitability. And I don't believe any vendor has ActiveE and RFoG going down one strand. Frank -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Wednesday, January 30, 2013 8:01 PM To: NANOG Subject: Re: Will wholesale-only muni actually bring the boys to your yard? ----- Original Message ----- > From: "Jean-Francois Mezei" > A good layer 2 deployment can support DHCP or PPPoE and thus be > compatible with incumbents infrastructure. However, a good layer2 > deployment won't have "RFoG" support and will prefer IPTV over the data > channel (the australian model supports multicast). So cable companies > without IPTV services may be at a disadvantage. I think this depends on what handoffs my TE can provide at the customer prem. > In Canada, Rogers (cableco) has announced that they plan to go all > IPTV instead of conventional TV channels. Well, the MythTV people will be happy to hear that. Or they would, if the content people would quit holding a gun to the heads of the transport people. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From frnkblk at iname.com Fri Feb 1 22:49:43 2013 From: frnkblk at iname.com (Frank Bulk (iname.com)) Date: Fri, 1 Feb 2013 16:49:43 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> Message-ID: <001a01ce00ce$6d230e40$47692ac0$@iname.com> Fletcher: Many rural LECs are homerunning their fiber back to the CO, such that the optical splitters are only in the CO. It gives them one management point, the highest possible efficiency (you can maximize any every splitter and therefore PON) and a pathway to ActiveE. Frank -----Original Message----- From: Fletcher Kittredge [mailto:fkittred at gwi.net] Sent: Thursday, January 31, 2013 3:58 PM To: Owen DeLong Cc: NANOG Subject: Re: Muni fiber: L1 or L2? On Thu, Jan 31, 2013 at 4:36 PM, Owen DeLong wrote: > If you have an MMR where all of the customers come together, then you > can cross-connect all of $PROVIDER_1's customers to a splitter provided > by $PROVIDER_1 and cross connect all of $PROVIDER_2's customers to > a splitter provided by $PROVIDER_2, etc. > > If the splitter is out in the neighborhood, then $PROVIDER_1 and > $PROVIDER_2 > and... all need to build out to every neighborhood. > > If you have the splitter next to the PON gear instead of next to the > subscribers, > then you remove the relevance of the inability to connect a splitter to > multiple > OLTs. The splitter becomes the provider interface to the open fiber plant Owen; Interesting. Do you then lose the cost advantage because you need home run fiber back to the MMR? Do you have examples of plants built with this architecture (I know of one such plant, but I am hoping you will turn up more examples.) regards, Fletcher -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From jason at thebaughers.com Fri Feb 1 23:03:43 2013 From: jason at thebaughers.com (Jason Baugher) Date: Fri, 1 Feb 2013 17:03:43 -0600 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: <001501ce00ce$491551c0$db3ff540$@iname.com> References: <51089FDE.507@vaxination.ca> <23294966.4289.1359597671189.JavaMail.root@benjamin.baylink.com> <000701ce00c9$7a443540$6ecc9fc0$@iname.com> <001501ce00ce$491551c0$db3ff540$@iname.com> Message-ID: For us, it would be the economics of the whole thing. When a 16x19.5 EDFA runs around $20k, it's much more cost effective to combine 1550nm onto 16 PON's than onto 16 AE runs. Unless the equipment costs were to fall drastically, there's no way it would ever fly. On Fri, Feb 1, 2013 at 4:48 PM, Frank Bulk (iname.com) wrote: > IIRC, there is some issue with bleedover of either the forward or return > (optically modulated) RF wavelength with the data wavelength. Perhaps with > better lasers this could be overcome in the future.**** > > ** ** > > Frank**** > > ** ** > > *From:* Jason Baugher [mailto:jason at thebaughers.com] > *Sent:* Friday, February 01, 2013 4:38 PM > *To:* Frank Bulk (iname.com) > *Cc:* Jay Ashworth; NANOG > > *Subject:* Re: Will wholesale-only muni actually bring the boys to your > yard?**** > > ** ** > > Management has asked us why we can't do RF overlay on our AE system. :) > We've had to explain a few times why that would be too expensive even if it > were available because of the high cost of the amps/splitters/combiners to > insert 1550nm onto every AE fiber.**** > > ** ** > > On Fri, Feb 1, 2013 at 4:14 PM, Frank Bulk (iname.com) > wrote:**** > > What's missing in this dialogue is the video component of an offering. > Many customers like a triple (or quad) play because the price points are > reasonable comparable to getting unbundled pricing from more than one > provider, and they have just throat to choke and bill to pay. > > But few IP TV providers will claim good profitability. And I don't > believe any vendor has ActiveE and RFoG going down one strand. > > Frank > > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: Wednesday, January 30, 2013 8:01 PM > To: NANOG > Subject: Re: Will wholesale-only muni actually bring the boys to your yard? > > ----- Original Message ----- > > From: "Jean-Francois Mezei" > > > > > A good layer 2 deployment can support DHCP or PPPoE and thus be > > compatible with incumbents infrastructure. However, a good layer2 > > deployment won't have "RFoG" support and will prefer IPTV over the data > > channel (the australian model supports multicast). So cable companies > > without IPTV services may be at a disadvantage. > > I think this depends on what handoffs my TE can provide at the customer > prem. > > > In Canada, Rogers (cableco) has announced that they plan to go all > > IPTV instead of conventional TV channels. > > Well, the MythTV people will be happy to hear that. > > Or they would, if the content people would quit holding a gun to the > heads of the transport people. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > > > **** > > ** ** > From henri.hannula at msoy.fi Fri Feb 1 22:59:46 2013 From: henri.hannula at msoy.fi (Henri Hannula) Date: Fri, 1 Feb 2013 22:59:46 +0000 Subject: VS: Muni fiber: L1 or L2? In-Reply-To: <569198EE-5E0D-4D2B-A1DA-33057148BCC4@delong.com> References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <569198EE-5E0D-4D2B-A1DA-33057148BCC4@delong.com> Message-ID: <14EB28242B5FC84E97BF638994426B58283457@posti2.msoy.local> You propably calculated the second one (5 - 2.34 -16)-15 + 0.26 since you got -28.08 (5 - 16 - 2.6) - 15 = -28.6 (5 - 2.34 - 16) - 15 - 0.26 = -28.6 -Hena -----Alkuper?inen viesti----- L?hett?j?: Owen DeLong [mailto:owen at delong.com] L?hetetty: 2. helmikuuta 2013 0:00 Vastaanottaja: Jason Baugher Kopio: NANOG Aihe: Re: Muni fiber: L1 or L2? On Feb 1, 2013, at 1:43 PM, Jason Baugher wrote: > It's still a 23dB loss for each customer from the CO to the ONT. > > I have an OLT that launches at +5dBm. At 1490nm, I should see about a .26dB loss per km. My 1x32 splitter is going to add about 16dB more loss. Assuming we ignore connector losses, and also assume that the customer is 10km away: > Nope. The power going into each fiber out of the splitter is 1/16th that of what went into the splitter. Yes, your total in-line loss is still 10km, but you are forgetting about the fact that you lost 15/16th of the power effectively going to the fiber when you went through the splitter (in addition to the splitter loss itself). So: CO Based splitter: Each customer gets (IN - 16dB - (10km x .26db))/32 Splitter at 9km: Each customer gets (IN - (9km x .26dB) -16db)/32-(1km x .26db) If we use 5dBm as our input, this works out: CO: (5db - 16db - (10km x .26db) / 32 /32 is effectively -15 db (-3db = ? power, 32 = 2^5) Substituting: (5db - 16db - 2.6db) -15db = -28.6db to each customer. Spitter at 9km: (5db - (9km x .26db) -16db)/32-(1km x .26db) Substituting: (5db - 2.34db -16db)-15db-.26db = -28.08db to each customer So there is a difference, but it seems rather negligible now that I've run the numbers. However, it's entirely possible that I got this wrong somewhere, so I invite those more expert than I to review the calculations and tell me what I got wrong. Owen > CO-based splitter: > +5dBm - 16dB - (10km x .26dB) = -13.6 > > Splitter at 9km: > +5dBm - (9km x .26dB) - 16dB - (1km x .26dB) = -13.6 > > > If someone can explain why this math would be wrong, I'd love to hear it and I'd be happy to run it past our vendor to see if they agree. > > > On Fri, Feb 1, 2013 at 3:16 PM, Owen DeLong wrote: > Actually, this is an issue. I should have seen it. > > > You have 3 loss components. Power out = (Power in - loss to splitter - > splitter loss) / nOut - loss-to-customer > > So, if the loss to the splitter is 3db and you have 20db (effective > 320db on a 16x split) loss on each customer link, that's a radically > worse proposition than 20db loss to the splitter and 3db loss to each customer (which is effectively 48db loss on a 16x split). > > It's still do-able, but you either need amplifier(s) or very short distances between the customer and the MMR. > > Given this consideration, I think the situation can still be addressed. > > Put the splitters in the B-Box and allow for the possibility that each > subscriber can be XC to either a splitter or an upstream dedicated > fiber. The provider side of each splitter would be connected to an upstream fiber to the MMR. > > So, each B-Box contains however many splitters are required and each > splitter is connected upstream to a single provider, but you can still have multiple competitive providers in the MMR. > > This setup could support both PON and Ethernet as well as other future technologies. > > Owen > > On Feb 1, 2013, at 1:04 PM, Jason Baugher wrote: > >> I should clarify: Distance x loss/km + splitter loss. = link loss. >> >> >> On Fri, Feb 1, 2013 at 3:03 PM, Jason Baugher wrote: >> I disagree. Loss is loss, regardless of where the splitter is placed in the equation. Distance x loss + splitter insertion loss = total loss for purposes of link budget calculation. >> >> The reason to push splitters towards the customer end is financial, not technical. >> >> >> On Fri, Feb 1, 2013 at 2:29 PM, Scott Helms wrote: >> Owen, >> >> You're basing your math off of some incorrect assumptions about PON. >> I'm actually sympathetic to your goal, but it simply can't work the >> way you're describing it in a PON network. Also, please don't base >> logic for open access on meet me rooms, this works in colo spaces and >> carrier hotels but doesn't in broadband deployments because of >> economics. If you want to champion this worthy goal you've got to >> accept that economics is a huge reason why this hasn't happened in >> the US and is disappearing where it has happened globally. >> >> >> > Bottom line, you've got OLT -> FIBER(of length n) -> splitter -> >> > fiber-drops to each house -> ONT. >> > >> >> So far you're correct. >> >> >> > >> > All I'm proposing is making n really short and making "fiber-drops >> > to each house" really long. >> > I'm not proposing changing the fundamental architecture. Yes, I >> > recognize this changes the economics and may well make PON less >> > attractive than other alternatives. I don't care. That's not a >> > primary concern. The question is "can PON be made to work in this environment?" It appears to me that it can. >> > >> >> >> Here is where you're problems start. The issue is that the signal >> *prior to being split* can go 20km if you're splitting it 32 ways (or >> less) or 10km if you're doing a 64 way split. AFTER the splitter you >> have a MAX radius of about 1 mile from the splitter. >> >> Here is a good document that describes the problem in some detail: >> >> http://www.ofsoptics.com/press_room/media-pdfs/FTTH-Prism-0909.pdf >> >> >> Also, here is a proposed spec that would allow for longer runs post >> splitter with some background on why it can't work in today's GPON >> deployments. >> >> http://www.ericsson.com/il/res/thecompany/docs/publications/ericsson_ >> review/2008/3_PON.pdf >> >> -- >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> > > From bonomi at mail.r-bonomi.com Fri Feb 1 23:10:03 2013 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 1 Feb 2013 17:10:03 -0600 (CST) Subject: Muni fiber: L1 or L2? In-Reply-To: <569198EE-5E0D-4D2B-A1DA-33057148BCC4@delong.com> Message-ID: <201302012310.r11NA3Tb001481@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Fri Feb 1 16:11:17 2013 > Subject: Re: Muni fiber: L1 or L2? > From: Owen DeLong > Date: Fri, 1 Feb 2013 13:59:54 -0800 > To: Jason Baugher > Cc: NANOG > > > On Feb 1, 2013, at 1:43 PM, Jason Baugher wrote: > > > It's still a 23dB loss for each customer from the CO to the ONT. > > > > I have an OLT that launches at +5dBm. At 1490nm, I should see about a > > .26dB loss per km. My 1x32 splitter is going to add about 16dB more > > loss. Assuming we ignore connector losses, and also assume that the > > customer is 10km away: > > > > Nope The power going into each fiber out of the splitter is 1/16th that > of what went into the splitter. > > Yes, your total in-line loss is still 10km, but you are forgetting about > the fact that you lost 15/16th of the power effectively going to the > fiber when you went through the splitter (in addition to the splitter > loss itself). > > So: CO Based splitter: > > Each customer gets (IN - 16dB - (10km x .26db))/32 Wrong. The 'loss' of the splitter _includes_ the division into multiple outputs. 16dB insertion loss for a 16-way splitter is 12dB for the division and 4dB of 'internal' (less than theoretically perfect) losses. > Splitter at 9km: > > Each customer gets (IN - (9km x .26dB) -16db)/32-(1km x .26db) > > If we use 5dBm as our input, this works out: > > CO: (5db - 16db - (10km x .26db) / 32 > /32 is effectively -15 db (-3db = power, 32 = 2^5) > Substituting: (5db - 16db - 2.6db) -15db = -28.6db to each customer. > > Spitter at 9km: (5db - (9km x .26db) -16db)/32-(1km x .26db) > Substituting: (5db - 2.34db -16db)-15db-.26db = -28.08db to each customer > > So there is a difference, but it seems rather negligible now that I've > run the numbers. Strange, I get -28.6 for both your calculations -- 'bc' output: (5-16-2.6)-15 -28.6 (5-2.34-16)-15-.26 -28.60 > However, it's entirely possible that I got this wrong somewhere, so I > invite those more expert than I to review the calculations and tell me > what I got wrong. a) arithmetic error. b) 'double-counting' splitter losses. Real-world for a 32-way splitter is around 20db -- 15db for the division, and 5db for the 'internal' losses. giving: C.O.: 5-20-2.6 = -17.4 db @9km: 5-2.34-20-.26 = -17.4 db From jra at baylink.com Fri Feb 1 23:46:28 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 1 Feb 2013 18:46:28 -0500 (EST) Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: <000701ce00c9$7a443540$6ecc9fc0$@iname.com> Message-ID: <16918201.4431.1359762388817.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Frank Bulk (iname.com)" > What's missing in this dialogue is the video component of an offering. > Many customers like a triple (or quad) play because the price points > are reasonable comparable to getting unbundled pricing from more than > one provider, and they have just throat to choke and bill to pay. > > But few IP TV providers will claim good profitability. And I don't > believe any vendor has ActiveE and RFoG going down one strand. Not an issue I'd missed. The suggestion of, I believe it was Owen, to run GPON over the home-run fiber, with the splitters at the headend, solves that problem rather nicely, though; the L3+ provider can do whatever they like; if they need GPON to deliver, they (or we) can provision the splitters, and patch through them, back to whatever OLT eqiuvalent they deliver from. In fact, I need to find out the pricing class of the GPON splitters; given what I gather the port count difference is between the line cards on, say, the Calix E7, I might do my own L2 service that way, since the Calix ONTs will take either. I'm working up a what, how and why writeup on this, given my personal set of tradeoffs; I hope to get it up by morning, so no one feels left out on the last Whacky Weekend before the conference (which, dammital, I can't attend, even though it's in Florida for the first time in a decade...). Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Fri Feb 1 23:57:31 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 1 Feb 2013 18:57:31 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: <201302010036.AAA08295@sunf10.rd.bbc.co.uk> Message-ID: <11267411.4435.1359763051231.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brandon Butterworth" > 3. no home run fibres means no competitors running their own > GPON or Ethernet. Why invest in making it easier for the > competition Because I don't have any competitors; I *am the municipality*. All the possible competitors *are my customers*, at what amounts to a tarriffed rate, whether for L1, or (more expensively) L2, assuming my L2 limitations are acceptable to them. My goal is to do the trenching once, and never again. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From bicknell at ufp.org Sat Feb 2 00:43:56 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 1 Feb 2013 16:43:56 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> Message-ID: <20130202004356.GA77024@ussenterprise.ufp.org> In a message written on Fri, Feb 01, 2013 at 03:29:32PM -0500, Scott Helms wrote: > You're basing your math off of some incorrect assumptions about PON. I'm I'd like to know more about the PON limitations, while I understand the 10,000 foot view, some of the rubber hitting the road issues are a mystery to me. My limited understanding is that fiber really has two parameters, loss and modal disperson. For most of the applications folks on this mailing list deal with loss is the big issue, and modal disperson is something that can be ignored. However for for many of the more interesting applications involving splitters, super long distances, or passive amplifiers modal disperson is actually a much larger issue. I would imagine if you put X light into a 32:1 splitter, each leg would leg 1/32nd of the light (acutally a bit less, no doubt), but I have an inking the disperson characteristics would be much, much worse. Is this the cause of the shorter distance on the downstream GPON channel, or does it have to do more with the upstream GPON channel, which is an odd kettle of fish going through a splitter "backwards"? If it is the issue, have any vendors tried disperson compensation with any success? The only place PON made any sense to me was extreme rural areas. If you could go 20km to a splitter and then hit 32 homes ~1km away (52km fiber pair length total), that was a win. If the homes are 2km from the CO, 32 pair (64km fiber pair length total) of home runs was cheaper than the savings on fiber, and then the cost of GPON splitters and equipment. I'm trying to figure out if my assessment is correct or not... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From owen at delong.com Sat Feb 2 03:52:30 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Feb 2013 19:52:30 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: <510C3EF6.5060905@vaxination.ca> References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <510C3EF6.5060905@vaxination.ca> Message-ID: <0D7538BB-C96D-4030-8C4C-0CD2282922E3@delong.com> On Feb 1, 2013, at 14:17 , Jean-Francois Mezei wrote: > On 13-02-01 16:03, Jason Baugher wrote: > >> The reason to push splitters towards the customer end is financial, not >> technical. > > It also has to do with existing fibre infrastructure. If a Telco has > already adopted a "fibre to a node" philosophy, then it has a;ready > installed a limited number of strands between CO and many neighbouhoods. Since the discussion here is about muni fiber capabilities and ideal greenfield plant designs, existing fiber is irrelevant to the discussion at hand. > It makes sense to standardise on one technology. And if that technology, > because it is used by many, ends up much cheaper due to economies of > scale, it makes sense to adopt it. Only if you're a single vendor looking to provide a single-vendor solution. That's really not what this conversation is about, IMHO. In fact, that's a pretty good summary of the situation we're trying to fix. > And remember that it isn't just the cable. You need to consider the OLT > cards. An OLT card can often support a few GPON systems each passing 32 > homes. Not sure why this matters... > With 1 strand per home, you take up one port per home served. (possibly > per home passed depending on deployment philosophy). So you end up > needing far more cards in an OLT to serve the same number of people. > More $$$ needed. Uh, no... That's not what we're talking about. We're talking about still using splitters, but, putting the splitter next to the OLT instead of near the ONT end. That's all. > GPON isn't suited for trunks. But for last mile, is it really so bad ? Yes... Because... > 2.mumble gpbs of capacity for 32 homes yields 62mbps of sustained > download for each home. (assuming you have 32 homes conected and using > it at same time) Great by todays standards, but likely to be obsoleted within 10 years. Given the nearly 100 year old nature of some copper plants, I'd like to see us start building fiber plants in a way that doesn't lock us into a particular technology choice constrained to the economic tradeoffs that are relevant today and may be completely different in as little as 5 years. > If you have multicast and everyone is watching superbowl at same time, > you're talking up very little bandwidth on that 2.mumble GPON link. Meh. Since everyone seems to want to be able to pause, rewind, etc., multicast doesn't tend to happen so much even in the IPTV world these days. Owen From owen at delong.com Sat Feb 2 03:54:24 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Feb 2013 19:54:24 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: <14EB28242B5FC84E97BF638994426B58283457@posti2.msoy.local> References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <569198EE-5E0D-4D2B-A1DA-33057148BCC4@delong.com> <14EB28242B5FC84E97BF638994426B58283457@posti2.msoy.local> Message-ID: <5A739659-4559-4E62-9F97-7A6D636313C3@delong.com> OK... Like Einstein, math is not my strong suit. Unfortunately, I don't have his prowess with physics, either. Owen On Feb 1, 2013, at 14:59 , Henri Hannula wrote: > You propably calculated the second one (5 - 2.34 -16)-15 + 0.26 since you got -28.08 > > (5 - 16 - 2.6) - 15 = -28.6 > (5 - 2.34 - 16) - 15 - 0.26 = -28.6 > > > -Hena > > -----Alkuper?inen viesti----- > L?hett?j?: Owen DeLong [mailto:owen at delong.com] > L?hetetty: 2. helmikuuta 2013 0:00 > Vastaanottaja: Jason Baugher > Kopio: NANOG > Aihe: Re: Muni fiber: L1 or L2? > > > On Feb 1, 2013, at 1:43 PM, Jason Baugher wrote: > >> It's still a 23dB loss for each customer from the CO to the ONT. >> >> I have an OLT that launches at +5dBm. At 1490nm, I should see about a .26dB loss per km. My 1x32 splitter is going to add about 16dB more loss. Assuming we ignore connector losses, and also assume that the customer is 10km away: >> > > Nope. The power going into each fiber out of the splitter is 1/16th that of what went into the splitter. > > Yes, your total in-line loss is still 10km, but you are forgetting about the fact that you lost 15/16th of the power effectively going to the fiber when you went through the splitter (in addition to the splitter loss itself). > > So: CO Based splitter: > > Each customer gets (IN - 16dB - (10km x .26db))/32 > > Splitter at 9km: > > Each customer gets (IN - (9km x .26dB) -16db)/32-(1km x .26db) > > If we use 5dBm as our input, this works out: > > CO: (5db - 16db - (10km x .26db) / 32 > /32 is effectively -15 db (-3db = ? power, 32 = 2^5) > Substituting: (5db - 16db - 2.6db) -15db = -28.6db to each customer. > > Spitter at 9km: (5db - (9km x .26db) -16db)/32-(1km x .26db) > Substituting: (5db - 2.34db -16db)-15db-.26db = -28.08db to each customer > > So there is a difference, but it seems rather negligible now that I've run the numbers. > > However, it's entirely possible that I got this wrong somewhere, so I invite those more expert than I to review the calculations and tell me what I got wrong. > > Owen > >> CO-based splitter: >> +5dBm - 16dB - (10km x .26dB) = -13.6 >> >> Splitter at 9km: >> +5dBm - (9km x .26dB) - 16dB - (1km x .26dB) = -13.6 >> >> >> If someone can explain why this math would be wrong, I'd love to hear it and I'd be happy to run it past our vendor to see if they agree. >> >> >> On Fri, Feb 1, 2013 at 3:16 PM, Owen DeLong wrote: >> Actually, this is an issue. I should have seen it. >> >> >> You have 3 loss components. Power out = (Power in - loss to splitter - >> splitter loss) / nOut - loss-to-customer >> >> So, if the loss to the splitter is 3db and you have 20db (effective >> 320db on a 16x split) loss on each customer link, that's a radically >> worse proposition than 20db loss to the splitter and 3db loss to each customer (which is effectively 48db loss on a 16x split). >> >> It's still do-able, but you either need amplifier(s) or very short distances between the customer and the MMR. >> >> Given this consideration, I think the situation can still be addressed. >> >> Put the splitters in the B-Box and allow for the possibility that each >> subscriber can be XC to either a splitter or an upstream dedicated >> fiber. The provider side of each splitter would be connected to an upstream fiber to the MMR. >> >> So, each B-Box contains however many splitters are required and each >> splitter is connected upstream to a single provider, but you can still have multiple competitive providers in the MMR. >> >> This setup could support both PON and Ethernet as well as other future technologies. >> >> Owen >> >> On Feb 1, 2013, at 1:04 PM, Jason Baugher wrote: >> >>> I should clarify: Distance x loss/km + splitter loss. = link loss. >>> >>> >>> On Fri, Feb 1, 2013 at 3:03 PM, Jason Baugher wrote: >>> I disagree. Loss is loss, regardless of where the splitter is placed in the equation. Distance x loss + splitter insertion loss = total loss for purposes of link budget calculation. >>> >>> The reason to push splitters towards the customer end is financial, not technical. >>> >>> >>> On Fri, Feb 1, 2013 at 2:29 PM, Scott Helms wrote: >>> Owen, >>> >>> You're basing your math off of some incorrect assumptions about PON. >>> I'm actually sympathetic to your goal, but it simply can't work the >>> way you're describing it in a PON network. Also, please don't base >>> logic for open access on meet me rooms, this works in colo spaces and >>> carrier hotels but doesn't in broadband deployments because of >>> economics. If you want to champion this worthy goal you've got to >>> accept that economics is a huge reason why this hasn't happened in >>> the US and is disappearing where it has happened globally. >>> >>> >>>> Bottom line, you've got OLT -> FIBER(of length n) -> splitter -> >>>> fiber-drops to each house -> ONT. >>>> >>> >>> So far you're correct. >>> >>> >>>> >>>> All I'm proposing is making n really short and making "fiber-drops >>>> to each house" really long. >>>> I'm not proposing changing the fundamental architecture. Yes, I >>>> recognize this changes the economics and may well make PON less >>>> attractive than other alternatives. I don't care. That's not a >>>> primary concern. The question is "can PON be made to work in this environment?" It appears to me that it can. >>>> >>> >>> >>> Here is where you're problems start. The issue is that the signal >>> *prior to being split* can go 20km if you're splitting it 32 ways (or >>> less) or 10km if you're doing a 64 way split. AFTER the splitter you >>> have a MAX radius of about 1 mile from the splitter. >>> >>> Here is a good document that describes the problem in some detail: >>> >>> http://www.ofsoptics.com/press_room/media-pdfs/FTTH-Prism-0909.pdf >>> >>> >>> Also, here is a proposed spec that would allow for longer runs post >>> splitter with some background on why it can't work in today's GPON >>> deployments. >>> >>> http://www.ericsson.com/il/res/thecompany/docs/publications/ericsson_ >>> review/2008/3_PON.pdf >>> >>> -- >>> Scott Helms >>> Vice President of Technology >>> ZCorum >>> (678) 507-5000 >>> -------------------------------- >>> http://twitter.com/kscotthelms >>> -------------------------------- >>> >>> >> >> > > From george.herbert at gmail.com Sat Feb 2 04:17:01 2013 From: george.herbert at gmail.com (George Herbert) Date: Fri, 1 Feb 2013 20:17:01 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: <5A739659-4559-4E62-9F97-7A6D636313C3@delong.com> References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <569198EE-5E0D-4D2B-A1DA-33057148BCC4@delong.com> <14EB28242B5FC84E97BF638994426B58283457@posti2.msoy.local> <5A739659-4559-4E62-9F97-7A6D636313C3@delong.com> Message-ID: On Fri, Feb 1, 2013 at 7:54 PM, Owen DeLong wrote: > OK... Like Einstein, math is not my strong suit. > > Unfortunately, I don't have his prowess with physics, either. > > Owen A bit here, a bit there... Hey, dB is a plural of Bits! -- -george william herbert george.herbert at gmail.com From george.herbert at gmail.com Sat Feb 2 04:59:00 2013 From: george.herbert at gmail.com (George Herbert) Date: Fri, 1 Feb 2013 20:59:00 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <569198EE-5E0D-4D2B-A1DA-33057148BCC4@delong.com> <14EB28242B5FC84E97BF638994426B58283457@posti2.msoy.local> <5A739659-4559-4E62-9F97-7A6D636313C3@delong.com> Message-ID: Ok, serious question - How is GPON's downstream AES encryption keying handled? -- -george william herbert george.herbert at gmail.com From jfmezei_nanog at vaxination.ca Sat Feb 2 05:22:07 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 02 Feb 2013 00:22:07 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <0D7538BB-C96D-4030-8C4C-0CD2282922E3@delong.com> References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <510C3EF6.5060905@vaxination.ca> <0D7538BB-C96D-4030-8C4C-0CD2282922E3@delong.com> Message-ID: <510CA27F.7050202@vaxination.ca> On 13-02-01 22:52, Owen DeLong wrote: > Since the discussion here is about muni fiber capabilities and ideal greenfield > plant designs, existing fiber is irrelevant to the discussion at hand. Not so irrelevant. If the municipality wishes to attract as many competitive ISPs as possible, it wants to build a "standard" last mile that ISPs can easily interface to. One which is compatible with other FTTH systems. Currently, the standard is GPON (even though there are many variations to the theme). Sone may say that having L1 service with each ISP having their OLT with splitters at the CO is an advantage. It also means that each ISP has to have its own ONTs in homes and they can all choose different configs for OLTs and the light in the fibre. Greater flexibility to differentiate between ISPs. (one may choose RFoG for TV with DOCSIS for data while the other is an all data link with IPTV.) But for an end user, switching ISPs would mean switching the CPE equipment too since the ONT installed by ISP-1 may not be compatible with OLT used by ISP-2. Requiring an ISP to have its own OLT at the CO with its own splitter also raises startup costs and reduces the chances of having competitive ISP environment. Providing L2 service means that ISPs connect to a municipal OLT, so they do not have to purchase OLTs and bother with splitters. At that point, it si simpler and cheaper to deploy splitters in neighbouhoods. It also reduces number of splices. When you do 1:1, you may have a big cable with lots of strands leaving the CO, but you'll have a JWI in neighbouhood where you cross connect the strands from CO to the strand that uses the pre-fab cable to the backyards of homes served. So in all the calculations made on dB loss, the number of splices was not factored in. You're not going to get a continuous cable from the CO to the telephone pole behind a home. If you put the splitter at the CO you get the losses from the splitter, and then losses from a splice at the neighbouhood where trunk from CO connects to cables that runs through backyards. When you put the splitter in the neighbouhood, it performs both the splitting and the connection of the cable from CO to the backyards. So you eliminate one splice. From owen at delong.com Sat Feb 2 06:22:43 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Feb 2013 22:22:43 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: <510CA27F.7050202@vaxination.ca> References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <510C3EF6.5060905@vaxination.ca> <0D7538BB-C96D-4030-8C4C-0CD2282922E3@delong.com> <510CA27F.7050202@vaxination.ca> Message-ID: On Feb 1, 2013, at 21:22 , Jean-Francois Mezei wrote: > On 13-02-01 22:52, Owen DeLong wrote: > >> Since the discussion here is about muni fiber capabilities and ideal greenfield >> plant designs, existing fiber is irrelevant to the discussion at hand. > > Not so irrelevant. If the municipality wishes to attract as many > competitive ISPs as possible, it wants to build a "standard" last mile > that ISPs can easily interface to. One which is compatible with other > FTTH systems. Yes and no. As I said, I think it's more important to build a system that can accommodate as many different potential technologies as possible rather than to follow the conventional wisdom of the day developed by single-provider monopoly environments. > Currently, the standard is GPON (even though there are many variations > to the theme). Meh... Not in South Korea... The standard there is Gig-E to the home. > Sone may say that having L1 service with each ISP having their OLT with > splitters at the CO is an advantage. It also means that each ISP has to > have its own ONTs in homes and they can all choose different configs for > OLTs and the light in the fibre. Greater flexibility to differentiate > between ISPs. (one may choose RFoG for TV with DOCSIS for data while the > other is an all data link with IPTV.) Exactly. > But for an end user, switching ISPs would mean switching the CPE > equipment too since the ONT installed by ISP-1 may not be compatible > with OLT used by ISP-2. So? I don't see that as a problem. > Requiring an ISP to have its own OLT at the CO with its own splitter > also raises startup costs and reduces the chances of having competitive > ISP environment. Hence my suggestion that in environments where it may make sense to do so, the muni could offer an optional enhanced L2 service. In this case, the muni would supply OLTs, ONTs, and hand off the L3 work to the provider(s). > Providing L2 service means that ISPs connect to a municipal OLT, so they > do not have to purchase OLTs and bother with splitters. At that point, > it si simpler and cheaper to deploy splitters in neighbouhoods. It also > reduces number of splices. Which I advocate as an OPTIONAL additional service. > When you do 1:1, you may have a big cable with lots of strands leaving > the CO, but you'll have a JWI in neighbouhood where you cross connect > the strands from CO to the strand that uses the pre-fab cable to the > backyards of homes served. I'm not sure what your abbreviation "JWI" means. > So in all the calculations made on dB loss, the number of splices was > not factored in. You're not going to get a continuous cable from the CO > to the telephone pole behind a home. If you put the splitter at the CO > you get the losses from the splitter, and then losses from a splice at > the neighbouhood where trunk from CO connects to cables that runs > through backyards. Sure, but you get those same losses regardless of which side of the splitter they are on. > > When you put the splitter in the neighbouhood, it performs both the > splitting and the connection of the cable from CO to the backyards. So > you eliminate one splice. According to http://www.thefoa.org/tech/lossbudg.htm this is about 0.3db, so reduce the served radius by ~1km. I think I already allowed for that in proposing an 8km serving radius for 10km optics. Given that 48 Gig -> 2 10G switches are getting cheaper and cheaper (even in the managed variety) to the point where being able to deploy them would be about 1/10th the cost per port of an OLT, I'm not sure that GPON is necessarily the clear winner in a carrier neutral scenario. Put splitters in the neighborhood and don't build for home-runs, then you eliminate the ability to introduce new technologies. IMHO, that's a really bad bet at this point. Owen From eugen at leitl.org Sat Feb 2 10:19:55 2013 From: eugen at leitl.org (Eugen Leitl) Date: Sat, 2 Feb 2013 11:19:55 +0100 Subject: Muni fiber: L1 or L2? In-Reply-To: <20130202004356.GA77024@ussenterprise.ufp.org> References: <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> Message-ID: <20130202101955.GP6172@leitl.org> On Fri, Feb 01, 2013 at 04:43:56PM -0800, Leo Bicknell wrote: > The only place PON made any sense to me was extreme rural areas. > If you could go 20km to a splitter and then hit 32 homes ~1km away > (52km fiber pair length total), that was a win. If the homes are > 2km from the CO, 32 pair (64km fiber pair length total) of home > runs was cheaper than the savings on fiber, and then the cost of > GPON splitters and equipment. I'm trying to figure out if my assessment > is correct or not... Is there any specific reason why muni networks don't use 1-10 GBit fiber mesh, using L3 switches in DSLAMs on every street corner? From matt.addison at lists.evilgeni.us Sat Feb 2 14:19:08 2013 From: matt.addison at lists.evilgeni.us (Matt Addison) Date: Sat, 2 Feb 2013 09:19:08 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <0D7538BB-C96D-4030-8C4C-0CD2282922E3@delong.com> References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <510C3EF6.5060905@vaxination.ca> <0D7538BB-C96D-4030-8C4C-0CD2282922E3@delong.com> Message-ID: <-6711453542153148198@unknownmsgid> On Feb 1, 2013, at 22:54, Owen DeLong wrote: >> If you have multicast and everyone is watching superbowl at same time, >> you're talking up very little bandwidth on that 2.mumble GPON link. > > Meh. Since everyone seems to want to be able to pause, rewind, etc., > multicast doesn't tend to happen so much even in the IPTV world these > days. Most of the time this is handled with a sliding buffer on the DVR at the customer prem (TiVo time shifting style) unless you're talking VOD. On Feb 1, 2013, at 19:44, Leo Bicknell wrote: > My limited understanding is that fiber really has two parameters, > loss and modal disperson. For most of the applications folks on > this mailing list deal with loss is the big issue, and modal disperson > is something that can be ignored. However for for many of the more > interesting applications involving splitters, super long distances, > or passive amplifiers modal disperson is actually a much larger > issue. > > I would imagine if you put X light into a 32:1 splitter, each leg > would leg 1/32nd of the light (acutally a bit less, no doubt), but > I have an inking the disperson characteristics would be much, much > worse. > > Is this the cause of the shorter distance on the downstream GPON > channel, or does it have to do more with the upstream GPON channel, > which is an odd kettle of fish going through a splitter "backwards"? > If it is the issue, have any vendors tried disperson compensation with > any success? I'd expect dispersion to be dispersion, in my limited optical education I've only heard that this is influenced by distance, not power level, so the signal would disperse the same amount whether its 7km of trunk + 100m of drop, or 100m of trunk + 7km of drop. 1310 and 1410 aren't particularly close so no need to worry about CMD causing cross channel interference. Quick googling shows this isn't an issue in 2.5G GPON plants which have an 16000ps-nm CMD tolerance, but 10G (XGPON or whatever the latest name is) will only have an 1100ps-nm tolerance which might add up fast depending on the fiber in the ground (Anyone have any good references on common fiber CMD/PMD at different wavelengths? Most of the references I found were focused around 1550) How the receiver in a GPON would respond to rapidly shifting dispersion/power levels due to upstream TDMA isn't something I'm familiar with. You could compensate for the power level with attenuators, but if you needed DC on every customer that's going to get expensive quick unless you can do it on the trunk side just to get the worst offenders back into your receivers window. ~Matt From jra at baylink.com Sat Feb 2 15:36:28 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 10:36:28 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: <510CA27F.7050202@vaxination.ca> Message-ID: <7249088.4570.1359819388729.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jean-Francois Mezei" > On 13-02-01 22:52, Owen DeLong wrote: > > Since the discussion here is about muni fiber capabilities and ideal > > greenfield > > plant designs, existing fiber is irrelevant to the discussion at > > hand. > > Not so irrelevant. If the municipality wishes to attract as many > competitive ISPs as possible, it wants to build a "standard" last mile > that ISPs can easily interface to. One which is compatible with other > FTTH systems. > > Currently, the standard is GPON (even though there are many variations > to the theme). There is a certain amount of utility to the "we should provide something which incoming providers who are already revved up in a specific direction can work with easily" argument, yes. Assuming there really are no loss or dispersal problems with 'splitter at the MDF', this will serve; an incoming L3 provider would have to put the boxes in slightly different places than usual, but at least they'd be the same boxes. > Sone may say that having L1 service with each ISP having their OLT > with > splitters at the CO is an advantage. It also means that each ISP has > to > have its own ONTs in homes and they can all choose different configs > for > OLTs and the light in the fibre. Greater flexibility to differentiate > between ISPs. (one may choose RFoG for TV with DOCSIS for data while > the > other is an all data link with IPTV.) Correct; we say that. > But for an end user, switching ISPs would mean switching the CPE > equipment too since the ONT installed by ISP-1 may not be compatible > with OLT used by ISP-2. Sure, but that's already true, and that's not a problem I'm trying to optimize out, frankly. > Requiring an ISP to have its own OLT at the CO with its own splitter > also raises startup costs and reduces the chances of having > competitive ISP environment. See below. > Providing L2 service means that ISPs connect to a municipal OLT, so they > do not have to purchase OLTs and bother with splitters. At that point, > it si simpler and cheaper to deploy splitters in neighbouhoods. It > also reduces number of splices. Yes, and no, in that order. If you'd been following along all week, you would have seen that the OP (me :-) wants to do *both*; supply L1 service to providers or subscribers that want that, and L2 service for other providers who are willing to pay more per sub per month, but have less capital investment up front. > When you do 1:1, you may have a big cable with lots of strands leaving > the CO, but you'll have a JWI in neighbouhood where you cross connect > the strands from CO to the strand that uses the pre-fab cable to the > backyards of homes served. Sure. Just no splitter. > So in all the calculations made on dB loss, the number of splices was > not factored in. You're not going to get a continuous cable from the CO > to the telephone pole behind a home. If you put the splitter at the CO > you get the losses from the splitter, and then losses from a splice at > the neighbouhood where trunk from CO connects to cables that runs > through backyards. True. Why I'll be subbing the plant design to a company that does that every day of the year, instead of trying to do it myself. > When you put the splitter in the neighbouhood, it performs both the > splitting and the connection of the cable from CO to the backyards. So > you eliminate one splice. Yes, but everyone on a splitter must be backhauled to the same L1 provider, and putting splitters *in the outside plant* precludes any other type of L1 service, *ever*. So that's a non-starter. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From bross at pobox.com Sat Feb 2 15:51:43 2013 From: bross at pobox.com (Brandon Ross) Date: Sat, 2 Feb 2013 10:51:43 -0500 (EST) Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: <000701ce00c9$7a443540$6ecc9fc0$@iname.com> References: <51089FDE.507@vaxination.ca> <23294966.4289.1359597671189.JavaMail.root@benjamin.baylink.com> <000701ce00c9$7a443540$6ecc9fc0$@iname.com> Message-ID: On Fri, 1 Feb 2013, Frank Bulk (iname.com) wrote: > What's missing in this dialogue is the video component of an offering. > Many customers like a triple (or quad) play because the price points are > reasonable comparable to getting unbundled pricing from more than one > provider, and they have just throat to choke and bill to pay. I must be missing something here. Why would a triple play using IPTV and VOIP be unachievable in this model? -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From jra at baylink.com Sat Feb 2 16:13:30 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 11:13:30 -0500 (EST) Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: Message-ID: <30721194.4576.1359821610305.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brandon Ross" > On Fri, 1 Feb 2013, Frank Bulk (iname.com) wrote: > > > What's missing in this dialogue is the video component of an offering. > > Many customers like a triple (or quad) play because the price points > > are reasonable comparable to getting unbundled pricing from more than > > one provider, and they have just throat to choke and bill to pay. > > I must be missing something here. Why would a triple play using IPTV > and VOIP be unachievable in this model? Available Providers. The City, remember, won't be doing L3, so we'd need to find someone who was doing that. You know how big a job it is to be a cable company? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From bross at pobox.com Sat Feb 2 17:49:43 2013 From: bross at pobox.com (Brandon Ross) Date: Sat, 2 Feb 2013 12:49:43 -0500 (EST) Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: <30721194.4576.1359821610305.JavaMail.root@benjamin.baylink.com> References: <30721194.4576.1359821610305.JavaMail.root@benjamin.baylink.com> Message-ID: On Sat, 2 Feb 2013, Jay Ashworth wrote: > Available Providers. > > The City, remember, won't be doing L3, so we'd need to find someone who > was doing that. You know how big a job it is to be a cable company? I would think in this model that the city would be prohibited from providing those services. Perhaps I live in a different world, but just about all of the small to midsize service providers I work with offer triple play today, and nearly all of them are migrating their triple play services to IP. If rural telco in Alabama or Mississippi can deliver triple play, surely a larger provider somewhere like NYC can do as well, no? -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From jra at baylink.com Sat Feb 2 17:54:22 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 12:54:22 -0500 (EST) Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: Message-ID: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brandon Ross" > On Sat, 2 Feb 2013, Jay Ashworth wrote: > > > Available Providers. > > > > The City, remember, won't be doing L3, so we'd need to find someone > > who was doing that. You know how big a job it is to be a cable company? > > I would think in this model that the city would be prohibited from > providing those services. That is what I just said, yes, Brandon: the City would offer L1 optical home-run connectivity and optional L2 transport and aggregation with Ethernet provider hand-off, and nothing at any higher layers. > Perhaps I live in a different world, but just about all of the small to > midsize service providers I work with offer triple play today, and nearly > all of them are migrating their triple play services to IP. Really. Citations? I'd love to see it play that way, myself. > If rural telco in Alabama or Mississippi can deliver triple play, surely a > larger provider somewhere like NYC can do as well, no? Well, I ain't no NYC, but... :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From owen at delong.com Sat Feb 2 18:04:10 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 2 Feb 2013 10:04:10 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: <20130202101955.GP6172@leitl.org> References: <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> Message-ID: <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> On Feb 2, 2013, at 2:19 AM, Eugen Leitl wrote: > On Fri, Feb 01, 2013 at 04:43:56PM -0800, Leo Bicknell wrote: > >> The only place PON made any sense to me was extreme rural areas. >> If you could go 20km to a splitter and then hit 32 homes ~1km away >> (52km fiber pair length total), that was a win. If the homes are >> 2km from the CO, 32 pair (64km fiber pair length total) of home >> runs was cheaper than the savings on fiber, and then the cost of >> GPON splitters and equipment. I'm trying to figure out if my assessment >> is correct or not... > > Is there any specific reason why muni networks don't use 1-10 GBit > fiber mesh, using L3 switches in DSLAMs on every street corner? Well, one reason is that, IMHO, the goal here is to provide a flexible L1 platform that will allow multiple competing providers a low barrier to entry to provide a multitude of competitive services. Owen From davidpeahi at gmail.com Sat Feb 2 18:09:03 2013 From: davidpeahi at gmail.com (david peahi) Date: Sat, 2 Feb 2013 10:09:03 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: <0D7538BB-C96D-4030-8C4C-0CD2282922E3@delong.com> References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <510C3EF6.5060905@vaxination.ca> <0D7538BB-C96D-4030-8C4C-0CD2282922E3@delong.com> Message-ID: Perhaps I missed a reference to receiver sensitivity in this thread. Since the receiver optical-electric components are binary in nature, received optical dB only has to be equal to or greater than the receiver's sensitivity. Low or high dB received light produces the same quality at the receiver. Thus, dB loss can be extensive due to factors such as attenuation, splices, dispersal, but as long as the received dB level is equal to the receiver sensitivity, it doesn't matter how much launched dB is lost. Is the point that splitters reduce the effective distance from the launch point in the PON architecture? David On Fri, Feb 1, 2013 at 7:52 PM, Owen DeLong wrote: > > On Feb 1, 2013, at 14:17 , Jean-Francois Mezei < > jfmezei_nanog at vaxination.ca> wrote: > > > On 13-02-01 16:03, Jason Baugher wrote: > > > >> The reason to push splitters towards the customer end is financial, not > >> technical. > > > > It also has to do with existing fibre infrastructure. If a Telco has > > already adopted a "fibre to a node" philosophy, then it has a;ready > > installed a limited number of strands between CO and many neighbouhoods. > > Since the discussion here is about muni fiber capabilities and ideal > greenfield > plant designs, existing fiber is irrelevant to the discussion at hand. > > > It makes sense to standardise on one technology. And if that technology, > > because it is used by many, ends up much cheaper due to economies of > > scale, it makes sense to adopt it. > > Only if you're a single vendor looking to provide a single-vendor solution. > That's really not what this conversation is about, IMHO. In fact, that's a > pretty good summary of the situation we're trying to fix. > > > And remember that it isn't just the cable. You need to consider the OLT > > cards. An OLT card can often support a few GPON systems each passing 32 > > homes. > > Not sure why this matters... > > > With 1 strand per home, you take up one port per home served. (possibly > > per home passed depending on deployment philosophy). So you end up > > needing far more cards in an OLT to serve the same number of people. > > More $$$ needed. > > Uh, no... That's not what we're talking about. We're talking about still > using > splitters, but, putting the splitter next to the OLT instead of near the > ONT > end. That's all. > > > GPON isn't suited for trunks. But for last mile, is it really so bad ? > > Yes... Because... > > > 2.mumble gpbs of capacity for 32 homes yields 62mbps of sustained > > download for each home. (assuming you have 32 homes conected and using > > it at same time) > > Great by todays standards, but likely to be obsoleted within 10 years. > Given > the nearly 100 year old nature of some copper plants, I'd like to see us > start > building fiber plants in a way that doesn't lock us into a particular > technology > choice constrained to the economic tradeoffs that are relevant today and > may be completely different in as little as 5 years. > > > If you have multicast and everyone is watching superbowl at same time, > > you're talking up very little bandwidth on that 2.mumble GPON link. > > Meh. Since everyone seems to want to be able to pause, rewind, etc., > multicast doesn't tend to happen so much even in the IPTV world these > days. > > Owen > > > > From brunner at nic-naa.net Sat Feb 2 18:24:22 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 02 Feb 2013 10:24:22 -0800 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> References: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> Message-ID: <510D59D6.2040906@nic-naa.net> On 2/2/13 9:54 AM, Jay Ashworth wrote: >> > I would think in this model that the city would be prohibited from >> > providing those services. > That is what I just said, yes, Brandon: the City would offer L1 optical > home-run connectivity and optional L2 transport and aggregation with > Ethernet provider hand-off, and nothing at any higher layers. > The L0 (ROW, poles & conduits) provider, and in option #1 L1 connectivity provider, and in option #2 L2 transport and aggregation provider, aka "City" is also a consumer of "City 2 City" service above L2, and is also a consumer of "City 2 Subscriber" services above L2. Creating the better platform for competitive access to the City's L(option(s)) infrastructure must not prelude "City" as a provider. Eric From jra at baylink.com Sat Feb 2 18:40:30 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 13:40:30 -0500 (EST) Subject: Rollup: Small City Municipal Broadband In-Reply-To: <2189432.4608.1359827842481.JavaMail.root@benjamin.baylink.com> Message-ID: <9191986.4618.1359830430468.JavaMail.root@benjamin.baylink.com> Ok, here's a rough plan assembled from everyone's helpful contributions and arguing all week, based on the City with which, if I'm lucky, I might get a job Sometime Soon. :-) (I'm sure some of you can speculate which city it might be, but Please Don't.) It's about 3 square miles, and has about 8000 passings, the majority of which are single or double family residential; a sprinkling of multi-tenant, about a dozen city facilities, and a bunch of retail multi-unit business. Oh, and a college campus, commuter. My goal is to fiber the entire city, with a 3-pr tail on each single-family residence (or unit of a duplex/triplex), and N*1.5 on multi-tenant business buildings, and probably about N*1.1 or so on large multi-unit residences. Empty lots, if we have any, will also get a 3-pr tail, in a box. My plan is for the city to contract out the design and build of the physical plant, with each individual pair home-run to a Master Distributing Frame in a city building. Since the diameter of the city is so small, this can be a single building, and it need not be centrally located -- since we are a coastal city, I want it at the other end. :-) I propose to offer to clients, generally ISP, but also property owner/ renters, L1 connectivity, either between two buildings, or to a properly equipped ISP, and also to equip for and offer L2 aggregated connectivity to ISPs, where the city, instead of the ISP, will provide the necessary CPE termination gear (ONT). The entire L0 fiber build, and all L2 aggregation equipment (except potential GPON splitters mentioned next) will be the property of the City. Assuming that the optical math pans out, we will hang GPON splitter frames in the MDT, and cross connect subscriber ports to the front of them, and the back of them to Provider equipment in an associated colo, in rooms or cages; we'll also probably do this for our L2 subscribers, using our own GPON splitters. Those will then be groomed into Ethernet handoffs for whatever providers want to take it that way, at a higher MRC. Splitters installed for Providers who take L1 handoffs will be their property, though installed in our MDF room. We will do all M-A-C work on the MDF, into which Provider employees will generally not be admitted, at least unescorted, on a daily basis, except in "emergencies", for which an extra NRC will be levied. The cost we will charge the Providers, per subscriber, will be a fixed MRC, similar to a 'tariffed' rate, which is published, and all Providers pay the same rate, which is subject by contract to occasional adjustment in either direction, and which is set to recover our costs to provide the service, based on take rates and depreciation periods which I have not yet determined. I'm assuming I can get 30 year depreciation out of the fiber plant with no problems, probably 40... maybe 50 if it's built to high enough standards -- I do not expect passive glass fiber to become obsolete in 50 years. Active equipment, a much shorter period, of course, probably between 4 and 7 years, depending on how far up the S-curve of terminal equipment design it proves that we've already traveled. At the moment, my comparison device is the Calix E7-20, with either 24-port AE or the GPON cards; either 836GE interior ONTs, or their equivalent exterior ones (since the power module has to be inside anyway, I'm not sure you gain that much by putting the ONT outside, but...) My motivation for not doing L3 is that it is said to greatly improve the chances for competition at the ISP level, a fact not yet in evidence. My motivation for not doing GPON in the field is that it's thoroughly impractical to do that in an environment where an unknown number of multiple providers will be competing for the subscribers, and anyway it breaks point to point, which the city will need for itself, and which I want to offer to residents as well. My motivation for doing L2 is that it takes a lost of the front-end cost burden off of potential smaller 'boutique' ISPs specializing in various disciplines (very low cost/lifeline service, very high speed, 'has a big local usenet spool', or what have you); such providers will have to pay (and recover) a higher per-subscriber MRC, in exchange for not having to themselves provision and install GPON splitters and something like a Calix E7 -- such hardware will be installed by the City, and cost-shared; if/when such a provider gets big enough, they can install their own, and we'll cut them over. I propose to take the project to the council for funding and approval having in my pocket a letter of intent from a local 2nd tier ISP of long standing to become our launch provider, with no incentives over the published rates except the guarantee of additional subscribers. My underlying motivation, which is intended to answer any tradeoff queries which I haven't explicitly addresses before this point, is to increase the City's position as being "full service" (as small as it is, it does it's own fire, police, garbage and water already), and improve it's chances of selection by people who are deciding where to move. The City already has a relatively good image, within its target market, but as time marches ever forwards, the maximum available broadband in its footprint will become less and less acceptable, and I expect that there are a significant number of people around the country for whom "I can get Gigabit in my house? Bidirectional? I'm moving" is a valid viewpoint. I know already that "what kind of broadband can I get" is a top-5, and sometimes top-3 selection issue for people contemplating a move. Things, therefore, which improve the city's image with potential immigrants, be they residents or small businesses, are a Good Thing, whether because those people actually want or need those services, or whether it's merely because they like to bask in the reflected glow there of. These things will likely reduce the city's vacancy rate, and thus increase property tax revenue and hence the city's budget, in addition to slowly improving the city's socioeconomic demographics, which will itself likely have a salutary effect on the small businesses already here, and in the decision processes of people thinking to move one here or start one. That's my thinking so far. Now comes the hard part: assembling enough other budgetary numbers to determine how much it will cost, how much we'll have to charge, and whether people will *pay* that much. I don't have any illusions that the wholesale charges will be a revenue stream for the City, and I won't let the council get any such ideas either; the benefits to the city (aside from dark fiber to all our own buildings) are a bit deeper than that, and will require sufficient time to come to fruition. I wrote this as a summary for all the helpful NANOGers who chimed in this week, and as a clarification for those who weren't quite sure where *I* was trying to go -- all muni builds are sui generis, and this one moreso than most. If any of you see anything we've already said, but I left out, please let me know... And have a Whacky Weekend. If any of you pass through the west coast enroute to ORL, let me know. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Sat Feb 2 18:47:02 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 13:47:02 -0500 (EST) Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: <510D59D6.2040906@nic-naa.net> Message-ID: <24341979.4620.1359830822313.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Eric Brunner-Williams" > The L0 (ROW, poles & conduits) provider, and > in option #1 L1 connectivity provider, and > in option #2 L2 transport and aggregation provider, > aka "City" > is also a consumer of "City 2 City" service above L2, and > is also a consumer of "City 2 Subscriber" services above L2. > > Creating the better platform for competitive access to the City's > L(option(s)) infrastructure must not prelude "City" as a provider. The City will be it's own customer for L1 ptp between our facilities, yes. We will also be a customer of the L1 service to provide the L2 service, and that MRC cost-recovery will be included in the L2 cost. While I realize that we could in turn be a competing L3 provider as a customer of the L1/2 provider, I'm loathe to go there if I'm not actually forced to; even moreso than the L2 bump, that's a *big* increase in labor and hence costs, in addition to which I've been convinced here that potential L3 providers will be less likely not to assume The Fix Is In in that case; the City's L3 provider getting an unfair break. If I can't get an LOI as suggested in the posting I just put up, then we may need to be the provider-of-last-resort, at a higher cost to continue to make coming in and competing as a provider. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jfmezei_nanog at vaxination.ca Sat Feb 2 19:23:15 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 02 Feb 2013 14:23:15 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <7249088.4570.1359819388729.JavaMail.root@benjamin.baylink.com> References: <7249088.4570.1359819388729.JavaMail.root@benjamin.baylink.com> Message-ID: <510D67A3.2040200@vaxination.ca> On 13-02-02 10:36, Jay Ashworth wrote: > Yes, but everyone on a splitter must be backhauled to the same L1 provider, > and putting splitters *in the outside plant* precludes any other type > of L1 service, *ever*. So that's a non-starter. If you have 4 ISPs, why not put 4 splitters in the neighbourhood ? Individual homes can be hooked to any one of the 4 splitters, and you then only need 4 strands between splitter and CO. I understand that having strands from CO to Homes is superior at the technical point of veiw and gives you more flexibility for different services (including commercial services to a home while the neighbour gets residential services). But if strands from CO to homes is so superior, how come telcos aren't doing it and are using GPON instead ? From jra at baylink.com Sat Feb 2 19:42:48 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 02 Feb 2013 14:42:48 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <510D67A3.2040200@vaxination.ca> References: <7249088.4570.1359819388729.JavaMail.root@benjamin.baylink.com> <510D67A3.2040200@vaxination.ca> Message-ID: Because telcos specifically want to /discourage/ competition. You're perilously close to trolling, here, sir... -jra Jean-Francois Mezei wrote: >On 13-02-02 10:36, Jay Ashworth wrote: > >> Yes, but everyone on a splitter must be backhauled to the same L1 >provider, >> and putting splitters *in the outside plant* precludes any other type >> of L1 service, *ever*. So that's a non-starter. > > >If you have 4 ISPs, why not put 4 splitters in the neighbourhood ? >Individual homes can be hooked to any one of the 4 splitters, and you >then only need 4 strands between splitter and CO. > >I understand that having strands from CO to Homes is superior at the >technical point of veiw and gives you more flexibility for different >services (including commercial services to a home while the neighbour >gets residential services). > >But if strands from CO to homes is so superior, how come telcos aren't >doing it and are using GPON instead ? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From khelms at zcorum.com Sat Feb 2 20:07:41 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 2 Feb 2013 15:07:41 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> References: <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> Message-ID: Owen, A layer 1 architecture isn't going to be an economical option for the foreseeable future so opining on its value is a waste of time...its simple not feasible now or even 5 years from now because of costs. The optimal open access network (with current or near future technology) is well known. Its called Ethernet and the methods to do triple play and open access are well documented not to mention already in wide spread use. Trying to enforce a layer 1 approach would be more expensive than the attempts to make this work with Packet Over SONET or even ATM. What is about a normal Ethernet deployment that you see as a negative? What problem are you tying to solve? On Sat, Feb 2, 2013 at 1:04 PM, Owen DeLong wrote: > > On Feb 2, 2013, at 2:19 AM, Eugen Leitl wrote: > > > On Fri, Feb 01, 2013 at 04:43:56PM -0800, Leo Bicknell wrote: > > > >> The only place PON made any sense to me was extreme rural areas. > >> If you could go 20km to a splitter and then hit 32 homes ~1km away > >> (52km fiber pair length total), that was a win. If the homes are > >> 2km from the CO, 32 pair (64km fiber pair length total) of home > >> runs was cheaper than the savings on fiber, and then the cost of > >> GPON splitters and equipment. I'm trying to figure out if my assessment > >> is correct or not... > > > > Is there any specific reason why muni networks don't use 1-10 GBit > > fiber mesh, using L3 switches in DSLAMs on every street corner? > > Well, one reason is that, IMHO, the goal here is to provide a flexible > L1 platform that will allow multiple competing providers a low barrier > to entry to provide a multitude of competitive services. > > Owen > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From owen at delong.com Sat Feb 2 20:04:33 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 2 Feb 2013 12:04:33 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: <510D67A3.2040200@vaxination.ca> References: <7249088.4570.1359819388729.JavaMail.root@benjamin.baylink.com> <510D67A3.2040200@vaxination.ca> Message-ID: <04682D97-951A-4D6C-84F7-07A06D58C4EB@delong.com> On Feb 2, 2013, at 11:23 AM, Jean-Francois Mezei wrote: > On 13-02-02 10:36, Jay Ashworth wrote: > >> Yes, but everyone on a splitter must be backhauled to the same L1 provider, >> and putting splitters *in the outside plant* precludes any other type >> of L1 service, *ever*. So that's a non-starter. > > > If you have 4 ISPs, why not put 4 splitters in the neighbourhood ? > Individual homes can be hooked to any one of the 4 splitters, and you > then only need 4 strands between splitter and CO. > > I understand that having strands from CO to Homes is superior at the > technical point of veiw and gives you more flexibility for different > services (including commercial services to a home while the neighbour > gets residential services). > > But if strands from CO to homes is so superior, how come telcos aren't > doing it and are using GPON instead ? > Because Telcos are optimizing for different parameters. They want the cheapest way to provide an adequate solution by today's standards and, where possible, to discourage competition. They want to offer a very small number of very standardized products. GPON with splitters in the neighborhood meet those goals. Hopefully, a city has a somewhat opposite set of goals. To provide a quality infrastructure for many years to come which encourages and supports the development of a vibrant and competitive market for a wide variety of services. Owen From khelms at zcorum.com Sat Feb 2 20:10:25 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 2 Feb 2013 15:10:25 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <9191986.4618.1359830430468.JavaMail.root@benjamin.baylink.com> References: <2189432.4608.1359827842481.JavaMail.root@benjamin.baylink.com> <9191986.4618.1359830430468.JavaMail.root@benjamin.baylink.com> Message-ID: Why on earth would you do this with PON instead of active Ethernet? What GPON vendor have you found where their technical staff will tell you this is a good architecture for their PON offering? On Sat, Feb 2, 2013 at 1:40 PM, Jay Ashworth wrote: > Ok, here's a rough plan assembled from everyone's helpful contributions > and arguing all week, based on the City with which, if I'm lucky, I > might get a job Sometime Soon. :-) (I'm sure some of you can speculate > which city it might be, but Please Don't.) > > It's about 3 square miles, and has about 8000 passings, the majority of > which are single or double family residential; a sprinkling of > multi-tenant, > about a dozen city facilities, and a bunch of retail multi-unit business. > > Oh, and a college campus, commuter. > > My goal is to fiber the entire city, with a 3-pr tail on each single-family > residence (or unit of a duplex/triplex), and N*1.5 on multi-tenant business > buildings, and probably about N*1.1 or so on large multi-unit residences. > Empty lots, if we have any, will also get a 3-pr tail, in a box. > > My plan is for the city to contract out the design and build of the > physical > plant, with each individual pair home-run to a Master Distributing Frame in > a city building. Since the diameter of the city is so small, this can be > a single building, and it need not be centrally located -- since we are a > coastal city, I want it at the other end. :-) > > > I propose to offer to clients, generally ISP, but also property owner/ > renters, L1 connectivity, either between two buildings, or to a properly > equipped ISP, and also to equip for and offer L2 aggregated connectivity > to ISPs, where the city, instead of the ISP, will provide the necessary > CPE termination gear (ONT). The entire L0 fiber build, and all L2 > aggregation equipment (except potential GPON splitters mentioned next) > will be the property of the City. > > Assuming that the optical math pans out, we will hang GPON splitter frames > in the MDT, and cross connect subscriber ports to the front of them, and > the back of them to Provider equipment in an associated colo, in rooms > or cages; we'll also probably do this for our L2 subscribers, using our > own GPON splitters. Those will then be groomed into Ethernet handoffs > for whatever providers want to take it that way, at a higher MRC. > Splitters installed for Providers who take L1 handoffs will be their > property, though installed in our MDF room. > > We will do all M-A-C work on the MDF, into which Provider employees will > generally not be admitted, at least unescorted, on a daily basis, except > in "emergencies", for which an extra NRC will be levied. > > The cost we will charge the Providers, per subscriber, will be a fixed > MRC, similar to a 'tariffed' rate, which is published, and all Providers > pay the same rate, which is subject by contract to occasional adjustment > in either direction, and which is set to recover our costs to provide > the service, based on take rates and depreciation periods which I have not > yet determined. I'm assuming I can get 30 year depreciation out of the > fiber plant with no problems, probably 40... maybe 50 if it's built to > high enough standards -- I do not expect passive glass fiber to become > obsolete in 50 years. > > Active equipment, a much shorter period, of course, probably between 4 > and 7 years, depending on how far up the S-curve of terminal equipment > design it proves that we've already traveled. At the moment, my > comparison device is the Calix E7-20, with either 24-port AE or the > GPON cards; either 836GE interior ONTs, or their equivalent exterior > ones (since the power module has to be inside anyway, I'm not sure you > gain that much by putting the ONT outside, but...) > > > > My motivation for not doing L3 is that it is said to greatly improve the > chances for competition at the ISP level, a fact not yet in evidence. > > My motivation for not doing GPON in the field is that it's thoroughly > impractical to do that in an environment where an unknown number of > multiple providers will be competing for the subscribers, and anyway > it breaks point to point, which the city will need for itself, and which > I want to offer to residents as well. > > My motivation for doing L2 is that it takes a lost of the front-end cost > burden off of potential smaller 'boutique' ISPs specializing in various > disciplines (very low cost/lifeline service, very high speed, 'has a big > local usenet spool', or what have you); such providers will have to pay > (and recover) a higher per-subscriber MRC, in exchange for not having to > themselves provision and install GPON splitters and something like a Calix > E7 -- such hardware will be installed by the City, and cost-shared; if/when > such a provider gets big enough, they can install their own, and we'll > cut them over. > > > I propose to take the project to the council for funding and approval > having in my pocket a letter of intent from a local 2nd tier ISP of > long standing to become our launch provider, with no incentives over > the published rates except the guarantee of additional subscribers. > > > My underlying motivation, which is intended to answer any tradeoff queries > which I haven't explicitly addresses before this point, is to increase > the City's position as being "full service" (as small as it is, it does > it's own fire, police, garbage and water already), and improve it's > chances of selection by people who are deciding where to move. The City > already has a relatively good image, within its target market, but as > time marches ever forwards, the maximum available broadband in its > footprint will become less and less acceptable, and I expect that there > are a significant number of people around the country for whom "I can > get Gigabit in my house? Bidirectional? I'm moving" is a valid viewpoint. > > I know already that "what kind of broadband can I get" is a top-5, and > sometimes top-3 selection issue for people contemplating a move. > > Things, therefore, which improve the city's image with potential > immigrants, > be they residents or small businesses, are a Good Thing, whether because > those people actually want or need those services, or whether it's merely > because they like to bask in the reflected glow there of. > > These things will likely reduce the city's vacancy rate, and thus increase > property tax revenue and hence the city's budget, in addition to slowly > improving the city's socioeconomic demographics, which will itself likely > have a salutary effect on the small businesses already here, and in the > decision processes of people thinking to move one here or start one. > > > That's my thinking so far. Now comes the hard part: assembling enough > other budgetary numbers to determine how much it will cost, how much we'll > have to charge, and whether people will *pay* that much. > > I don't have any illusions that the wholesale charges will be a revenue > stream for the City, and I won't let the council get any such ideas either; > the benefits to the city (aside from dark fiber to all our own buildings) > are a bit deeper than that, and will require sufficient time to come to > fruition. > > > I wrote this as a summary for all the helpful NANOGers who chimed in this > week, and as a clarification for those who weren't quite sure where *I* > was trying to go -- all muni builds are sui generis, and this one moreso > than most. > > If any of you see anything we've already said, but I left out, please > let me know... > > And have a Whacky Weekend. If any of you pass through the west coast > enroute to ORL, let me know. :-) > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From dylan at dylannguyen.net Sat Feb 2 20:10:50 2013 From: dylan at dylannguyen.net (Dylan N) Date: Sat, 02 Feb 2013 15:10:50 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <9191986.4618.1359830430468.JavaMail.root@benjamin.baylink.com> References: <9191986.4618.1359830430468.JavaMail.root@benjamin.baylink.com> Message-ID: <510D72CA.4000107@dylannguyen.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Out of curiosity, do you have plans for legal battles or anything? There have been some other places attempting or running muni broadband that have resulted in crap like the hilariously named "AN ACT TO PROTECT JOBS AND INVESTMENT BY REGULATING LOCAL GOVERNMENT COMPETITION WITH PRIVATE BUSINESS" bill. Sorry, misclicked, delete the first incomplete email if possible. On 2013-2-3, Jay Ashworth wrote: > Ok, here's a rough plan assembled from everyone's helpful contributions > and arguing all week, based on the City with which, if I'm lucky, I > might get a job Sometime Soon. :-) (I'm sure some of you can speculate > which city it might be, but Please Don't.) > > It's about 3 square miles, and has about 8000 passings, the majority of > which are single or double family residential; a sprinkling of multi-tenant, > about a dozen city facilities, and a bunch of retail multi-unit business. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJRDXLKAAoJEG1+YMkH2Rls1DIH/2sLEp3po8GYQjgJtnSs7wCj jNwKlE8FJzoYgMtJPIv5bpwlHaqGjKfAJGqi8DBnp/WoJJIXmgDf0HLiCSgAnvPX 90tqUWy0J7W31PtqajUAaZKF7NehNo3/N5BQe9RGfGBLu3fvZxJ7Fqd+iKZl389D eOO3IOYapTZvWGkXN80EJBdld2NDYnboiigGGFpViwhu3PP20GxjOE+1ntiOzZ79 mPLaemD3/MK11vYBHpWBptvwHPOE0K8ec3vCxgknhub31LwXzDAv3AfvvxDyl/Ei GeBMg57NuEmgh/AvRaXpfNel6eDurpNGKya4rQYUgJAQ3wOlxIqVa9fsR2ZN1vk= =5/Xm -----END PGP SIGNATURE----- From jra at baylink.com Sat Feb 2 20:22:57 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 15:22:57 -0500 (EST) Subject: Rollup: Small City Municipal Broadband In-Reply-To: Message-ID: <33402569.4632.1359836577050.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > Why on earth would you do this with PON instead of active Ethernet? > What GPON vendor have you found where their technical staff will tell you > this is a good architecture for their PON offering? Asked and answered, Scott; have you been ignoring the threads all week? I'm pretty sure I even answered it in the posting, but just in case: 1) Line cards for the OLT frames appear to be 2 orders of magnitude denser for GPON termination than AE (480 ports per 10U vs 10k ports per 10U in Calix, unless I've badly misunderstood my sources), and 2) GPON is what potential L3 providers large enough to want an optical handoff are generally used to. If someone wants AE, they can certainly have it. (C'mon; miss the *next* turn, too :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Sat Feb 2 20:32:54 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 15:32:54 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: Message-ID: <11839530.4636.1359837174683.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > A layer 1 architecture isn't going to be an economical option for the > foreseeable future so opining on its value is a waste of time...its > simple > not feasible now or even 5 years from now because of costs. The > optimal > open access network (with current or near future technology) is well > known. > Its called Ethernet and the methods to do triple play and open access > are > well documented not to mention already in wide spread use. Trying to > enforce a layer 1 approach would be more expensive than the attempts > to > make this work with Packet Over SONET or even ATM. > > What is about a normal Ethernet deployment that you see as a negative? > What problem are you tying to solve? Well, Scott, assuming you mean ethernet over fiber, then you've just said that it's economically infeasible to deploy the physical layer of precisely the architecture you advocate. I find these conflicting reports most conflicting. As for "what problems are you trying to solve", I just itemized that. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Sat Feb 2 20:36:16 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 15:36:16 -0500 (EST) Subject: Rollup: Small City Municipal Broadband In-Reply-To: <510D72CA.4000107@dylannguyen.net> Message-ID: <12882181.4638.1359837376898.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Dylan N" > Out of curiosity, do you have plans for legal battles or anything? > There have been some other places attempting or running muni broadband that > have resulted in crap like the hilariously named "AN ACT TO PROTECT > JOBS AND INVESTMENT BY REGULATING LOCAL GOVERNMENT COMPETITION WITH PRIVATE > BUSINESS" bill. Believe me, budgeting for both legal, and PR to make Verizoany large proprietary carrier look greedy and malign is in my plans, yes. :-) TTBOMK, Florida is not a state where Verizon succeeded in making muni ownership of the phy layer illegal. And since they're on record that a) they were cherrypicking and b) they're done now it shouldn't be too hard to suggest their intentions. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From pfunix at gmail.com Sat Feb 2 20:43:45 2013 From: pfunix at gmail.com (Beavis) Date: Sat, 2 Feb 2013 14:43:45 -0600 Subject: Ddos mitigation service In-Reply-To: <011201ce0099$23b47b70$6b1d7250$@iodi.se> References: <510BD7E8.4010805@userid.org> <510BE3EA.1010009@nimblesec.com> <011201ce0099$23b47b70$6b1d7250$@iodi.se> Message-ID: +1 on Dosarrest, not so crazy price, used them before their support is awesome. Used to be called whypigsfly, heard that some of their techniques of mitigation we're used by prolexic as well. I'm not a sales rep. nor will I ever be. On Fri, Feb 1, 2013 at 10:28 AM, Joseph Chin wrote: > From my personal experience, I am a fan of pure-play DDoS mitigation service > providers (e.g. Prolexic, Dosarrest) because they are the least likely to > give up on you when things get real difficult. Read the SLA careful to make > sure it is fit for your purpose. > > -----Original Message----- > From: James Thomas [mailto:jim at nimblesec.com] > Sent: Friday, February 01, 2013 3:49 PM > To: nanog at nanog.org > Subject: Re: Ddos mitigation service > > Hi Pierre, > > Thank you for your interesting note. > > On 01/02/2013 09:57, Pierre Lamy wrote: >> The 3 major scrubbing vendors: >> >> Prolexic >> Verisign >> Akamai > > IIRC, CloudFlare claims to the same capcity of DDOS mitigation as Prolexic > (500gb) and also has a free option with fewer scrubbing features. Do you > have experience with it, or is there some other reason to have excluded it > from your list? I apologize for my noobish question. > > Cheers, > > James > > > > -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments Disclaimer: http://goldmark.org/jeff/stupid-disclaimers/ From khelms at zcorum.com Sat Feb 2 20:53:20 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 2 Feb 2013 15:53:20 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <33402569.4632.1359836577050.JavaMail.root@benjamin.baylink.com> References: <33402569.4632.1359836577050.JavaMail.root@benjamin.baylink.com> Message-ID: Jay, I'm spotty on mailing lists since most of my time is spent building these kinds of networks. 1) Talk to more vendors than just Calix, especially if they're quoting their Ethernet density on the C7. Also, keep in mind that port density may or may not be relevant to your situation since space for muni shelves isn't usually a problem. Port density is much more important if you're deploying in existing telco enclosures but muni networks tend (not universally of course) to reuse existing city infrastructure building to house the nodes of their network. Please note that I am not reccomending against Calix, they're a good solution in many cases, but AE is not a strong point on the C7. The E7 and the B series, which is the old Occam product, is much better than the C7. For that matter I wouldn't consider doing a new build on the C7 since that platform's EoL can't be too far in the future. 2) I have no idea who told you this, but this is completely and utterly incorrect in nationwide terms. If you have a specific layer 3 provder in mind that tells you they want a GPON hand off then that's fine, but ISPs in general don't know what GPON is and have no gear to terminate that kind of connection. On Sat, Feb 2, 2013 at 3:22 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Scott Helms" > > > Why on earth would you do this with PON instead of active Ethernet? > > What GPON vendor have you found where their technical staff will tell you > > this is a good architecture for their PON offering? > > Asked and answered, Scott; have you been ignoring the threads all week? > > I'm pretty sure I even answered it in the posting, but just in case: > > 1) Line cards for the OLT frames appear to be 2 orders of magnitude denser > for GPON termination than AE (480 ports per 10U vs 10k ports per 10U in > Calix, unless I've badly misunderstood my sources), and > > 2) GPON is what potential L3 providers large enough to want an optical > handoff are generally used to. > > If someone wants AE, they can certainly have it. > > (C'mon; miss the *next* turn, too :-) > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Sat Feb 2 21:11:55 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 16:11:55 -0500 (EST) Subject: Rollup: Small City Municipal Broadband In-Reply-To: <24683668.4644.1359839500973.JavaMail.root@benjamin.baylink.com> Message-ID: <24601950.4646.1359839515250.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > I'm spotty on mailing lists since most of my time is spent building > these kinds of networks. Showoff. :-) > 1) Talk to more vendors than just Calix, especially if they're quoting > their Ethernet density on the C7. Also, keep in mind that port density may > or may not be relevant to your situation since space for muni shelves isn't > usually a problem. Port density is much more important if you're deploying > in existing telco enclosures but muni networks tend (not universally > of course) to reuse existing city infrastructure building to house the > nodes of their network. Please note that I am not reccomending against > Calix, they're a good solution in many cases, but AE is not a strong point on > the C7. The E7 and the B series, which is the old Occam product, is much > better than the C7. For that matter I wouldn't consider doing a new > build on the C7 since that platform's EoL can't be too far in the future. I hope I said "E7"; it's what I meant to say. Yes, I wasn't going to stop at Calix; I'm just juggling budgetary type numbers at the moment; I'll have 3 or 4 quotes before I go to press. It's a 36 month project just to beginning of build, at this point, likely. Assuming I get the gig at all. > 2) I have no idea who told you this, but this is completely and utterly > incorrect in nationwide terms. If you have a specific layer 3 provder > in mind that tells you they want a GPON hand off then that's fine, but > ISPs in general don't know what GPON is and have no gear to terminate that > kind of connection. Other people here, said it. If nothing else, it's certainly what the largest nationwide FTTH provider is provisioning, and I suspect it serves more passings than anything else; possibly than everything else. But it doesn't matter either way, except in cross-connects between my MDF and my colo cages; except for GPONs apparent compatibility with RF CATV delivery (which I gather, but have not researched) is just block-upconvert, I don't care either way; there's no difference in the plant buildout. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From owen at delong.com Sat Feb 2 21:26:37 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 2 Feb 2013 13:26:37 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> Message-ID: <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> On Feb 2, 2013, at 12:07 PM, Scott Helms wrote: > Owen, > > A layer 1 architecture isn't going to be an economical option for the foreseeable future so opining on its value is a waste of time...its simple not feasible now or even 5 years from now because of costs. The optimal open access network (with current or near future technology) is well known. Its called Ethernet and the methods to do triple play and open access are well documented not to mention already in wide spread use. Trying to enforce a layer 1 approach would be more expensive than the attempts to make this work with Packet Over SONET or even ATM. > > What is about a normal Ethernet deployment that you see as a negative? What problem are you tying to solve? > Ethernet works just fine in the L1 solution I've proposed, so I'm not sure why you say it isn't economically viable to do so. Owen > > On Sat, Feb 2, 2013 at 1:04 PM, Owen DeLong wrote: > > On Feb 2, 2013, at 2:19 AM, Eugen Leitl wrote: > > > On Fri, Feb 01, 2013 at 04:43:56PM -0800, Leo Bicknell wrote: > > > >> The only place PON made any sense to me was extreme rural areas. > >> If you could go 20km to a splitter and then hit 32 homes ~1km away > >> (52km fiber pair length total), that was a win. If the homes are > >> 2km from the CO, 32 pair (64km fiber pair length total) of home > >> runs was cheaper than the savings on fiber, and then the cost of > >> GPON splitters and equipment. I'm trying to figure out if my assessment > >> is correct or not... > > > > Is there any specific reason why muni networks don't use 1-10 GBit > > fiber mesh, using L3 switches in DSLAMs on every street corner? > > Well, one reason is that, IMHO, the goal here is to provide a flexible > L1 platform that will allow multiple competing providers a low barrier > to entry to provide a multitude of competitive services. > > Owen > > > > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- From khelms at zcorum.com Sat Feb 2 21:29:44 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 2 Feb 2013 16:29:44 -0500 Subject: Fwd: Rollup: Small City Municipal Broadband In-Reply-To: References: <24683668.4644.1359839500973.JavaMail.root@benjamin.baylink.com> Message-ID: > I hope I said "E7"; it's what I meant to say. Yes, I wasn't going to > stop at Calix; I'm just juggling budgetary type numbers at the moment; > I'll have 3 or 4 quotes before I go to press. It's a 36 month project > just to beginning of build, at this point, likely. > > Assuming I get the gig at all. > The E7 is a good shelf, so that's a decent starting point. I'd also talk with Zhone, Allied Telesys, Adtran, and Cisco if for no other reason but get the best pricing you can. I'd also focus much more on your cost per port than the density since your uptake rate will be driven by economics long before port density and how much space your gear takes becomes an issue. > > > 2) I have no idea who told you this, but this is completely and utterly > > incorrect in nationwide terms. If you have a specific layer 3 provder > > in mind that tells you they want a GPON hand off then that's fine, but > > ISPs in general don't know what GPON is and have no gear to terminate > that > > kind of connection. > > Other people here, said it. If nothing else, it's certainly what the > largest nationwide FTTH provider is provisioning, and I suspect it serves > more passings than anything else; possibly than everything else. > I'm not sure what you mean by this. The largest PON offering in the US is Verizon's FIOS, but AFAIK they don't interconnect with anyone at layer 2 and their layer 3 fiber connections are either Packet Over SONET, Gig E(most common), or very occasionally still ATM. I have heard of a few instances where they'd buy existing GPON networks but I've never heard of them cross connecting like this even with operators that they do significant business with in other ways. > > But it doesn't matter either way, except in cross-connects between my MDF > and my colo cages; except for GPONs apparent compatibility with RF CATV > delivery (which I gather, but have not researched) is just block-upconvert, > I don't care either way; there's no difference in the plant buildout. > This is not correct. DOCSIS is an MPEG stream over QAM or QPSK modulation and there is nothing about it that is compatible to any flavor of PON. In fact if you look at the various CableLabs standards you'll see DPoE ( http://www.cablelabs.com/dpoe/specifications/index.html) which lists how a DOCSIS system can inter-operate and provision an PON system. If you look at the two largest PON networks (FIOS and Uverse) you'll see the two different approaches to doing video with a PON architecture. Verizon is simply modulating a MPEG stream (this is block compatible to a cable plant, in fact its the same way that a HFC network functions) on a different color on the same fiber that they send their PON signalling. ATT takes another approach where they simply run IPTV over their PON network. I've listened to presentations from Verizon's VP of Engineering (at that time) for FIOS and he said their choice was driven by the technology available when they launched and they did modulated RF over their fiber instead of IPTV because that technology wasn't as mature when they started. Verizon's approach may be what someone was thinking of when they said that PON was compatible to cable signaling but that's not how it works. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Sat Feb 2 21:31:42 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 2 Feb 2013 16:31:42 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> References: <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> Message-ID: Owen, Cross connecting at layer 1 is what I'm saying isn't feasible. If you want to simply hand them a fiber then sell dark fiber or DWDM ports but trying to create an architecture around PON or other splitters won't work because PON splitters aren't compatible with other protocols. On Sat, Feb 2, 2013 at 4:26 PM, Owen DeLong wrote: > > On Feb 2, 2013, at 12:07 PM, Scott Helms wrote: > > Owen, > > A layer 1 architecture isn't going to be an economical option for the > foreseeable future so opining on its value is a waste of time...its simple > not feasible now or even 5 years from now because of costs. The optimal > open access network (with current or near future technology) is well known. > Its called Ethernet and the methods to do triple play and open access are > well documented not to mention already in wide spread use. Trying to > enforce a layer 1 approach would be more expensive than the attempts to > make this work with Packet Over SONET or even ATM. > > What is about a normal Ethernet deployment that you see as a negative? > What problem are you tying to solve? > > > Ethernet works just fine in the L1 solution I've proposed, so I'm not sure > why you say it isn't economically viable to do so. > > Owen > > > On Sat, Feb 2, 2013 at 1:04 PM, Owen DeLong wrote: > >> >> On Feb 2, 2013, at 2:19 AM, Eugen Leitl wrote: >> >> > On Fri, Feb 01, 2013 at 04:43:56PM -0800, Leo Bicknell wrote: >> > >> >> The only place PON made any sense to me was extreme rural areas. >> >> If you could go 20km to a splitter and then hit 32 homes ~1km away >> >> (52km fiber pair length total), that was a win. If the homes are >> >> 2km from the CO, 32 pair (64km fiber pair length total) of home >> >> runs was cheaper than the savings on fiber, and then the cost of >> >> GPON splitters and equipment. I'm trying to figure out if my >> assessment >> >> is correct or not... >> > >> > Is there any specific reason why muni networks don't use 1-10 GBit >> > fiber mesh, using L3 switches in DSLAMs on every street corner? >> >> Well, one reason is that, IMHO, the goal here is to provide a flexible >> L1 platform that will allow multiple competing providers a low barrier >> to entry to provide a multitude of competitive services. >> >> Owen >> >> >> > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From bross at pobox.com Sat Feb 2 21:52:47 2013 From: bross at pobox.com (Brandon Ross) Date: Sat, 2 Feb 2013 16:52:47 -0500 (EST) Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> References: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> Message-ID: On Sat, 2 Feb 2013, Jay Ashworth wrote: >> Perhaps I live in a different world, but just about all of the small to >> midsize service providers I work with offer triple play today, and nearly >> all of them are migrating their triple play services to IP. > > Really. Citations? I'd love to see it play that way, myself. Okay: South Central Rural Telephone Glasgow, KY http://www.scrtc.com/ Left side of page, "Digital TV service". See this news article: http://www.wcluradio.com/index.php?option=com_content&view=article&id=15567:capacity-crowd-hears-good-report-at-scrtc-annuan-mee "He also reported that SCRTC is continuing to upgrade our services, converting customers to the new IPTV service and trying to get as much fiber optic cable built as possible." Camellia Communications Greenville, AL http://camelliacom.com/services/ctv-dvr.html Note the models of set-top boxes they are using are IP based Griswold Cooperative Telephone Griswold, IA http://www.griswoldtelco.com/griswold-coop-iptv-video Farmer's Mutual Coopeative Telephone Moulton, IA http://farmersmutualcoop.com/ Citizens Floyd, VA http://www.citizens.coop/ How about a Canadian example you say? CoopTel Valcourt, QB http://www.cooptel.qc.ca/en-residentiel-tele-guidesusager.php Check out the models of set-top boxes here too. Oh, also, have you heard of ATT U-Verse? http://www.att.com/gen/press-room?pid=4800&cdvn=news&newsarticleid=26580 "AT&T U-verse TV is the only 100 percent Internet Protocol-based television (IPTV) service offered by a national service provider" So even the likes of AT&T, in this scheme, could buy fiber paths to their subs and provide TV service. I'm pretty sure AT&T knows how to deliver voice services over IP as well. Do you want more examples? I bet I can come up with 50 small/regional telecom companies that are providing TV services over IP in North America if I put my mind to it. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From owen at delong.com Sat Feb 2 21:49:25 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 2 Feb 2013 13:49:25 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> Message-ID: <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> It seems that you are (deliberately or otherwise) seriously misconstruing what I am saying. I'm saying that if you build an L1 dark fiber system as we have described, the purchasers can use it to deploy Ethernet, PON, or any other technology. I'm not saying it's how I would build out a PON only system. That was never the goal. The goal is to provide a municipal L1 service that can be used by ANY provider for ANY service, or as close to that as possible. To make the offering more attractive to low-budget providers, the system may also incorporate some L2 services. Owen On Feb 2, 2013, at 1:31 PM, Scott Helms wrote: > Owen, > > Cross connecting at layer 1 is what I'm saying isn't feasible. If you want to simply hand them a fiber then sell dark fiber or DWDM ports but trying to create an architecture around PON or other splitters won't work because PON splitters aren't compatible with other protocols. > > > On Sat, Feb 2, 2013 at 4:26 PM, Owen DeLong wrote: > > On Feb 2, 2013, at 12:07 PM, Scott Helms wrote: > >> Owen, >> >> A layer 1 architecture isn't going to be an economical option for the foreseeable future so opining on its value is a waste of time...its simple not feasible now or even 5 years from now because of costs. The optimal open access network (with current or near future technology) is well known. Its called Ethernet and the methods to do triple play and open access are well documented not to mention already in wide spread use. Trying to enforce a layer 1 approach would be more expensive than the attempts to make this work with Packet Over SONET or even ATM. >> >> What is about a normal Ethernet deployment that you see as a negative? What problem are you tying to solve? >> > > Ethernet works just fine in the L1 solution I've proposed, so I'm not sure why you say it isn't economically viable to do so. > > Owen > >> >> On Sat, Feb 2, 2013 at 1:04 PM, Owen DeLong wrote: >> >> On Feb 2, 2013, at 2:19 AM, Eugen Leitl wrote: >> >> > On Fri, Feb 01, 2013 at 04:43:56PM -0800, Leo Bicknell wrote: >> > >> >> The only place PON made any sense to me was extreme rural areas. >> >> If you could go 20km to a splitter and then hit 32 homes ~1km away >> >> (52km fiber pair length total), that was a win. If the homes are >> >> 2km from the CO, 32 pair (64km fiber pair length total) of home >> >> runs was cheaper than the savings on fiber, and then the cost of >> >> GPON splitters and equipment. I'm trying to figure out if my assessment >> >> is correct or not... >> > >> > Is there any specific reason why muni networks don't use 1-10 GBit >> > fiber mesh, using L3 switches in DSLAMs on every street corner? >> >> Well, one reason is that, IMHO, the goal here is to provide a flexible >> L1 platform that will allow multiple competing providers a low barrier >> to entry to provide a multitude of competitive services. >> >> Owen >> >> >> >> >> >> -- >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- > > > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- From jra at baylink.com Sat Feb 2 22:26:57 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 17:26:57 -0500 (EST) Subject: Followup: Small City Municipal Broadband In-Reply-To: <9191986.4618.1359830430468.JavaMail.root@benjamin.baylink.com> Message-ID: <5680273.4658.1359844017052.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jay Ashworth" > It's about 3 square miles, and has about 8000 passings, the majority > of which are single or double family residential; a sprinkling of > multi-tenant, about a dozen city facilities, and a bunch of retail > multi-unit business. I was musing, off-list, as to why there isn't a Mad-Lib you can just plug some numbers into and get within, say, 40% or so of your target costs for a given design. Well, http://www.ftthcommunitytoolkit.wikispaces.net isn't it, but it does have a bunch of useful information for this project, looks like. A couple of clarifying points: 1) I had posited GPON as I assumed that was where most of the CATV over FTTH hardware work was, vice FiOS. Turns out there's lots of hardware for IPTV as well, and quite a number of smaller deployments, so apparently that path is easier than I thought. The only difference is cross-connect fiber counts, and possibly some link budget. 2) I was planning to provide an IX switch in my colo, so all my L3 providers could short-circuit traffic to my *other* providers through it, unloading my uplinks. 3) Given that, I suppose I could put Limelight and Akamai racks in there, and couple them to the IX switch as well, policies permitting. 4) Given what a pisser it's going to be to get tags to me on the local backbone loops (about 3 are with 5 miles of my city border), I'm also considering having a 10G or 2 hauled in from each of 2 backbones, and reselling those to my L3 providers (again at cost recovery pricing), while not precluding any provider wanting to haul in their own uplink from doing so. 5) There's a possiblity my college campus may be on I2 (or want to); perhaps I can facilitate that as well -- and possible (again, policies permitting) extend such connections to relevant staff members or students who live in the city) (I'm not as familiar with I2 as I should be). 6) And pursuant to 3, perhaps I could even set up the IPTV service and resell that to the L3 provider to bundle with their IP service, so they don't have to do it themselves; while it's not a difficult as I had gathered, it's still harder than them doing VoIP as part of their own triple-play. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From bross at pobox.com Sat Feb 2 22:27:41 2013 From: bross at pobox.com (Brandon Ross) Date: Sat, 2 Feb 2013 17:27:41 -0500 (EST) Subject: Fwd: Rollup: Small City Municipal Broadband In-Reply-To: References: <24683668.4644.1359839500973.JavaMail.root@benjamin.baylink.com> Message-ID: On Sat, 2 Feb 2013, Scott Helms wrote: > I'd also talk with Zhone, Allied Telesys, Adtran, and Cisco if for no > other reason but get the best pricing you can. I can't believe I'm going to beat Owen to this point, but considering you a building a brand new infrastructure, I'd hope you'd support your service provider's stakeholders if they want to do IPv6. To do so securely, you'll want your neutral layer 2 infrastrcuture to at least support RA-guard and DHCPv6 shield. You might also want/need DHCPv6 PD snooping, MLD snooping. We have found VERY disappointing support for these features in this type of gear. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From bross at pobox.com Sat Feb 2 22:40:13 2013 From: bross at pobox.com (Brandon Ross) Date: Sat, 2 Feb 2013 17:40:13 -0500 (EST) Subject: Followup: Small City Municipal Broadband In-Reply-To: <5680273.4658.1359844017052.JavaMail.root@benjamin.baylink.com> References: <5680273.4658.1359844017052.JavaMail.root@benjamin.baylink.com> Message-ID: On Sat, 2 Feb 2013, Jay Ashworth wrote: > 6) And pursuant to 3, perhaps I could even set up the IPTV service and > resell that to the L3 provider to bundle with their IP service, so > they don't have to do it themselves; while it's not a difficult as I > had gathered, it's still harder than them doing VoIP as part of their > own triple-play. So you are going to prohibit the operator of the fiber plant from running layer 3 services, but then turn around and let them offer IPTV? That seems quite inconsistent to me. And just because it's "hard"? Running a decent layer 3 service is "hard" too. Isn't the whole point to let these service providers compete with each other on the quality and cost of their services? -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From owen at delong.com Sat Feb 2 22:41:23 2013 From: owen at delong.com (Owen DeLong) Date: Sat, 2 Feb 2013 14:41:23 -0800 Subject: Followup: Small City Municipal Broadband In-Reply-To: <5680273.4658.1359844017052.JavaMail.root@benjamin.baylink.com> References: <5680273.4658.1359844017052.JavaMail.root@benjamin.baylink.com> Message-ID: <4BD69E9F-2500-4E8D-9656-979E6A42FBD9@delong.com> On Feb 2, 2013, at 2:26 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Jay Ashworth" > >> It's about 3 square miles, and has about 8000 passings, the majority >> of which are single or double family residential; a sprinkling of >> multi-tenant, about a dozen city facilities, and a bunch of retail >> multi-unit business. > > I was musing, off-list, as to why there isn't a Mad-Lib you can just plug > some numbers into and get within, say, 40% or so of your target costs for > a given design. > > Well, > > http://www.ftthcommunitytoolkit.wikispaces.net > > isn't it, but it does have a bunch of useful information for this project, > looks like. > > A couple of clarifying points: > > 1) I had posited GPON as I assumed that was where most of the CATV over > FTTH hardware work was, vice FiOS. Turns out there's lots of hardware for > IPTV as well, and quite a number of smaller deployments, so apparently > that path is easier than I thought. The only difference is cross-connect > fiber counts, and possibly some link budget. > > 2) I was planning to provide an IX switch in my colo, so all my L3 providers > could short-circuit traffic to my *other* providers through it, unloading > my uplinks. > > 3) Given that, I suppose I could put Limelight and Akamai racks in there, > and couple them to the IX switch as well, policies permitting. > > 4) Given what a pisser it's going to be to get tags to me on the local > backbone loops (about 3 are with 5 miles of my city border), I'm also > considering having a 10G or 2 hauled in from each of 2 backbones, and > reselling those to my L3 providers (again at cost recovery pricing), > while not precluding any provider wanting to haul in their own uplink > from doing so. > A better model, IMHO, is to encourage the backbones to come meet your providers at your IX/Colo. > 5) There's a possiblity my college campus may be on I2 (or want to); > perhaps I can facilitate that as well -- and possible (again, policies > permitting) extend such connections to relevant staff members or students > who live in the city) (I'm not as familiar with I2 as I should be). Do some research before you pursue this too vocally or commit to it. > 6) And pursuant to 3, perhaps I could even set up the IPTV service and > resell that to the L3 provider to bundle with their IP service, so > they don't have to do it themselves; while it's not a difficult as I > had gathered, it's still harder than them doing VoIP as part of their > own triple-play. Pandora's can of worms. Owen From khelms at zcorum.com Sat Feb 2 22:47:37 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 2 Feb 2013 17:47:37 -0500 Subject: Fwd: Rollup: Small City Municipal Broadband In-Reply-To: References: <24683668.4644.1359839500973.JavaMail.root@benjamin.baylink.com> Message-ID: That's one of the reasons to look at active ethernet over gpon. There is much more of a chance to do v6 on that gear, especially cisco's Metro ethernet switches. On Feb 2, 2013 5:27 PM, "Brandon Ross" wrote: > On Sat, 2 Feb 2013, Scott Helms wrote: > > I'd also talk with Zhone, Allied Telesys, Adtran, and Cisco if for no >> other reason but get the best pricing you can. >> > > I can't believe I'm going to beat Owen to this point, but considering you > a building a brand new infrastructure, I'd hope you'd support your service > provider's stakeholders if they want to do IPv6. To do so securely, you'll > want your neutral layer 2 infrastrcuture to at least support RA-guard and > DHCPv6 shield. You might also want/need DHCPv6 PD snooping, MLD snooping. > We have found VERY disappointing support for these features in this type > of gear. > > -- > Brandon Ross Yahoo & AIM: > BrandonNRoss > +1-404-635-6667 ICQ: > 2269442 > Schedule a meeting: https://doodle.com/bross Skype: > brandonross > From jra at baylink.com Sat Feb 2 22:57:23 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 17:57:23 -0500 (EST) Subject: Followup: Small City Municipal Broadband In-Reply-To: Message-ID: <27718515.4664.1359845843748.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brandon Ross" > > 6) And pursuant to 3, perhaps I could even set up the IPTV service and > > resell that to the L3 provider to bundle with their IP service, so > > they don't have to do it themselves; while it's not a difficult as I > > had gathered, it's still harder than them doing VoIP as part of > > their own triple-play. > > So you are going to prohibit the operator of the fiber plant from > running layer 3 services, but then turn around and let them offer IPTV? That > seems quite inconsistent to me. And just because it's "hard"? No; I wouldn't offer it retail; I'd offer it to all provider-comers wholesale, at cost plus, just like everything else. > Running a decent layer 3 service is "hard" too. Isn't the whole point to > let these service providers compete with each other on the quality and > cost of their services? You could say the same thing about the uplink, though; I note you didn't throw a flag at that, or at Akamai; is the IPTV issue different to you? Fair point. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Sat Feb 2 23:02:18 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 18:02:18 -0500 (EST) Subject: Rollup: Small City Municipal Broadband In-Reply-To: Message-ID: <13960771.4668.1359846138233.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brandon Ross" > I can't believe I'm going to beat Owen to this point, but considering you > a building a brand new infrastructure, I'd hope you'd support your service > provider's stakeholders if they want to do IPv6. To do so securely, > you'll want your neutral layer 2 infrastrcuture to at least support > RA-guard and DHCPv6 shield. You might also want/need DHCPv6 PD > snooping, MLD snooping. We have found VERY disappointing support for these > features in this type of gear. IPv6 would be on my ticklist, yes. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Sat Feb 2 23:03:15 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 18:03:15 -0500 (EST) Subject: Followup: Small City Municipal Broadband In-Reply-To: <27718515.4664.1359845843748.JavaMail.root@benjamin.baylink.com> Message-ID: <15903276.4670.1359846195258.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jay Ashworth" > > So you are going to prohibit the operator of the fiber plant from > > running layer 3 services, but then turn around and let them offer > > IPTV? That seems quite inconsistent to me. And just because it's "hard"? > > No; I wouldn't offer it retail; I'd offer it to all provider-comers > wholesale, at cost plus, just like everything else. It's just been pointed out to me that I can farm that out. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From bross at pobox.com Sat Feb 2 23:14:56 2013 From: bross at pobox.com (Brandon Ross) Date: Sat, 2 Feb 2013 18:14:56 -0500 (EST) Subject: Followup: Small City Municipal Broadband In-Reply-To: <27718515.4664.1359845843748.JavaMail.root@benjamin.baylink.com> References: <27718515.4664.1359845843748.JavaMail.root@benjamin.baylink.com> Message-ID: On Sat, 2 Feb 2013, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Brandon Ross" > >>> 6) And pursuant to 3, perhaps I could even set up the IPTV service and >>> resell that to the L3 provider to bundle with their IP service, so >>> they don't have to do it themselves; while it's not a difficult as I >>> had gathered, it's still harder than them doing VoIP as part of >>> their own triple-play. >> >> So you are going to prohibit the operator of the fiber plant from >> running layer 3 services, but then turn around and let them offer IPTV? That >> seems quite inconsistent to me. And just because it's "hard"? > > No; I wouldn't offer it retail; I'd offer it to all provider-comers > wholesale, at cost plus, just like everything else. It sure seems like just pushing the competition (or lack thereof) up the stack. >> Running a decent layer 3 service is "hard" too. Isn't the whole point to >> let these service providers compete with each other on the quality and >> cost of their services? > > You could say the same thing about the uplink, Which uplink is that? I'm a little confused. > though; I note you didn't throw a flag at that, or at Akamai; is the > IPTV issue different to you? If you were to open your colo to all comers that have similar models to Akamai, that seems fair. After all, it's not the city selling Akamai services to either the ISPs or end-users, the city is just providing a convenient way for the providers that are there to interconnect with content providers that care to show up. Now if you were to encourage an IPTV services provider that WASN'T the city to co-locate at the facility, that seems reasonable as long as terms were even if another one wanted to show up. I could imagine that some might sell service direct retail, others might go wholesale with one of the other service providers. Maybe both? This whole thing is the highway analogy to me. The fiber is the road. The city MIGHT build a rest stop (layer 2), but shouldn't be allowed to either be in the trucking business (layer 3), nor in the business of manufacturing the products that get shipped over the road (IPTV, VOIP, etc.), and the same should apply to the company that maintains the fiber, if it's outsourced. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From bicknell at ufp.org Sat Feb 2 23:30:05 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 2 Feb 2013 15:30:05 -0800 Subject: Followup: Small City Municipal Broadband In-Reply-To: References: <27718515.4664.1359845843748.JavaMail.root@benjamin.baylink.com> Message-ID: <20130202233005.GA12783@ussenterprise.ufp.org> In a message written on Sat, Feb 02, 2013 at 06:14:56PM -0500, Brandon Ross wrote: > This whole thing is the highway analogy to me. The fiber is the road. > The city MIGHT build a rest stop (layer 2), but shouldn't be allowed to > either be in the trucking business (layer 3), nor in the > business of manufacturing the products that get shipped over the road > (IPTV, VOIP, etc.), and the same should apply to the company that > maintains the fiber, if it's outsourced. I think your analogy is largely correct (I'm not sure Rest Stop == Layer 2 is perfect, but close enough), but it is a very important way of describing things to a non-technical audience. FTTH should operate like roads in many respects. From ownership and access, to how the network is expanded. For instance a new neighborhood would see the developer build both the roads and fiber to specifications, and then turn them over to the municipality. Same model. Having multiple people build the infrastructure would be just as inefficeint as if every house had two roads built to it by two private companies. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jra at baylink.com Sun Feb 3 00:31:54 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 19:31:54 -0500 (EST) Subject: Followup: Small City Municipal Broadband In-Reply-To: <31177951.4672.1359851499441.JavaMail.root@benjamin.baylink.com> Message-ID: <17907601.4674.1359851514092.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brandon Ross" > > No; I wouldn't offer it retail; I'd offer it to all provider-comers > > wholesale, at cost plus, just like everything else. > > It sure seems like just pushing the competition (or lack thereof) up > the stack. Could be. To compete with Roadrunner, people will have to do triple play, and the CATV is the hard part. If someone else is already doing the aggregation, I'm good with that. > >> Running a decent layer 3 service is "hard" too. Isn't the whole > >> point to > >> let these service providers compete with each other on the quality > >> and > >> cost of their services? > > > > You could say the same thing about the uplink, > > Which uplink is that? I'm a little confused. My colo's uplinks to the world, which were one of three things I proposed offering at wholesale to ISPs. > > though; I note you didn't throw a flag at that, or at Akamai; is the > > IPTV issue different to you? > > If you were to open your colo to all comers that have similar models > to Akamai, that seems fair. After all, it's not the city selling Akamai > services to either the ISPs or end-users, the city is just providing a > convenient way for the providers that are there to interconnect with > content providers that care to show up. Precisely. Akamai's business model is that they just show up? Me and my ISPs don't have to pay them? > Now if you were to encourage an IPTV services provider that WASN'T the > city to co-locate at the facility, that seems reasonable as long as terms > were even if another one wanted to show up. I could imagine that some > might sell service direct retail, others might go wholesale with one of > the other service providers. Maybe both? Perhaps; yeah. > This whole thing is the highway analogy to me. The fiber is the road. > The city MIGHT build a rest stop (layer 2), but shouldn't be allowed > to either be in the trucking business (layer 3), nor in the > business of manufacturing the products that get shipped over the road > (IPTV, VOIP, etc.), and the same should apply to the company that > maintains the fiber, if it's outsourced. Ok, fair point. My goal in IX and Akamai was "unload my uplinks". The bigger my downlinks are, the more I will care. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Sun Feb 3 00:45:12 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 19:45:12 -0500 (EST) Subject: Followup: Small City Municipal Broadband In-Reply-To: <20130202233005.GA12783@ussenterprise.ufp.org> Message-ID: <8426181.4682.1359852312829.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Leo Bicknell" > Having multiple people build the infrastructure would be just as > inefficeint as if every house had two roads built to it by two private > companies. I was going to trot on the Manhattan 26-crossbuck telephone pole, and multiple power wires and water pipes, but roads is *much* better. Especially since my dad did this in the 70s, and I am a *big* fan of The Dwight D Eisenhower System of Interstate and Defense Highways. Yes, the Interstate System has a home page: https://www.fhwa.dot.gov/interstate/homepage.cfm Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From bross at pobox.com Sun Feb 3 00:52:58 2013 From: bross at pobox.com (Brandon Ross) Date: Sat, 2 Feb 2013 19:52:58 -0500 (EST) Subject: Followup: Small City Municipal Broadband In-Reply-To: <17907601.4674.1359851514092.JavaMail.root@benjamin.baylink.com> References: <17907601.4674.1359851514092.JavaMail.root@benjamin.baylink.com> Message-ID: On Sat, 2 Feb 2013, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Brandon Ross" > >>>> Running a decent layer 3 service is "hard" too. Isn't the whole >>>> point to >>>> let these service providers compete with each other on the quality >>>> and >>>> cost of their services? >>> >>> You could say the same thing about the uplink, >> >> Which uplink is that? I'm a little confused. > > My colo's uplinks to the world, which were one of three things I proposed > offering at wholesale to ISPs. I guess I missed that. You are saying that you would aggregate/resell transit bandwidth in your colo? I would argue against that as well. I'd suggest making sure your colo had adequate entrance facilities to allow whomever wants to provide upstream service there to show up, and allow them access to the fiber, which you already effectively have done. >>> though; I note you didn't throw a flag at that, or at Akamai; is the >>> IPTV issue different to you? >> >> If you were to open your colo to all comers that have similar models >> to Akamai, that seems fair. After all, it's not the city selling Akamai >> services to either the ISPs or end-users, the city is just providing a >> convenient way for the providers that are there to interconnect with >> content providers that care to show up. > > Precisely. Akamai's business model is that they just show up? Me and > my ISPs don't have to pay them? I guess as far as putting an Akamai server in a colo/on an exchange, I assumed they didn't charge, but now that you mention it, I don't have first hand knowledge of that. I certainly would suggest that the city should not pay for anyone to show up at the colo, but allow them access if they care to do so on equal footing. Of course Akamai charges for their services, that's a bit different than just exchanging traffic. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From khelms at zcorum.com Sun Feb 3 01:06:06 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 2 Feb 2013 20:06:06 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> References: <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> Message-ID: Owen, I think the confusion I have is that you seem to want to create solutions for problems that have already been solved. There is no cost effective method of sharing a network at layer 1 since DWDM is expensive and requires compatible gear on both sides and no one has enough fiber (nor is cheap enough in brand new builds) to simply home run every home and maintain that. ISPs that would want to use the shared network in general (>95% in my experience) don't want to maintain the access gear and since there is no clear way to delineate responsibilities when there is an issue its hard. The long and short of it is lots of people have tried to L1 sharing and its not economical and nothing I've seen here or elsewhere changes that. The thing you have to remember is that muni networks have to be cost effective and that's not just the capital costs. The operational cost in the long term is much greater than the cost of initial gear and fiber install. On Feb 2, 2013 4:54 PM, "Owen DeLong" wrote: > It seems that you are (deliberately or otherwise) seriously misconstruing > what I am saying. > > I'm saying that if you build an L1 dark fiber system as we have described, > the purchasers can use it to deploy Ethernet, PON, or any other technology. > > I'm not saying it's how I would build out a PON only system. That was > never the goal. > > The goal is to provide a municipal L1 service that can be used by ANY > provider for ANY service, or as close to that as possible. > > To make the offering more attractive to low-budget providers, the system > may also incorporate some L2 services. > > Owen > > On Feb 2, 2013, at 1:31 PM, Scott Helms wrote: > > Owen, > > Cross connecting at layer 1 is what I'm saying isn't feasible. If you > want to simply hand them a fiber then sell dark fiber or DWDM ports but > trying to create an architecture around PON or other splitters won't work > because PON splitters aren't compatible with other protocols. > > > On Sat, Feb 2, 2013 at 4:26 PM, Owen DeLong wrote: > >> >> On Feb 2, 2013, at 12:07 PM, Scott Helms wrote: >> >> Owen, >> >> A layer 1 architecture isn't going to be an economical option for the >> foreseeable future so opining on its value is a waste of time...its simple >> not feasible now or even 5 years from now because of costs. The optimal >> open access network (with current or near future technology) is well known. >> Its called Ethernet and the methods to do triple play and open access are >> well documented not to mention already in wide spread use. Trying to >> enforce a layer 1 approach would be more expensive than the attempts to >> make this work with Packet Over SONET or even ATM. >> >> What is about a normal Ethernet deployment that you see as a negative? >> What problem are you tying to solve? >> >> >> Ethernet works just fine in the L1 solution I've proposed, so I'm not >> sure why you say it isn't economically viable to do so. >> >> Owen >> >> >> On Sat, Feb 2, 2013 at 1:04 PM, Owen DeLong wrote: >> >>> >>> On Feb 2, 2013, at 2:19 AM, Eugen Leitl wrote: >>> >>> > On Fri, Feb 01, 2013 at 04:43:56PM -0800, Leo Bicknell wrote: >>> > >>> >> The only place PON made any sense to me was extreme rural areas. >>> >> If you could go 20km to a splitter and then hit 32 homes ~1km away >>> >> (52km fiber pair length total), that was a win. If the homes are >>> >> 2km from the CO, 32 pair (64km fiber pair length total) of home >>> >> runs was cheaper than the savings on fiber, and then the cost of >>> >> GPON splitters and equipment. I'm trying to figure out if my >>> assessment >>> >> is correct or not... >>> > >>> > Is there any specific reason why muni networks don't use 1-10 GBit >>> > fiber mesh, using L3 switches in DSLAMs on every street corner? >>> >>> Well, one reason is that, IMHO, the goal here is to provide a flexible >>> L1 platform that will allow multiple competing providers a low barrier >>> to entry to provide a multitude of competitive services. >>> >>> Owen >>> >>> >>> >> >> >> -- >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> >> > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > From khelms at zcorum.com Sun Feb 3 01:08:39 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 2 Feb 2013 20:08:39 -0500 Subject: Followup: Small City Municipal Broadband In-Reply-To: <27718515.4664.1359845843748.JavaMail.root@benjamin.baylink.com> References: <27718515.4664.1359845843748.JavaMail.root@benjamin.baylink.com> Message-ID: Jay, While its certainly technically possible to offer linear video in a shared network model the content owners have big objections of that. There really is no way to do wholesale IPTV except for a very few organizations like the cable coop (NCTC http://www.nctconline.org/). On Sat, Feb 2, 2013 at 5:57 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Brandon Ross" > > > > 6) And pursuant to 3, perhaps I could even set up the IPTV service and > > > resell that to the L3 provider to bundle with their IP service, so > > > they don't have to do it themselves; while it's not a difficult as I > > > had gathered, it's still harder than them doing VoIP as part of > > > their own triple-play. > > > > So you are going to prohibit the operator of the fiber plant from > > running layer 3 services, but then turn around and let them offer IPTV? > That > > seems quite inconsistent to me. And just because it's "hard"? > > No; I wouldn't offer it retail; I'd offer it to all provider-comers > wholesale, at cost plus, just like everything else. > > > Running a decent layer 3 service is "hard" too. Isn't the whole point to > > let these service providers compete with each other on the quality and > > cost of their services? > > You could say the same thing about the uplink, though; I note you didn't > throw a flag at that, or at Akamai; is the IPTV issue different to you? > > Fair point. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Sun Feb 3 01:16:41 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 20:16:41 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: Message-ID: <16365898.4692.1359854201449.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > Owen > I think the confusion I have is that you seem to want to create solutions > for problems that have already been solved. There is no cost effective > method of sharing a network at layer 1 since DWDM is expensive and requires > compatible gear on both sides and no one has enough fiber (nor is cheap > enough in brand new builds) to simply home run every home and maintain > that. That's my fundamental design assumption, and you're the first person to throw a flag on it. I'm hearing $700 per passing and $600 per sub; those seem sustainable numbers for a 30 year service life amortization. I'm not yet 100% clear if that's layer 1 only or layer 2 agg as well. [ And note that for me, it's practical; most everyone else is merely along for the ride. ] > ISPs that would want to use the shared network in general (>95% > in my experience) don't want to maintain the access gear and since there > is no clear way to delineate responsibilities when there is an issue its > hard. You're talking about what I'm calling L2 clients. If layer 2 falls over it's my fault, and believe me, I'll know about it. > The long and short of it is lots of people have tried to L1 sharing > and its > not economical and nothing I've seen here or elsewhere changes that. You just changed gears again, no? I'm not trying to share L1 *drops*. I'm trying to make it possible to share *the entire L1 deployment between providers*, a drop at a time. > The thing you have to remember is that muni networks have to be cost > effective > and that's not just the capital costs. The operational cost in the long > term is much greater than the cost of initial gear and fiber install. Depends on what you're trying to do. But yes, I do know the difference between CAPEX and OPEX. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From rs at seastrom.com Sun Feb 3 01:20:31 2013 From: rs at seastrom.com (Robert E. Seastrom) Date: Sat, 02 Feb 2013 20:20:31 -0500 Subject: Muni network ownership and the Fourth In-Reply-To: <4DF0E2E7-B8EB-4E2E-B006-FFE000DDE80A@delong.com> (Owen DeLong's message of "Tue, 29 Jan 2013 22:10:38 -0800") References: <26775108.4177.1359473378307.JavaMail.root@benjamin.baylink.com> <18632615.4181.1359475171554.JavaMail.root@benjamin.baylink.com> <20130129170500.GA38295@ussenterprise.ufp.org> <60FA8A1C-DF38-4FC2-83F3-4B10660A013F@delong.com> <20130130030319.GB55895@ussenterprise.ufp.org> <5108A1F0.6020805@vaxination.ca> <4DF0E2E7-B8EB-4E2E-B006-FFE000DDE80A@delong.com> Message-ID: <864nhury5c.fsf@seastrom.com> Owen DeLong writes: > On Jan 29, 2013, at 20:30 , Jean-Francois Mezei wrote: > >> On 13-01-29 22:03, Leo Bicknell wrote: >> >>> The _muni_ should not run any equipment colo of any kind. The muni >>> MMR should be fiber only, and not even require so much as a generator >>> to work. It should not need to be staffed 24x7, have anything that >>> requires PM, etc. >> >> This is not possible in a GPON system. The OLT has to be carrier neutral >> so that different carriers can connect to it. It is the last point of >> aggregation before reaching homes. >> >> Otherwise, you would need to run multiple strands to each splitter box >> and inside run as many splitters as there are ISPs so that one home an >> be connect to the splitter used by ISP-1 while the next home's strand is >> connected to another splitter associated with ISP-2. This gets complicated. >> > > Why can't the splitters be in the MMR? (I'm genuinely asking... I confess > to a certain level of GPON ignorance). Sorry for being late to the party (real work and all that). There is no reason whatsoever that one can't have centralized splitters in one's PON plant. The additional costs to do so are pretty much just limited to higher fiber counts in the field, which adds, tops, a couple of percent to the price of the build. More than offset by futureproofing and not requiring forklift upgrades to add a new technology for a few customers. Obviously the splitters should be owned by the service provider and upstream of the mega-patch-bay for a muni open access system. Meanwhile, EPON seems to be the technology that's won out on a global basis. Might have something to do with the price - all the hooks to support legacy ATM stuff in GPON's GEM come at a cost. :-) -r PS: Back in the mid-90s, I used to fantasize about being able to say "legacy ATM". From khelms at zcorum.com Sun Feb 3 01:36:00 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 2 Feb 2013 20:36:00 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <16365898.4692.1359854201449.JavaMail.root@benjamin.baylink.com> References: <16365898.4692.1359854201449.JavaMail.root@benjamin.baylink.com> Message-ID: > > > Owen > > I think the confusion I have is that you seem to want to create solutions > > for problems that have already been solved. There is no cost effective > > method of sharing a network at layer 1 since DWDM is expensive and > requires > > compatible gear on both sides and no one has enough fiber (nor is cheap > > enough in brand new builds) to simply home run every home and maintain > > that. > > That's my fundamental design assumption, and you're the first person to > throw a flag on it. I'm hearing $700 per passing and $600 per sub; those > seem sustainable numbers for a 30 year service life amortization. > > I'm not yet 100% clear if that's layer 1 only or layer 2 agg as well. > OK, think about it like this. The most efficient topology to provide both coverage and resiliency is a ring with nodes (shelves) from which end users are connected. That ring (usually Gig or 10Gig Ethernet today) needs to be connected to a central location so you can interconnect to other providers (your ISP customers) and/or to connect to the Internet if the city is also going to provide direct L3 services. If you instead push down a L1 path then the most expensive pieces of gear in the access network (the FTTx shelves) have to be replicated by everyone who wants to offer services. This bad not just from the initial cost perspective but because people and companies that identify themselves as ISPs seldom know anything beyond Ethernet and IP and then only in a few manufacturers (mainly Cisco and Juniper). They are most certainly not comfortable working with Calix, Adtran, and the rest of the carrier (formerly telco) equipment manufacturers. To make matters more complicated in cases of problems you don't have a good demarcation of responsibility. What do you do as the L1 provider when one of your ISP partners tells you one of his customers can't connect or stay connected to that ISP's gear? Whose responsible in that case? What happens when your tech goes out with an OTDR ( http://en.wikipedia.org/wiki/Optical_time-domain_reflectometer) meter and says the connection is fine but your ISP insists its your problem? > > [ And note that for me, it's practical; most everyone else is merely > along for the ride. ] > > > ISPs that would want to use the shared network in general (>95% > > in my experience) don't want to maintain the access gear and since there > > is no clear way to delineate responsibilities when there is an issue its > > hard. > > You're talking about what I'm calling L2 clients. If layer 2 falls over > it's my fault, and believe me, I'll know about it. > What I'm telling you is that you can't reliably have L1 clients in shared model. You can of course lease someone a dark fiber from point A to point B, but that's not a traditional way of partnering with ISPs and in any case will only be feasible for a small number of connections since you (probably) can't afford to home run each location in your network. > > > The long and short of it is lots of people have tried to L1 sharing > > and its > > not economical and nothing I've seen here or elsewhere changes that. > > You just changed gears again, no? > > I'm not trying to share L1 *drops*. I'm trying to make it possible > to share *the entire L1 deployment between providers*, a drop at a time. > That's what I'm trying to tell you can't do. Its more expensive in both the initial and long term costs. > > > The thing you have to remember is that muni networks have to be cost > > effective > > and that's not just the capital costs. The operational cost in the long > > term is much greater than the cost of initial gear and fiber install. > > Depends on what you're trying to do. But yes, I do know the difference > between CAPEX and OPEX. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Sun Feb 3 01:51:55 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 20:51:55 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: Message-ID: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > > > Owen > > > I think the confusion I have is that you seem to want to create > > > solutions > > > for problems that have already been solved. There is no cost > > > effective > > > method of sharing a network at layer 1 since DWDM is expensive and > > requires > > > compatible gear on both sides and no one has enough fiber (nor is > > > cheap > > > enough in brand new builds) to simply home run every home and > > > maintain > > > that. > > > > That's my fundamental design assumption, and you're the first person to > > throw a flag on it. I'm hearing $700 per passing and $600 per sub; those > > seem sustainable numbers for a 30 year service life amortization. > > > > I'm not yet 100% clear if that's layer 1 only or layer 2 agg as > > well. > > OK, think about it like this. The most efficient topology to provide both > coverage and resiliency is a ring with nodes (shelves) from which end users > are connected. That ring (usually Gig or 10Gig Ethernet today) needs to be > connected to a central location so you can interconnect to other providers > (your ISP customers) and/or to connect to the Internet if the city is > also going to provide direct L3 services. If you instead push down a L1 > path then the most expensive pieces of gear in the access network (the FTTx > shelves) have to be replicated by everyone who wants to offer > services. In short, you're saying I *must* have a ring with active equipment scattered around it, and I *cannot* home run each property. No one else is saying that, and you don't appear to justify it later in this email: > This bad not just from the initial cost perspective but because people > and companies that identify themselves as ISPs seldom know anything beyond > Ethernet and IP and then only in a few manufacturers (mainly Cisco and > Juniper). They are most certainly not comfortable working with Calix, > Adtran, and the rest of the carrier (formerly telco) equipment > manufacturers. Well, ok, but those people who are not comfortable handling access gear like the Calix will be L2 clients, anyway, taking a groomed 802.1q handoff from my Calix/whatever core, so they won't *have* to care. L1 access will be there a) cause it has to be anyway, to keep active equipment out of the outside plant, b) for people who really want PtP, and 3) for ISPs large enough to want to do it themselves, if any show up (they admittedly might not; we're only 6k households). > To make matters more complicated in cases of problems > you don't have a good demarcation of responsibility. What do you do as the > L1 provider when one of your ISP partners tells you one of his customers > can't connect or stay connected to that ISP's gear? Whose responsible in > that case? Well that's an interesting question, but I don't see that it's not orthogonal to the issue you raised earlier. > What happens when your tech goes out with an OTDR ( > http://en.wikipedia.org/wiki/Optical_time-domain_reflectometer) meter > and says the connection is fine but your ISP insists its your problem? On an L1 connection, you mean? I'll do what people always do; I'll work the ticket; at that level, this stuff's relatively digital, no? > > You're talking about what I'm calling L2 clients. If layer 2 falls > > over it's my fault, and believe me, I'll know about it. > > What I'm telling you is that you can't reliably have L1 clients in > shared model. You're telling me that, but you're not giving me good reasons *why* you think so. > You can of course lease someone a dark fiber from point A to point > B, but that's not a traditional way of partnering with ISPs and in any > case will only be feasible for a small number of connections since you > (probably) can't afford to home run each location in your network. Well, I'll have to see on that, won't I? That's my next practicality checkpoint; fiber passing costs. > > > The long and short of it is lots of people have tried to L1 > > > sharing and its > > > not economical and nothing I've seen here or elsewhere changes > > > that. > > > > You just changed gears again, no? > > > > I'm not trying to share L1 *drops*. I'm trying to make it possible > > to share *the entire L1 deployment between providers*, a drop at a > > time. > That's what I'm trying to tell you can't do. Its more expensive in > both the initial and long term costs. I can see 'initial', maybe, but if I reduce the utility of the field network by putting active equipment in it, then I've already raised the OPEX, substantially, as well as reducing the intrinsic value of that network. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Sun Feb 3 01:55:34 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 20:55:34 -0500 (EST) Subject: Muni network ownership and the Fourth In-Reply-To: <864nhury5c.fsf@seastrom.com> Message-ID: <10887966.4706.1359856534239.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Robert E. Seastrom" > > Why can't the splitters be in the MMR? (I'm genuinely asking... I > > confess to a certain level of GPON ignorance). > > Sorry for being late to the party (real work and all that). > > There is no reason whatsoever that one can't have centralized > splitters in one's PON plant. The additional costs to do so are > pretty much just limited to higher fiber counts in the field, which > adds, tops, a couple of percent to the price of the build. Ok, see, this is what Leo, Owen and I all think, and maybe a couple others. But Scott just got done telling me it's *so* much more expensive to home-run than ring or GPON-in-pedestals that it's commercially infeasible. > More than > offset by futureproofing and not requiring forklift upgrades to add a > new technology for a few customers. Obviously the splitters should be > owned by the service provider and upstream of the mega-patch-bay for a > muni open access system. Well, I would assume the splitters have to be compatible with the OLT/ONT chosen by a prospective L1 client, no? Or is GPON GPON, which is GPON? > Meanwhile, EPON seems to be the technology that's won out on a global > basis. Might have something to do with the price - all the hooks to > support legacy ATM stuff in GPON's GEM come at a cost. :-) Hmmm. I invite you, Rob, if you have the time, to look at the Rollup and Followup posts I put out this afternoon, which are the look at this which is closest to current in time. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jason at thebaughers.com Sun Feb 3 02:03:52 2013 From: jason at thebaughers.com (Jason Baugher) Date: Sat, 2 Feb 2013 20:03:52 -0600 Subject: Fwd: Rollup: Small City Municipal Broadband In-Reply-To: References: <24683668.4644.1359839500973.JavaMail.root@benjamin.baylink.com> Message-ID: On Feb 2, 2013 3:33 PM, "Scott Helms" wrote: > ...... > This is not correct. DOCSIS is an MPEG stream over QAM or QPSK modulation > and there is nothing about it that is compatible to any flavor of PON. In > fact if you look at the various CableLabs standards you'll see DPoE ( > http://www.cablelabs.com/dpoe/specifications/index.html) which lists how a > DOCSIS system can inter-operate and provision an PON system. If you look at Jay may be referring to something I alluded to earlier, what Calix refers to as RF overlay. The RF signal from the traditional cable system is converted to 1550nm and combined onto the PON before the splitter with a CWDM module. Certain model ONT's split the 1550 back off and convert back to an RF port. From jason at thebaughers.com Sun Feb 3 02:09:44 2013 From: jason at thebaughers.com (Jason Baugher) Date: Sat, 2 Feb 2013 20:09:44 -0600 Subject: Muni network ownership and the Fourth In-Reply-To: <10887966.4706.1359856534239.JavaMail.root@benjamin.baylink.com> References: <864nhury5c.fsf@seastrom.com> <10887966.4706.1359856534239.JavaMail.root@benjamin.baylink.com> Message-ID: On Feb 2, 2013 7:56 PM, "Jay Ashworth" wrote: > .... > Well, I would assume the splitters have to be compatible with the OLT/ONT > chosen by a prospective L1 client, no? Or is GPON GPON, which is GPON? > Splitters are passive. They only split light. They care not what information the light is carrying. From bicknell at ufp.org Sun Feb 3 02:12:28 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 2 Feb 2013 18:12:28 -0800 Subject: Muni network ownership and the Fourth In-Reply-To: <10887966.4706.1359856534239.JavaMail.root@benjamin.baylink.com> References: <864nhury5c.fsf@seastrom.com> <10887966.4706.1359856534239.JavaMail.root@benjamin.baylink.com> Message-ID: <20130203021228.GA16918@ussenterprise.ufp.org> In a message written on Sat, Feb 02, 2013 at 08:55:34PM -0500, Jay Ashworth wrote: > > From: "Robert E. Seastrom" > > There is no reason whatsoever that one can't have centralized > > splitters in one's PON plant. The additional costs to do so are > > pretty much just limited to higher fiber counts in the field, which > > adds, tops, a couple of percent to the price of the build. > > Ok, see, this is what Leo, Owen and I all think, and maybe a couple others. > > But Scott just got done telling me it's *so* much more expensive to > home-run than ring or GPON-in-pedestals that it's commercially infeasible. Note, both are right, depending on the starting point and goals. Historically teclos have installed (relatively) low count fiber cables, based on a fiber to the pedistal and copper to the prem strategy. If you have one of these existing deployments, the cost of home run fiber (basically starting the fiber build from scratch, since the count is so low) is more expensive, and much greater cost than deploying GPON or similar over the existing plant. However, that GPON equipment will have a lifespan of 7-20 years. In a greenfield scenario where there is no fiber in the ground the cost is in digging the trench. The fiber going into it is only ~5% of the cost, and going from a 64 count fiber to a 864 count fiber only moves that to 7-8%. The fiber has a life of 40-80 years, and thus adding high count is cheaper than doing low count with GPON. Existing builds are optimizing to avoid sending out the backhoe and directional boring machine. New builds, or extreme forward thinking builds are trying to send them out once and never again. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From khelms at zcorum.com Sun Feb 3 02:28:06 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 2 Feb 2013 21:28:06 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> References: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> Message-ID: > > > > OK, think about it like this. The most efficient topology to provide both > > coverage and resiliency is a ring with nodes (shelves) from which end > users > > are connected. That ring (usually Gig or 10Gig Ethernet today) needs to > be > > connected to a central location so you can interconnect to other > providers > > (your ISP customers) and/or to connect to the Internet if the city is > > also going to provide direct L3 services. If you instead push down a L1 > > path then the most expensive pieces of gear in the access network (the > FTTx > > shelves) have to be replicated by everyone who wants to offer > > services. > > In short, you're saying I *must* have a ring with active equipment > scattered around it, and I *cannot* home run each property. > > No one else is saying that, and you don't appear to justify it later > in this email: > I'm not saying that you have to, but that's the most efficient and resilient (both of those are important right?) way of arranging the gear. The exact loop length from the shelves to the end users is up to you and in certain circumstances (generally really compact areas) you can simply home run everyone. Most muni networks don't look that way though because while town centers are generally compact where people (especially the better subdivisions) live is away from the center of town in the US. I can't give you a lot insight on your specific area since I don't know it, but those are the general rules. > > > This bad not just from the initial cost perspective but because people > > and companies that identify themselves as ISPs seldom know anything > beyond > > Ethernet and IP and then only in a few manufacturers (mainly Cisco and > > Juniper). They are most certainly not comfortable working with Calix, > > Adtran, and the rest of the carrier (formerly telco) equipment > > manufacturers. > > Well, ok, but those people who are not comfortable handling access gear > like the Calix will be L2 clients, anyway, taking a groomed 802.1q handoff > from my Calix/whatever core, so they won't *have* to care. > That works, so long as its an Ethernet hand off you're (usually there is some goofy gear out there) in good shape. > > L1 access will be there a) cause it has to be anyway, to keep active > equipment out of the outside plant, b) for people who really want PtP, > and 3) for ISPs large enough to want to do it themselves, if any show > up (they admittedly might not; we're only 6k households). > Keep in place, but I've worked with virtually all of the nationwide guys and most of the regional ones and they don't as a rule want anything to do with your fiber plant. Even in major metro areas selling dark fiber doesn't have a huge uptake because if you the network owner didn't light it you have no idea how good or bad the splices and runs are. > > > To make matters more complicated in cases of problems > > you don't have a good demarcation of responsibility. What do you do as > the > > L1 provider when one of your ISP partners tells you one of his customers > > can't connect or stay connected to that ISP's gear? Whose responsible in > > that case? > > Well that's an interesting question, but I don't see that it's not > orthogonal to the issue you raised earlier. > > > What happens when your tech goes out with an OTDR ( > > http://en.wikipedia.org/wiki/Optical_time-domain_reflectometer) meter > > and says the connection is fine but your ISP insists its your problem? > > On an L1 connection, you mean? I'll do what people always do; I'll work > the ticket; at that level, this stuff's relatively digital, no? > No, its not and I've seen several of networks fail because demarc issues. US Carrier (a statewide network here in GA) was recently sold for pennies on the dollar largely because of blurry demarcs. You can and will get sucked into scenarios you don't want to be in and will lose money on. > > > > You're talking about what I'm calling L2 clients. If layer 2 falls > > > over it's my fault, and believe me, I'll know about it. > > > > What I'm telling you is that you can't reliably have L1 clients in > > shared model. > > You're telling me that, but you're not giving me good reasons *why* you > think so. > Because: 1) There won't be much interest in doing it from experienced operators so you're only going to get customers for it that are also new to the business. So your combined troubleshooting and install time will be bad for a long time until everyone in the chain kind of understand what they're doing. 2) Unless you can home run every single connection you're going to run into a lot of access related issues. You will be working for the city so they won't have a problem with you getting into their building at the water tower/sewage treatment plant/power sub station or other city owned property. Your L1 customer isn't going to have that access (not with the city manager/mayor/council's knowledge anyway) because of regulatory and liability reasons. If you do home run everything you still have an access challenge (where are you going to be able to give access to these customers economically?) but its probably more solvable since its one spot. You also increase your costs by home running each connection, but that may or may not be a deal breaker in your situation. 3) Your going to have to do a lot more work since at L1 all of the rough edges and sharp corners are there to be dealt (like someone grabbing the wrong cable from the patch panel) there is simply no inexpensive method of safeguarding L1 adds, changes, and modifies so either you do them or you let your L1 customer do them and run a risk. This is also something that the city management is going to have concerned over. 4) Physical layer troubleshooting is much harder than layer 2 and up. Having several organizations and potentially several different equipment vendors and L2 technologies will be very tough to deal with over time. 5) I've seen at least 5 muni networks try this and not succeed. If you include non-muni networks with similar characteristics (like EMCs) then I've seen it tried more than a dozen times with no success (or interest) beyond a few dark fiber set ups for point to point connections across town. > > > You can of course lease someone a dark fiber from point A to point > > B, but that's not a traditional way of partnering with ISPs and in any > > case will only be feasible for a small number of connections since you > > (probably) can't afford to home run each location in your network. > > Well, I'll have to see on that, won't I? That's my next practicality > checkpoint; fiber passing costs. > > > > > The long and short of it is lots of people have tried to L1 > > > > sharing and its > > > > not economical and nothing I've seen here or elsewhere changes > > > > that. > > > > > > You just changed gears again, no? > > > > > > I'm not trying to share L1 *drops*. I'm trying to make it possible > > > to share *the entire L1 deployment between providers*, a drop at a > > > time. > > > That's what I'm trying to tell you can't do. Its more expensive in > > both the initial and long term costs. > > I can see 'initial', maybe, but if I reduce the utility of the field > network by putting active equipment in it, then I've already raised the > OPEX, substantially, as well as reducing the intrinsic value of that > network. > I think you're vastly overestimating the desire that customers have for a bare fiber. Having said that, your community may be different from what I've experienced. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Sun Feb 3 02:29:23 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 2 Feb 2013 21:29:23 -0500 Subject: Fwd: Rollup: Small City Municipal Broadband In-Reply-To: References: <24683668.4644.1359839500973.JavaMail.root@benjamin.baylink.com> Message-ID: Jason, Yeah, that's what I figured. There are lots of older PON deployments that used the modulated RF approach. On Sat, Feb 2, 2013 at 9:03 PM, Jason Baugher wrote: > > On Feb 2, 2013 3:33 PM, "Scott Helms" wrote: > > > ...... > > > This is not correct. DOCSIS is an MPEG stream over QAM or QPSK > modulation > > and there is nothing about it that is compatible to any flavor of PON. > In > > fact if you look at the various CableLabs standards you'll see DPoE ( > > http://www.cablelabs.com/dpoe/specifications/index.html) which lists > how a > > DOCSIS system can inter-operate and provision an PON system. If you look > at > > Jay may be referring to something I alluded to earlier, what Calix refers > to as RF overlay. The RF signal from the traditional cable system is > converted to 1550nm and combined onto the PON before the splitter with a > CWDM module. Certain model ONT's split the 1550 back off and convert back > to an RF port. > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Sun Feb 3 02:33:41 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 2 Feb 2013 21:33:41 -0500 Subject: Muni network ownership and the Fourth In-Reply-To: <20130203021228.GA16918@ussenterprise.ufp.org> References: <864nhury5c.fsf@seastrom.com> <10887966.4706.1359856534239.JavaMail.root@benjamin.baylink.com> <20130203021228.GA16918@ussenterprise.ufp.org> Message-ID: The difference between building a ring and then dropping connections and home running all of the connections is much more than difference in fiber count. However, its certainly true that home running works in some greenfield deployments and I hope I have not confused anyone on that point. A detailed look at the area to be covered along with the goals of the network will definitely drive you in the correct deployment model. This should be one of the first things you do. On Sat, Feb 2, 2013 at 9:12 PM, Leo Bicknell wrote: > In a message written on Sat, Feb 02, 2013 at 08:55:34PM -0500, Jay > Ashworth wrote: > > > From: "Robert E. Seastrom" > > > There is no reason whatsoever that one can't have centralized > > > splitters in one's PON plant. The additional costs to do so are > > > pretty much just limited to higher fiber counts in the field, which > > > adds, tops, a couple of percent to the price of the build. > > > > Ok, see, this is what Leo, Owen and I all think, and maybe a couple > others. > > > > But Scott just got done telling me it's *so* much more expensive to > > home-run than ring or GPON-in-pedestals that it's commercially > infeasible. > > Note, both are right, depending on the starting point and goals. > > Historically teclos have installed (relatively) low count fiber > cables, based on a fiber to the pedistal and copper to the prem > strategy. If you have one of these existing deployments, the cost > of home run fiber (basically starting the fiber build from scratch, > since the count is so low) is more expensive, and much greater cost > than deploying GPON or similar over the existing plant. > > However, that GPON equipment will have a lifespan of 7-20 years. > > In a greenfield scenario where there is no fiber in the ground the > cost is in digging the trench. The fiber going into it is only ~5% > of the cost, and going from a 64 count fiber to a 864 count fiber > only moves that to 7-8%. The fiber has a life of 40-80 years, and > thus adding high count is cheaper than doing low count with GPON. > > Existing builds are optimizing to avoid sending out the backhoe and > directional boring machine. New builds, or extreme forward thinking > builds are trying to send them out once and never again. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From bicknell at ufp.org Sun Feb 3 02:35:07 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 2 Feb 2013 18:35:07 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> Message-ID: <20130203023507.GB16918@ussenterprise.ufp.org> In a message written on Sat, Feb 02, 2013 at 09:28:06PM -0500, Scott Helms wrote: > I'm not saying that you have to, but that's the most efficient and > resilient (both of those are important right?) way of arranging the gear. > The exact loop length from the shelves to the end users is up to you and > in certain circumstances (generally really compact areas) you can simply > home run everyone. Most muni networks don't look that way though because > while town centers are generally compact where people (especially the > better subdivisions) live is away from the center of town in the US. I > can't give you a lot insight on your specific area since I don't know it, > but those are the general rules. If the goal is the minimize the capital outlay of a greenfield build, your model can be more efficient, depending on the geography covered. Basically you're assuming that the active electronics to make a ring are cheaper than building high count fiber back to a central point. There are geographies where that is both true, and not true. I'll give you the benefit of the doubt that you're model is cheaper for a majority of builds. On the other hand, I am not nearly as interested in minimizing the up front capital cost. It's an issue, sure, but I care much more about the total lifecycle cost. I'd rather spend 20% more up front to end up with 20-80% lower costs over 50 years. My argument is not that high count fiber back to a central location is cheaper in absolute, up front dollars, but that it's at worst a minimal amount more and will have neglegable additonal cost over a 40-80 year service life. By contrast, the ring topology you suggest may be slightly less expensive up front, but will require the active parts that make up the ring to be swapped out every 7-20 years. I believe that will lead to greater lifecycle cost; and almost importantly impeed development of new services as the existing gear ends up incompatable with newer technologies. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jeff-kell at utc.edu Sun Feb 3 03:02:42 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Sat, 2 Feb 2013 22:02:42 -0500 Subject: Fwd: Rollup: Small City Municipal Broadband In-Reply-To: References: <24683668.4644.1359839500973.JavaMail.root@benjamin.baylink.com> Message-ID: <510DD352.6010608@utc.edu> This has been a fascinating discussion :) While we don't quite qualify as a small city, we do have quite a dispersion of coverage across our residence halls and general campus. There is an ongoing RFP process to build out our own CATV distribution (or more generally, to avoid the resident CATV provider charge monopoly). Initial competitors included incumbent cable (largely RF coax), new providers (also RF coax), and content-only providers (either assuming we do distribution over our fiber, or add another distribution component), to IPTV solutions (using existing network). IPTV requires a "very co-operative" multicast distribution, which we currently do not have (not exclusive vendor gear end-to-end); it needs to be designed that way from the beginning as opposed to bolted onto the end. RF CATV (or HFC distribution) requires some unique fiber plant... notably AFC terminations as opposed to the UPCs we have for data. And you have to consider one-way content provider network, versus two-way feedback (and the associated set-top box complications we're trying to avoid). And throw in the phone for the other "triple play" component, and you're generally talking PoE[+]. Even in a captive audience, the possibilities are challenging :) Jeff From davidpeahi at gmail.com Sun Feb 3 03:11:52 2013 From: davidpeahi at gmail.com (david peahi) Date: Sat, 2 Feb 2013 19:11:52 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: <20130203023507.GB16918@ussenterprise.ufp.org> References: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> <20130203023507.GB16918@ussenterprise.ufp.org> Message-ID: Technically, any of the architectures espoused by some of the commentators on this thread will work, and would at least be an order of magnitude better than what is available in the local loop today. One of the commentators, however, did underscore the biggest challenge by far to national broadband. (Even the watered down version consisting of a welter of autonomous municipal networks as is the subject of this thread). And that challenge is the stranglehold that incumbent telcos have on the local loop, and their caustic, anti-progress influence in City Halls, Sate Legislatures, and Washington DC. That is why the Australian NBN serves as a good example of how to wrest control of the local loop plant away from the telcos. In many areas of the US a parallel fiber network is already in place, built out by the Federal School Lunch e-rate program. Here, regrettably, the telcos have exerted their caustic influence by compelling legislators to allow only school and library traffic on the e-rate fiber. As far as a purely technical solution, in my own experience some years ago I worked in the entertainment business in the Burbank/Glendale, Ca. area. Both cites, led by the visionary Burbank Department of Water and Power, built out dark fiber networks. Of course, getting municipal fiber in Glendale required an intense struggle with the incumbent telco, which sent a representative to every city council meeting arguing that municipal fiber was bad for the city residents. David On Sat, Feb 2, 2013 at 6:35 PM, Leo Bicknell wrote: > In a message written on Sat, Feb 02, 2013 at 09:28:06PM -0500, Scott Helms > wrote: > > I'm not saying that you have to, but that's the most efficient and > > resilient (both of those are important right?) way of arranging the gear. > > The exact loop length from the shelves to the end users is up to you and > > in certain circumstances (generally really compact areas) you can simply > > home run everyone. Most muni networks don't look that way though because > > while town centers are generally compact where people (especially the > > better subdivisions) live is away from the center of town in the US. I > > can't give you a lot insight on your specific area since I don't know it, > > but those are the general rules. > > If the goal is the minimize the capital outlay of a greenfield > build, your model can be more efficient, depending on the geography > covered. Basically you're assuming that the active electronics to > make a ring are cheaper than building high count fiber back to a > central point. There are geographies where that is both true, and > not true. I'll give you the benefit of the doubt that you're model is > cheaper for a majority of builds. > > On the other hand, I am not nearly as interested in minimizing the > up front capital cost. It's an issue, sure, but I care much more > about the total lifecycle cost. I'd rather spend 20% more up front > to end up with 20-80% lower costs over 50 years. My argument is > not that high count fiber back to a central location is cheaper in > absolute, up front dollars, but that it's at worst a minimal amount > more and will have neglegable additonal cost over a 40-80 year > service life. > > By contrast, the ring topology you suggest may be slightly less > expensive up front, but will require the active parts that make up > the ring to be swapped out every 7-20 years. I believe that will > lead to greater lifecycle cost; and almost importantly impeed > development of new services as the existing gear ends up incompatable > with newer technologies. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > From khelms at zcorum.com Sun Feb 3 03:17:24 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 2 Feb 2013 22:17:24 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <20130203023507.GB16918@ussenterprise.ufp.org> References: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> <20130203023507.GB16918@ussenterprise.ufp.org> Message-ID: > If the goal is the minimize the capital outlay of a greenfield > build, your model can be more efficient, depending on the geography > covered. Basically you're assuming that the active electronics to > make a ring are cheaper than building high count fiber back to a > central point. There are geographies where that is both true, and > not true. I'll give you the benefit of the doubt that you're model is > cheaper for a majority of builds. > Agreed, there are definitely scenarios where home running everything makes sense. > > On the other hand, I am not nearly as interested in minimizing the > up front capital cost. It's an issue, sure, but I care much more > about the total lifecycle cost. I'd rather spend 20% more up front > to end up with 20-80% lower costs over 50 years. My argument is > not that high count fiber back to a central location is cheaper in > absolute, up front dollars, but that it's at worst a minimal amount > more and will have neglegable additonal cost over a 40-80 year > service life. > Here's the thing, over the time frame your describing you're probably going to have to look at more fiber runs just because of growth in areas that you didn't build for before. Even if you nail the total growth of homes and businesses in your area your chances of getting both the numbers right _and_ the locations are pretty slim. Also, you're going to have to replace gear no matter where it is core or nodes on a ring. Granted gear that lives in a CO can be less expensive but its not that much of a difference (~1% of gear costs). Having a ring topology is basically the best way we've come up with as of yet to hedge your bets, especially since you can extend your ring when you need. > > > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jackson.tim at gmail.com Sun Feb 3 03:22:05 2013 From: jackson.tim at gmail.com (Tim Jackson) Date: Sat, 2 Feb 2013 21:22:05 -0600 Subject: Rollup: Small City Municipal Broadband In-Reply-To: References: <33402569.4632.1359836577050.JavaMail.root@benjamin.baylink.com> Message-ID: C7 is old school. E7/E20 is far far far far far far different. On Feb 2, 2013 2:55 PM, "Scott Helms" wrote: > Jay, > > I'm spotty on mailing lists since most of my time is spent building these > kinds of networks. > > 1) Talk to more vendors than just Calix, especially if they're quoting > their Ethernet density on the C7. Also, keep in mind that port density may > or may not be relevant to your situation since space for muni shelves isn't > usually a problem. Port density is much more important if you're deploying > in existing telco enclosures but muni networks tend (not universally of > course) to reuse existing city infrastructure building to house the nodes > of their network. Please note that I am not reccomending against Calix, > they're a good solution in many cases, but AE is not a strong point on the > C7. The E7 and the B series, which is the old Occam product, is much > better than the C7. For that matter I wouldn't consider doing a new build > on the C7 since that platform's EoL can't be too far in the future. > > 2) I have no idea who told you this, but this is completely and utterly > incorrect in nationwide terms. If you have a specific layer 3 provder in > mind that tells you they want a GPON hand off then that's fine, but ISPs in > general don't know what GPON is and have no gear to terminate that kind of > connection. > > > On Sat, Feb 2, 2013 at 3:22 PM, Jay Ashworth wrote: > > > ----- Original Message ----- > > > From: "Scott Helms" > > > > > Why on earth would you do this with PON instead of active Ethernet? > > > What GPON vendor have you found where their technical staff will tell > you > > > this is a good architecture for their PON offering? > > > > Asked and answered, Scott; have you been ignoring the threads all week? > > > > I'm pretty sure I even answered it in the posting, but just in case: > > > > 1) Line cards for the OLT frames appear to be 2 orders of magnitude > denser > > for GPON termination than AE (480 ports per 10U vs 10k ports per 10U in > > Calix, unless I've badly misunderstood my sources), and > > > > 2) GPON is what potential L3 providers large enough to want an optical > > handoff are generally used to. > > > > If someone wants AE, they can certainly have it. > > > > (C'mon; miss the *next* turn, too :-) > > > > Cheers, > > -- jra > > -- > > Jay R. Ashworth Baylink > > jra at baylink.com > > Designer The Things I Think RFC > > 2100 > > Ashworth & Associates http://baylink.pitas.com 2000 Land > > Rover DII > > St Petersburg FL USA #natog +1 727 647 > > 1274 > > > > > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > From jackson.tim at gmail.com Sun Feb 3 03:24:15 2013 From: jackson.tim at gmail.com (Tim Jackson) Date: Sat, 2 Feb 2013 21:24:15 -0600 Subject: Fwd: Rollup: Small City Municipal Broadband In-Reply-To: References: <24683668.4644.1359839500973.JavaMail.root@benjamin.baylink.com> Message-ID: Word to dropping docsis science on NANOG. On Feb 2, 2013 3:34 PM, "Scott Helms" wrote: > > I hope I said "E7"; it's what I meant to say. Yes, I wasn't going to > > stop at Calix; I'm just juggling budgetary type numbers at the moment; > > I'll have 3 or 4 quotes before I go to press. It's a 36 month project > > just to beginning of build, at this point, likely. > > > > Assuming I get the gig at all. > > > > The E7 is a good shelf, so that's a decent starting point. I'd also talk > with Zhone, Allied Telesys, Adtran, and Cisco if for no other reason but > get the best pricing you can. I'd also focus much more on your cost per > port than the density since your uptake rate will be driven by economics > long before port density and how much space your gear takes becomes an > issue. > > > > > > 2) I have no idea who told you this, but this is completely and utterly > > > incorrect in nationwide terms. If you have a specific layer 3 provder > > > in mind that tells you they want a GPON hand off then that's fine, but > > > ISPs in general don't know what GPON is and have no gear to terminate > > that > > > kind of connection. > > > > Other people here, said it. If nothing else, it's certainly what the > > largest nationwide FTTH provider is provisioning, and I suspect it serves > > more passings than anything else; possibly than everything else. > > > > I'm not sure what you mean by this. The largest PON offering in the US is > Verizon's FIOS, but AFAIK they don't interconnect with anyone at layer 2 > and their layer 3 fiber connections are either Packet Over SONET, Gig > E(most common), or very occasionally still ATM. I have heard of a few > instances where they'd buy existing GPON networks but I've never heard of > them cross connecting like this even with operators that they do > significant business with in other ways. > > > > > > But it doesn't matter either way, except in cross-connects between my MDF > > and my colo cages; except for GPONs apparent compatibility with RF CATV > > delivery (which I gather, but have not researched) is just > block-upconvert, > > I don't care either way; there's no difference in the plant buildout. > > > > This is not correct. DOCSIS is an MPEG stream over QAM or QPSK modulation > and there is nothing about it that is compatible to any flavor of PON. In > fact if you look at the various CableLabs standards you'll see DPoE ( > http://www.cablelabs.com/dpoe/specifications/index.html) which lists how a > DOCSIS system can inter-operate and provision an PON system. If you look at > the two largest PON networks (FIOS and Uverse) you'll see the two different > approaches to doing video with a PON architecture. Verizon is simply > modulating a MPEG stream (this is block compatible to a cable plant, in > fact its the same way that a HFC network functions) on a different color on > the same fiber that they send their PON signalling. ATT takes another > approach where they simply run IPTV over their PON network. I've listened > to presentations from Verizon's VP of Engineering (at that time) for FIOS > and he said their choice was driven by the technology available when they > launched and they did modulated RF over their fiber instead of IPTV because > that technology wasn't as mature when they started. Verizon's approach may > be what someone was thinking of when they said that PON was compatible to > cable signaling but that's not how it works. > > > > > > Cheers, > > -- jra > > -- > > Jay R. Ashworth Baylink > > jra at baylink.com > > Designer The Things I Think RFC > > 2100 > > Ashworth & Associates http://baylink.pitas.com 2000 Land > > Rover DII > > St Petersburg FL USA #natog +1 727 647 > > 1274 > > > > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > From jackson.tim at gmail.com Sun Feb 3 03:26:31 2013 From: jackson.tim at gmail.com (Tim Jackson) Date: Sat, 2 Feb 2013 21:26:31 -0600 Subject: Fwd: Rollup: Small City Municipal Broadband In-Reply-To: References: <24683668.4644.1359839500973.JavaMail.root@benjamin.baylink.com> Message-ID: What does Cisco shitty metro switches have to do with anything? Haaaaaay we have the best shitty metro-e boxes around. We're awesome. On Feb 2, 2013 4:49 PM, "Scott Helms" wrote: > That's one of the reasons to look at active ethernet over gpon. There is > much more of a chance to do v6 on that gear, especially cisco's Metro > ethernet switches. > On Feb 2, 2013 5:27 PM, "Brandon Ross" wrote: > > > On Sat, 2 Feb 2013, Scott Helms wrote: > > > > I'd also talk with Zhone, Allied Telesys, Adtran, and Cisco if for no > >> other reason but get the best pricing you can. > >> > > > > I can't believe I'm going to beat Owen to this point, but considering you > > a building a brand new infrastructure, I'd hope you'd support your > service > > provider's stakeholders if they want to do IPv6. To do so securely, > you'll > > want your neutral layer 2 infrastrcuture to at least support RA-guard and > > DHCPv6 shield. You might also want/need DHCPv6 PD snooping, MLD > snooping. > > We have found VERY disappointing support for these features in this type > > of gear. > > > > -- > > Brandon Ross Yahoo & AIM: > > BrandonNRoss > > +1-404-635-6667 ICQ: > > 2269442 > > Schedule a meeting: https://doodle.com/bross Skype: > > brandonross > > > From bicknell at ufp.org Sun Feb 3 03:32:03 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 2 Feb 2013 19:32:03 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> <20130203023507.GB16918@ussenterprise.ufp.org> Message-ID: <20130203033203.GA19119@ussenterprise.ufp.org> In a message written on Sat, Feb 02, 2013 at 10:17:24PM -0500, Scott Helms wrote: > Here's the thing, over the time frame your describing you're probably going > to have to look at more fiber runs just because of growth in areas that you > didn't build for before. Even if you nail the total growth of homes and > businesses in your area your chances of getting both the numbers right > _and_ the locations are pretty slim. Also, you're going to have to replace > gear no matter where it is core or nodes on a ring. Granted gear that > lives in a CO can be less expensive but its not that much of a difference > (~1% of gear costs). Having a ring topology is basically the best way > we've come up with as of yet to hedge your bets, especially since you can > extend your ring when you need. I'm not sure I understand your growth argument; both models will require additional build costs for growth to the network, and I think they roughly parallel the tradeoff's we've been discussing. As for the gear, I agree that the cost per port for the equipment providing service (Ethernet switch, GPON bits, WDM mux, whatever) is likely to be roughly similar in a CO and in the field. There's not a huge savings on the gear itself. But I would strongly disagree the overall costs, and services are similar. Compare a single CO of equipment to a network with 150 pedistals of active gear around a city. The CO can have one generator, and one battery bank. Most providers don't even put generator with each pedistal, and must maintain separate battery banks for each. A single CO could relatively cheaply have 24x7x356 hands to correct problems and swap equipment, where as the distributed network will add drive time to the equation and require higher staffing and greater costs (like the truck and fuel). Geography is a huge factor though. My concept of home running all fiber would be an extremely poor choice for extremely rural, low density networks. Your ring choice would be much, much better. On the flip side, in a high density world, say downtown NYC, my dark fiber to the end user network is far cheaper than building super-small rings and maintaining the support gear for the equipment (generators and batteries, if you can get space for them in most buildings). Still, I think direct dark fiber has lower lifecycle costs for 70-80% of the population living in cities and suburban areas. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From khelms at zcorum.com Sun Feb 3 03:53:04 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 2 Feb 2013 22:53:04 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <20130203033203.GA19119@ussenterprise.ufp.org> References: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> <20130203023507.GB16918@ussenterprise.ufp.org> <20130203033203.GA19119@ussenterprise.ufp.org> Message-ID: On Sat, Feb 2, 2013 at 10:32 PM, Leo Bicknell wrote: > In a message written on Sat, Feb 02, 2013 at 10:17:24PM -0500, Scott Helms > wrote: > > Here's the thing, over the time frame your describing you're probably > going > > to have to look at more fiber runs just because of growth in areas that > you > > didn't build for before. Even if you nail the total growth of homes and > > businesses in your area your chances of getting both the numbers right > > _and_ the locations are pretty slim. Also, you're going to have to > replace > > gear no matter where it is core or nodes on a ring. Granted gear that > > lives in a CO can be less expensive but its not that much of a difference > > (~1% of gear costs). Having a ring topology is basically the best way > > we've come up with as of yet to hedge your bets, especially since you can > > extend your ring when you need. > > I'm not sure I understand your growth argument; both models will > require additional build costs for growth to the network, and I > think they roughly parallel the tradeoff's we've been discussing. > Yes, but the reason why a ring with nodes is often the better architecture is because while both situations require more fiber to accomidate growth in areas that didn't previously have customers the distance from $new_area to existing ring is going to be shorter almost invariably than the distance from $new_area to CO. This matters not only from the stand point of it costs a certain amount per mile to bury or hang fiber but also because of right of ways and other hurdles that involve getting from point A to point B. > > As for the gear, I agree that the cost per port for the equipment > providing service (Ethernet switch, GPON bits, WDM mux, whatever) > is likely to be roughly similar in a CO and in the field. There's > not a huge savings on the gear itself. > > But I would strongly disagree the overall costs, and services are > similar. Compare a single CO of equipment to a network with 150 > pedistals of active gear around a city. The CO can have one > generator, and one battery bank. Most providers don't even put > generator with each pedistal, and must maintain separate battery > banks for each. A single CO could relatively cheaply have 24x7x356 > hands to correct problems and swap equipment, where as the distributed > network will add drive time to the equation and require higher > staffing and greater costs (like the truck and fuel). > Absolutely, getting a separate power meter for each enclosure, dealing with batteries there, and just remote gear all increases operational costs and the more nodes you have the greater that cost will be. > > Geography is a huge factor though. My concept of home running all fiber > would be an extremely poor choice for extremely rural, low density > networks. Your ring choice would be much, much better. On the flip > side, in a high density world, say downtown NYC, my dark fiber to the > end user network is far cheaper than building super-small rings and > maintaining the support gear for the equipment (generators and > batteries, if you can get space for them in most buildings). > > Still, I think direct dark fiber has lower lifecycle costs for 70-80% of > the population living in cities and suburban areas. > This is where the math gets hard and the specifics of each situation dictate what you need to do. IF you know precisely what your service area can be and that area is already densely populated then you're probably going to be able to cover all of that area with a single build. Downtown NYC is a scenario I'd completely agree with since you probably would also struggle trying to find places to install enclosures and you have a very tightly defined area that is densely populated today. I'd also say that this is not the normal muni network in the US today, since generally speaking muni networks spring up where the local area is poorly served by commercial operators. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Sun Feb 3 03:57:54 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 22:57:54 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: Message-ID: <5763600.4716.1359863874883.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > Here's the thing, over the time frame your describing you're probably going > to have to look at more fiber runs just because of growth in areas that you > didn't build for before. Even if you nail the total growth of homes and > businesses in your area your chances of getting both the numbers right > _and_ the locations are pretty slim. Also, you're going to have to replace > gear no matter where it is core or nodes on a ring. Granted gear that > lives in a CO can be less expensive but its not that much of a difference > (~1% of gear costs). Having a ring topology is basically the best way > we've come up with as of yet to hedge your bets, especially since you > can extend your ring when you need. In most cases that's true. My city, however, is built so close to 100% that I don't think it matters much. Over 2500 units per sqmi. The problem with gear in the ring isn't cost. It's OAM&P, and upgrades, and distributed emergency power, and, and, and... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jfmezei_nanog at vaxination.ca Sun Feb 3 04:07:22 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 02 Feb 2013 23:07:22 -0500 Subject: Fwd: Rollup: Small City Municipal Broadband In-Reply-To: References: <24683668.4644.1359839500973.JavaMail.root@benjamin.baylink.com> Message-ID: <510DE27A.8000300@vaxination.ca> On 13-02-02 21:29, Scott Helms wrote: > Yeah, that's what I figured. There are lots of older PON deployments that > used the modulated RF approach. >From what I have read, Verizon's FIOS does that. RFoG cable TV for certain frequencies, normal ethernet data for other frequencies, and dedicated bandwidth for VoIP. Cable companies in Canada have begun to deploy FTTH in greenfields. And those are deployed to be compatible with their coax infrastructure. The fibre from the CMTS is simply extended to the home instead of stopping at a "node" on a telephone pole. The coax starts at the ONT to get to the TV sets. Not sure if they have a DOCSIS modem attached to the coax or if they get the ethernet out of ONT. However, Rogers seems to have areas being deployed differently and I *believe* it is pure ethernet. (and not even sure if GPON). Rogers also wants to go all IPTV , something unexpected from a traditional cableTV company. Something to consider about dark fibre L1 service: If city lets Service Providers perform installations (string from telephone pole to homes etc), you need to worry about damages they can cause. And in cases when customer unsubscribes from SP-1 and subscribes to SP-2 you have to make sure that SP-1 doesn't damage the termination of the fibre in the home to make installation by SP-2 harder/costlier. In an L2 service, the city is responsible for all installations and de-installs and has no incentive to damage the infrastructure to hurt a competitor. And generally, the CPE is installed by city and stays in place when end user swiches service provider. From jra at baylink.com Sun Feb 3 04:17:32 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 2 Feb 2013 23:17:32 -0500 (EST) Subject: Rollup: Small City Municipal Broadband In-Reply-To: <510DE27A.8000300@vaxination.ca> Message-ID: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jean-Francois Mezei" > Something to consider about dark fibre L1 service: If city lets Service > Providers perform installations (string from telephone pole to homes > etc), you need to worry about damages they can cause. And in cases when > customer unsubscribes from SP-1 and subscribes to SP-2 you have to make > sure that SP-1 doesn't damage the termination of the fibre in the home > to make installation by SP-2 harder/costlier. You're still not getting it. And I'm not sure if it's on purpose or not. But I've been pretty clear: Home run from each prem to an MDF. City employes do all M-A-C patch cable moves on the MDF, to horizontals into the colo, where the provider's gear aggregates it from L1 to whatever. No aerial plant at all, no multple provider runs to the prems. That's most of the point here. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jfmezei_nanog at vaxination.ca Sun Feb 3 05:07:34 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sun, 03 Feb 2013 00:07:34 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> References: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> Message-ID: <510DF096.60907@vaxination.ca> On 13-02-02 23:17, Jay Ashworth wrote: > Home run from each prem to an MDF. City employes do all M-A-C patch cable > moves on the MDF, to horizontals into the colo, where the provider's gear > aggregates it from L1 to whatever. > > No aerial plant at all, no multple provider runs to the prems. Not talking about MDF/CO/MMR or whatever you call the aggregation point. While you've made it clear that you don't let Service Providers play around in that aggregation point, you didn't define (or perhaps I missed it) the responsabilities for work at homes. When municipality does the buildout, does it just pass homes, or does it actually connect every home ? When "passing homes", you would generally have pre-built taps such as Corning FlexNAPs along the cable so that a strand can be added quickly between the tap at telephone pole and the home wanting to get service. You only connect homes that subscribe to your service. (so you have to decide who is responsible for stringing fibre from telephone pole to the home when end user subscribes to a Service Provider's services. Not entirely sure what sort of methods they use when it is an underground cable plant. (perhaps more likely to see fibre brought to each home during the dig, perhaps not). In any event, you still have to worry about responsability if you allow Service Providers to install their on ONT or whatever CPE equipment in homes. If they damage the fibre cable when customer unsubscribes, who is responsible for the costs of repair ? (consider a case where either homeowner or SP just cuts the fibre as it comes out of wall when taking the ONT out to be returned to the SP. In Canada, the wholesale regime gives the owner of the cable plant (telco or cableco) responsibility for all installs even for independent ISPs. However, independent ISPs are responsible for providing approved modems to their customers. (different for VDSL where the telco provides the modems even for custoemrs of indy ISPs since the modems are customized to work with the VDSL DSLAMS selected by the telcos). In the case of cable companies, they have a list of approved DOCIS modems they allow independent ISPs to sell to teir customers. We'll see in the next few months what will transpire for a wholesale FTTH access in terms of responsabilities for CPE equipment (ONT, battery backup etc). From frnkblk at iname.com Sun Feb 3 05:25:31 2013 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 2 Feb 2013 23:25:31 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: <0D7538BB-C96D-4030-8C4C-0CD2282922E3@delong.com> References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <510C3EF6.5060905@vaxination.ca> <0D7538BB-C96D-4030-8C4C-0CD2282922E3@delong.com> Message-ID: <01fc01ce01ce$e267b060$a7371120$@iname.com> Live TV still makes up the majority of video viewing. http://www.thecab.tv/main/bm~doc/multiscreeninsights-2q12-p.pdf Multicasting video remains a valuable video distribution technique. Frank -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Friday, February 01, 2013 9:53 PM To: Jean-Francois Mezei Cc: nanog at nanog.org Subject: Re: Muni fiber: L1 or L2? On Feb 1, 2013, at 14:17 , Jean-Francois Mezei wrote: > If you have multicast and everyone is watching superbowl at same time, > you're talking up very little bandwidth on that 2.mumble GPON link. Meh. Since everyone seems to want to be able to pause, rewind, etc., multicast doesn't tend to happen so much even in the IPTV world these days. Owen From frnkblk at iname.com Sun Feb 3 05:55:21 2013 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 2 Feb 2013 23:55:21 -0600 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: References: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> Message-ID: <020901ce01d3$0da88c00$28f9a400$@iname.com> Yes, but IP TV is not profitable on stand-alone basis -- it's just a necessary part of the triple play. A lot of the discussion has been about Internet and network design, but not much about the other two "plays". Frank -----Original Message----- From: Brandon Ross [mailto:bross at pobox.com] Sent: Saturday, February 02, 2013 3:53 PM To: Jay Ashworth Cc: NANOG Subject: Re: Will wholesale-only muni actually bring the boys to your yard? On Sat, 2 Feb 2013, Jay Ashworth wrote: >> Perhaps I live in a different world, but just about all of the small to >> midsize service providers I work with offer triple play today, and nearly >> all of them are migrating their triple play services to IP. > > Really. Citations? I'd love to see it play that way, myself. Okay: South Central Rural Telephone Glasgow, KY http://www.scrtc.com/ Left side of page, "Digital TV service". See this news article: http://www.wcluradio.com/index.php?option=com_content&view=article&id=15567: capacity-crowd-hears-good-report-at-scrtc-annuan-mee "He also reported that SCRTC is continuing to upgrade our services, converting customers to the new IPTV service and trying to get as much fiber optic cable built as possible." Camellia Communications Greenville, AL http://camelliacom.com/services/ctv-dvr.html Note the models of set-top boxes they are using are IP based Griswold Cooperative Telephone Griswold, IA http://www.griswoldtelco.com/griswold-coop-iptv-video Farmer's Mutual Coopeative Telephone Moulton, IA http://farmersmutualcoop.com/ Citizens Floyd, VA http://www.citizens.coop/ How about a Canadian example you say? CoopTel Valcourt, QB http://www.cooptel.qc.ca/en-residentiel-tele-guidesusager.php Check out the models of set-top boxes here too. Oh, also, have you heard of ATT U-Verse? http://www.att.com/gen/press-room?pid=4800&cdvn=news&newsarticleid=26580 "AT&T U-verse TV is the only 100 percent Internet Protocol-based television (IPTV) service offered by a national service provider" So even the likes of AT&T, in this scheme, could buy fiber paths to their subs and provide TV service. I'm pretty sure AT&T knows how to deliver voice services over IP as well. Do you want more examples? I bet I can come up with 50 small/regional telecom companies that are providing TV services over IP in North America if I put my mind to it. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From frnkblk at iname.com Sun Feb 3 06:07:41 2013 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 3 Feb 2013 00:07:41 -0600 Subject: Rollup: Small City Municipal Broadband In-Reply-To: References: <24683668.4644.1359839500973.JavaMail.root@benjamin.baylink.com> Message-ID: <020a01ce01d4$c6b6b400$54241c00$@iname.com> Scott: Is there a vendor that supports RFoG on the same strand as ActiveE? Frank -----Original Message----- From: Scott Helms [mailto:khelms at zcorum.com] Sent: Saturday, February 02, 2013 3:30 PM To: NANOG Subject: Fwd: Rollup: Small City Municipal Broadband > But it doesn't matter either way, except in cross-connects between my MDF > and my colo cages; except for GPONs apparent compatibility with RF CATV > delivery (which I gather, but have not researched) is just block-upconvert, > I don't care either way; there's no difference in the plant buildout. This is not correct. DOCSIS is an MPEG stream over QAM or QPSK modulation and there is nothing about it that is compatible to any flavor of PON. In fact if you look at the various CableLabs standards you'll see DPoE ( http://www.cablelabs.com/dpoe/specifications/index.html) which lists how a DOCSIS system can inter-operate and provision an PON system. If you look at the two largest PON networks (FIOS and Uverse) you'll see the two different approaches to doing video with a PON architecture. Verizon is simply modulating a MPEG stream (this is block compatible to a cable plant, in fact its the same way that a HFC network functions) on a different color on the same fiber that they send their PON signalling. ATT takes another approach where they simply run IPTV over their PON network. I've listened to presentations from Verizon's VP of Engineering (at that time) for FIOS and he said their choice was driven by the technology available when they launched and they did modulated RF over their fiber instead of IPTV because that technology wasn't as mature when they started. Verizon's approach may be what someone was thinking of when they said that PON was compatible to cable signaling but that's not how it works. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From wbailey at satelliteintelligencegroup.com Sun Feb 3 07:19:48 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sun, 3 Feb 2013 07:19:48 +0000 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <020a01ce01d4$c6b6b400$54241c00$@iname.com> References: <24683668.4644.1359839500973.JavaMail.root@benjamin.baylink.com> , <020a01ce01d4$c6b6b400$54241c00$@iname.com> Message-ID: Don't know what frequency they use but ppm.co.uk does all the way to 14ghz (our ku band) over dwdm.. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Frank Bulk Date: 02/02/2013 10:10 PM (GMT-08:00) To: 'Scott Helms' ,NANOG Subject: RE: Rollup: Small City Municipal Broadband Scott: Is there a vendor that supports RFoG on the same strand as ActiveE? Frank -----Original Message----- From: Scott Helms [mailto:khelms at zcorum.com] Sent: Saturday, February 02, 2013 3:30 PM To: NANOG Subject: Fwd: Rollup: Small City Municipal Broadband > But it doesn't matter either way, except in cross-connects between my MDF > and my colo cages; except for GPONs apparent compatibility with RF CATV > delivery (which I gather, but have not researched) is just block-upconvert, > I don't care either way; there's no difference in the plant buildout. This is not correct. DOCSIS is an MPEG stream over QAM or QPSK modulation and there is nothing about it that is compatible to any flavor of PON. In fact if you look at the various CableLabs standards you'll see DPoE ( http://www.cablelabs.com/dpoe/specifications/index.html) which lists how a DOCSIS system can inter-operate and provision an PON system. If you look at the two largest PON networks (FIOS and Uverse) you'll see the two different approaches to doing video with a PON architecture. Verizon is simply modulating a MPEG stream (this is block compatible to a cable plant, in fact its the same way that a HFC network functions) on a different color on the same fiber that they send their PON signalling. ATT takes another approach where they simply run IPTV over their PON network. I've listened to presentations from Verizon's VP of Engineering (at that time) for FIOS and he said their choice was driven by the technology available when they launched and they did modulated RF over their fiber instead of IPTV because that technology wasn't as mature when they started. Verizon's approach may be what someone was thinking of when they said that PON was compatible to cable signaling but that's not how it works. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From ops.lists at gmail.com Sun Feb 3 12:42:32 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 3 Feb 2013 18:12:32 +0530 Subject: Announcing a reserved ASN? In-Reply-To: References: Message-ID: AS23456 is currently announcing a good few netblocks (which don't have a very good smtp reputation, by the way). Funny thing is, that's a special use ASN as per rfc4893, something about two octet ASNs that don't have a four octet representation. Only one upstream (airtelbroadband-as-ap, as24560) that I can see > > 103.7.204.0/22 > > 103.14.208.0/22 > > 103.23.124.0/22 > > 103.30.12.0/22 > > 103.245.112.0/22 > > 111.235.148.0/22 > > 177.55.249.0/24 > > 186.251.192.0/21 --srs (htc one x) From ops.lists at gmail.com Sun Feb 3 12:57:40 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 3 Feb 2013 18:27:40 +0530 Subject: Announcing a reserved ASN? In-Reply-To: References: Message-ID: At least the 103.x which are announced by airtel. The other netblocks (one Indian and two brazilian) appear unrelated though also showing as23456 --srs (htc one x) On 03-Feb-2013 6:12 PM, "Suresh Ramasubramanian" > wrote: > AS23456 is currently announcing a good few netblocks (which don't have a > very good smtp reputation, by the way). > > Funny thing is, that's a special use ASN as per rfc4893, something about > two octet ASNs that don't have a four octet representation. > > Only one upstream (airtelbroadband-as-ap, as24560) that I can see > > > > 103.7.204.0/22 > > > 103.14.208.0/22 > > > 103.23.124.0/22 > > > 103.30.12.0/22 > > > 103.245.112.0/22 > > > 111.235.148.0/22 > > > 177.55.249.0/24 > > > 186.251.192.0/21 > > --srs (htc one x) > -- --srs (iPad) From rs at seastrom.com Sun Feb 3 13:00:02 2013 From: rs at seastrom.com (Robert E. Seastrom) Date: Sun, 03 Feb 2013 08:00:02 -0500 Subject: Muni network ownership and the Fourth In-Reply-To: <20130203021228.GA16918@ussenterprise.ufp.org> (Leo Bicknell's message of "Sat, 2 Feb 2013 18:12:28 -0800") References: <864nhury5c.fsf@seastrom.com> <10887966.4706.1359856534239.JavaMail.root@benjamin.baylink.com> <20130203021228.GA16918@ussenterprise.ufp.org> Message-ID: <86pq0hblil.fsf@seastrom.com> Leo Bicknell writes: > In a message written on Sat, Feb 02, 2013 at 08:55:34PM -0500, Jay Ashworth wrote: >> > From: "Robert E. Seastrom" >> > There is no reason whatsoever that one can't have centralized >> > splitters in one's PON plant. The additional costs to do so are >> > pretty much just limited to higher fiber counts in the field, which >> > adds, tops, a couple of percent to the price of the build. >> >> Ok, see, this is what Leo, Owen and I all think, and maybe a couple others. >> >> But Scott just got done telling me it's *so* much more expensive to >> home-run than ring or GPON-in-pedestals that it's commercially infeasible. > > Note, both are right, depending on the starting point and goals. Data point, which makes the rest of this discussion moot: Since telcos are historically myopic and don't build (much) extra fiber into their plant to support future technologies, the only use for existing fiber in the ground in passive optical applications is to connect the COs. There is not enough running out towards the customers to support retrofitting it for PON. Besides, there are regulatory issues with re-purposing existing voice-plant-supporting assets for PON in places such as VZ territory where the ILEC got a pass on legislated equal access applying to PON builds. Some more data that may inform your conceptualization - Split ratios of 128 and 64 only work in the lab. Proper engineering (overlap of dB and bits/sec/customer) will dictate split ratios of 16 or 32 (depending on modulation scheme, and no, going to 10gbit modulation doesn't help; you still have the link budget problem) last time I did the math. Still, the power budget improvements by not going with a single strand active ethernet solution (which were another suggested technology and has actually been deployed by some muni PON folks like Clarkesville, TN) are huge. Imagine a 24 port switch that draws 100 watts. OK, that's 4w per customer. 30k customers from a served location, that's 120kw ($13k power bill if you had 100% efficient UPSes and 0 cost cooling, neither of which is true) just for the edge, not counting any aggregation devices or northbound switch gear. Back at NN, we discounted this as a technology almost immediately based on energy efficiency alone. Anyway, in summary, for PON deployments the part that matters *is* a greenfield deployment and if the fiber plant is planned and scaled accordingly the cost differential is noise. -r > Historically teclos have installed (relatively) low count fiber > cables, based on a fiber to the pedistal and copper to the prem > strategy. If you have one of these existing deployments, the cost > of home run fiber (basically starting the fiber build from scratch, > since the count is so low) is more expensive, and much greater cost > than deploying GPON or similar over the existing plant. > > However, that GPON equipment will have a lifespan of 7-20 years. > > In a greenfield scenario where there is no fiber in the ground the > cost is in digging the trench. The fiber going into it is only ~5% > of the cost, and going from a 64 count fiber to a 864 count fiber > only moves that to 7-8%. The fiber has a life of 40-80 years, and > thus adding high count is cheaper than doing low count with GPON. > > Existing builds are optimizing to avoid sending out the backhoe and > directional boring machine. New builds, or extreme forward thinking > builds are trying to send them out once and never again. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ From khelms at zcorum.com Sun Feb 3 13:29:39 2013 From: khelms at zcorum.com (Scott Helms) Date: Sun, 3 Feb 2013 08:29:39 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <020a01ce01d4$c6b6b400$54241c00$@iname.com> References: <24683668.4644.1359839500973.JavaMail.root@benjamin.baylink.com> <020a01ce01d4$c6b6b400$54241c00$@iname.com> Message-ID: Frank, I don't know off hand, but it ought to be easy even though Ethernet uses a wider "channel" than most PON set ups. I'll do some asking tomorrow. On Sun, Feb 3, 2013 at 1:07 AM, Frank Bulk wrote: > Scott: > > Is there a vendor that supports RFoG on the same strand as ActiveE? > > Frank > > -----Original Message----- > From: Scott Helms [mailto:khelms at zcorum.com] > Sent: Saturday, February 02, 2013 3:30 PM > To: NANOG > Subject: Fwd: Rollup: Small City Municipal Broadband > > > But it doesn't matter either way, except in cross-connects between my MDF > > and my colo cages; except for GPONs apparent compatibility with RF CATV > > delivery (which I gather, but have not researched) is just > block-upconvert, > > I don't care either way; there's no difference in the plant buildout. > > This is not correct. DOCSIS is an MPEG stream over QAM or QPSK modulation > and there is nothing about it that is compatible to any flavor of PON. In > fact if you look at the various CableLabs standards you'll see DPoE ( > http://www.cablelabs.com/dpoe/specifications/index.html) which lists how a > DOCSIS system can inter-operate and provision an PON system. If you look at > the two largest PON networks (FIOS and Uverse) you'll see the two different > approaches to doing video with a PON architecture. Verizon is simply > modulating a MPEG stream (this is block compatible to a cable plant, in > fact its the same way that a HFC network functions) on a different color on > the same fiber that they send their PON signalling. ATT takes another > approach where they simply run IPTV over their PON network. I've listened > to presentations from Verizon's VP of Engineering (at that time) for FIOS > and he said their choice was driven by the technology available when they > launched and they did modulated RF over their fiber instead of IPTV because > that technology wasn't as mature when they started. Verizon's approach may > be what someone was thinking of when they said that PON was compatible to > cable signaling but that's not how it works. > > > > > > Cheers, > > -- jra > > -- > > Jay R. Ashworth Baylink > > jra at baylink.com > > Designer The Things I Think RFC > > 2100 > > Ashworth & Associates http://baylink.pitas.com 2000 Land > > Rover DII > > St Petersburg FL USA #natog +1 727 647 > > 1274 > > > > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Sun Feb 3 14:31:19 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 3 Feb 2013 09:31:19 -0500 (EST) Subject: Rollup: Small City Municipal Broadband In-Reply-To: <510DF096.60907@vaxination.ca> Message-ID: <30428360.4732.1359901879269.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jean-Francois Mezei" > On 13-02-02 23:17, Jay Ashworth wrote: > > Home run from each prem to an MDF. City employes do all M-A-C patch cable > > moves on the MDF, to horizontals into the colo, where the provider's gear > > aggregates it from L1 to whatever. > > > > No aerial plant at all, no multple provider runs to the prems. > > Not talking about MDF/CO/MMR or whatever you call the aggregation point. > While you've made it clear that you don't let Service Providers play > around in that aggregation point, you didn't define (or perhaps I > missed it) the responsabilities for work at homes. Ah, and that's because I was making an assumption I didn't actually mention; my apologies. > When municipality does the buildout, does it just pass homes, or does > it actually connect every home ? I was planning to at the very least bring the 'drop' (the underground tail) up on to the structure. We probably won't actually put the ONTs on for people who don't pre-sub. It's still an open question whether we'll use interior or exterior ONTs for our own L2 service, but the idea that there will be competing L2/3 providers lets out the idea of preprovisioning all the ONTs; no sense. > When "passing homes", you would generally have pre-built taps such as > Corning FlexNAPs along the cable so that a strand can be added quickly > between the tap at telephone pole and the home wanting to get service. > You only connect homes that subscribe to your service. (so you have to > decide who is responsible for stringing fibre from telephone pole to > the home when end user subscribes to a Service Provider's services. Yeah; everything from the MMR/MDF to the prem is our responsibility; the ISPs rack up in the colo and we physically hand them optical (or ethernet) patches. > Not entirely sure what sort of methods they use when it is an > underground cable plant. (perhaps more likely to see fibre brought to > each home during the dig, perhaps not). It was my plan, yes, but I haven't talked to fiber install contractor people yet, since this is at least a 36 month project. > In any event, you still have to worry about responsability if you allow > Service Providers to install their on ONT or whatever CPE equipment in > homes. If they damage the fibre cable when customer unsubscribes, who > is responsible for the costs of repair ? (consider a case where either > homeowner or SP just cuts the fibre as it comes out of wall when > taking the ONT out to be returned to the SP. I'm sure someone makes scissor-proof armored optical drop cables, right? :-) > In Canada, the wholesale regime gives the owner of the cable plant > (telco or cableco) responsibility for all installs even for independent > ISPs. However, independent ISPs are responsible for providing approved > modems to their customers. (different for VDSL where the telco > provides the modems even for custoemrs of indy ISPs since the modems are > customized to work with the VDSL DSLAMS selected by the telcos). In > the case of cable companies, they have a list of approved DOCIS modems > the> allow independent ISPs to sell to teir customers. That's something like how, say, RoadRunner does it here; they'll supply the cablemodem, or you can buy a compatible one. It's a loss, since they'll replace lightning zapped ones for free if it's there. > We'll see in the next few months what will transpire for a wholesale > FTTH access in terms of responsabilities for CPE equipment (ONT, > battery backup etc). In Canada, you mean? Interesting. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Sun Feb 3 14:34:58 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 3 Feb 2013 09:34:58 -0500 (EST) Subject: Muni network ownership and the Fourth In-Reply-To: <86pq0hblil.fsf@seastrom.com> Message-ID: <6174691.4734.1359902098206.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Robert E. Seastrom" > Data point, which makes the rest of this discussion moot: > > Since telcos are historically myopic and don't build (much) extra > fiber into their plant to support future technologies, the only use > for existing fiber in the ground in passive optical applications is to > connect the COs. There is not enough running out towards the > customers to support retrofitting it for PON. It doesn't make it moot for me; I'm greenfield. > Some more data that may inform your conceptualization - Split ratios > of 128 and 64 only work in the lab. Proper engineering (overlap of dB > and bits/sec/customer) will dictate split ratios of 16 or 32 > (depending on modulation scheme, and no, going to 10gbit modulation > doesn't help; you still have the link budget problem) last time I did > the math. Yeah, I sorta figured this. > Still, the power budget improvements by not going with a single strand > active ethernet solution (which were another suggested technology and > has actually been deployed by some muni PON folks like Clarkesville, > TN) are huge. Imagine a 24 port switch that draws 100 watts. OK, > that's 4w per customer. 30k customers from a served location, that's > 120kw ($13k power bill if you had 100% efficient UPSes and 0 cost > cooling, neither of which is true) just for the edge, not counting any > aggregation devices or northbound switch gear. Hmm. the optics don't have auto power control? > Back at NN, we discounted this as a technology almost immediately > based on energy efficiency alone. > > Anyway, in summary, for PON deployments the part that matters *is* a > greenfield deployment and if the fiber plant is planned and scaled > accordingly the cost differential is noise. I assume you mean "the cost diff between GPON plant and home-run plant"; that's the answer I was hoping for. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From rsk at gsp.org Sun Feb 3 15:04:19 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 3 Feb 2013 10:04:19 -0500 Subject: Announcing a reserved ASN? In-Reply-To: References: Message-ID: <20130203150419.GA14398@gsp.org> On Sun, Feb 03, 2013 at 06:12:32PM +0530, Suresh Ramasubramanian wrote: > AS23456 is currently announcing a good few netblocks (which don't have a > very good smtp reputation, by the way). To say the least. A quick rDNS scan reveals that those netblocks include: 8448 addresses 6932 return nxdomain 512 return servfail 1004 with rDNS entries Those 1004 hosts with rDNS account for 36 domains: ainoutserver.net alphainfonet.com boxmatter.org clickcabin.com cloud-core.com contrymail.com coremail4you.org dealatmail.org deliver8mail.org deliverbox.org deliveryalive.org deliveryaverage.org emailadvisir.org emailpacts.com emailservercore.com emailvalue.co.in emailvalue.in fairmail4you.org financeofferpros.com globalmaildelivery.org inboxdelivery.org livemailservices.in nayasa.net newwaygain.com paydayloanforyou.net payloantoyou.com quickpaydaytoyou.net ready4deal.org realemail.org realemaildelivery.org sandeshdelivery.org sandeshfour.com sandeshone.com sandeshonline.org truemaildelivery.org warmmailcampaign.com I'm sure they're all perfectly legitimate businesses. ---rsk From dave.nanog at alfordmedia.com Sun Feb 3 15:29:51 2013 From: dave.nanog at alfordmedia.com (Dave Pooser) Date: Sun, 03 Feb 2013 09:29:51 -0600 Subject: Announcing a reserved ASN? In-Reply-To: Message-ID: On 2/3/13 9:04 AM, "Rich Kulawiec" wrote: >On Sun, Feb 03, 2013 at 06:12:32PM +0530, Suresh Ramasubramanian wrote: >> AS23456 is currently announcing a good few netblocks (which don't have a >> very good smtp reputation, by the way). > >To say the least. A quick rDNS scan reveals that those netblocks include: > > 8448 addresses > 6932 return nxdomain > 512 return servfail > 1004 with rDNS entries > >Those 1004 hosts with rDNS account for 36 domains: Just as another data point, the domain names you listed hit on enough URL blacklists that Spamassassin quarantined the message for me (and would have rejected it during the SMTP transaction had the NANOG server not been listed on DNSWL-High). Spam hosts plus fake ASN = paging the Spamhaus DROP maintainers to the white courtesy phone.... -- Dave Pooser Manager of Information Services Alford Media http://www.alfordmedia.com From bross at pobox.com Sun Feb 3 15:55:50 2013 From: bross at pobox.com (Brandon Ross) Date: Sun, 3 Feb 2013 10:55:50 -0500 (EST) Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: <020901ce01d3$0da88c00$28f9a400$@iname.com> References: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> <020901ce01d3$0da88c00$28f9a400$@iname.com> Message-ID: On Sat, 2 Feb 2013, Frank Bulk wrote: > Yes, but IP TV is not profitable on stand-alone basis -- it's just a > necessary part of the triple play. A lot of the discussion has been about > Internet and network design, but not much about the other two "plays". I don't know if that's true or not, but so what? The concern was that providers would be unable to provide television services across this muni fiber infrastructure and that customers would demand triple play. I showed that they absolutely can provide this service by doing it across IP. If a provider can't make money at it, then they don't have to provide it. This whole exercise, I thought, was about removing the tyranny of the monopoly of the last mine so that these other innovations could take place in an open market. And as far as the "other" triple play, it's even more well established that delivery of voice over IP can be done economically. Or do you need me to send you URLs of companies that do it to prove it? > -----Original Message----- > From: Brandon Ross [mailto:bross at pobox.com] > Sent: Saturday, February 02, 2013 3:53 PM > To: Jay Ashworth > Cc: NANOG > Subject: Re: Will wholesale-only muni actually bring the boys to your yard? > > On Sat, 2 Feb 2013, Jay Ashworth wrote: > >>> Perhaps I live in a different world, but just about all of the small to >>> midsize service providers I work with offer triple play today, and nearly >>> all of them are migrating their triple play services to IP. >> >> Really. Citations? I'd love to see it play that way, myself. > > Okay: > > South Central Rural Telephone > Glasgow, KY > http://www.scrtc.com/ > Left side of page, "Digital TV service". See this news article: > > http://www.wcluradio.com/index.php?option=com_content&view=article&id=15567: > capacity-crowd-hears-good-report-at-scrtc-annuan-mee > > "He also reported that SCRTC is continuing to upgrade our services, > converting customers to the new IPTV service and trying to get as much > fiber optic cable built as possible." > > Camellia Communications > Greenville, AL > http://camelliacom.com/services/ctv-dvr.html > Note the models of set-top boxes they are using are IP based > > Griswold Cooperative Telephone > Griswold, IA > http://www.griswoldtelco.com/griswold-coop-iptv-video > > Farmer's Mutual Coopeative Telephone > Moulton, IA > http://farmersmutualcoop.com/ > > Citizens > Floyd, VA > http://www.citizens.coop/ > > > How about a Canadian example you say? > > CoopTel > Valcourt, QB > http://www.cooptel.qc.ca/en-residentiel-tele-guidesusager.php > Check out the models of set-top boxes here too. > > Oh, also, have you heard of ATT U-Verse? > > http://www.att.com/gen/press-room?pid=4800&cdvn=news&newsarticleid=26580 > > "AT&T U-verse TV is the only 100 percent Internet Protocol-based > television (IPTV) service offered by a national service provider" > > So even the likes of AT&T, in this scheme, could buy fiber paths to their > subs and provide TV service. I'm pretty sure AT&T knows how to deliver > voice services over IP as well. > > Do you want more examples? I bet I can come up with 50 small/regional > telecom companies that are providing TV services over IP in North America > if I put my mind to it. > > -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From ops.lists at gmail.com Sun Feb 3 16:02:31 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Sun, 3 Feb 2013 21:32:31 +0530 Subject: Announcing a reserved ASN? In-Reply-To: References: Message-ID: I do believe, as has been pointed out to me elsewhere that this is what shows up when there's a 64 bit ASN and router software that doesn't grok 64 bit ASNs So, completely by chance that one such as belongs to what looks like a bulk mailer --srs (htc one x) On 03-Feb-2013 9:02 PM, "Dave Pooser" wrote: > On 2/3/13 9:04 AM, "Rich Kulawiec" wrote: > > >On Sun, Feb 03, 2013 at 06:12:32PM +0530, Suresh Ramasubramanian wrote: > >> AS23456 is currently announcing a good few netblocks (which don't have a > >> very good smtp reputation, by the way). > > > >To say the least. A quick rDNS scan reveals that those netblocks include: > > > > 8448 addresses > > 6932 return nxdomain > > 512 return servfail > > 1004 with rDNS entries > > > >Those 1004 hosts with rDNS account for 36 domains: > > > > Just as another data point, the domain names you listed hit on enough URL > blacklists that Spamassassin quarantined the message for me (and would > have rejected it during the SMTP transaction had the NANOG server not been > listed on DNSWL-High). Spam hosts plus fake ASN = paging the Spamhaus DROP > maintainers to the white courtesy phone.... > -- > Dave Pooser > Manager of Information Services > Alford Media http://www.alfordmedia.com > > > > From jra at baylink.com Sun Feb 3 16:14:18 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 3 Feb 2013 11:14:18 -0500 (EST) Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: Message-ID: <13387558.4738.1359908058077.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brandon Ross" > On Sat, 2 Feb 2013, Frank Bulk wrote: > > > Yes, but IP TV is not profitable on stand-alone basis -- it's just a > > necessary part of the triple play. A lot of the discussion has been > > about > Internet and network design, but not much about the other two > > "plays". > > I don't know if that's true or not, but so what? > > The concern was that providers would be unable to provide television > services across this muni fiber infrastructure and that customers would > demand triple play. I showed that they absolutely can provide this > service by doing it across IP. Yeah; I'm not sure what Frank was worried about on this one, either. :-) Your citations were just what I needed, Brandon. Why did you think there was a problem, here, Frank? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From bross at pobox.com Sun Feb 3 16:15:04 2013 From: bross at pobox.com (Brandon Ross) Date: Sun, 3 Feb 2013 11:15:04 -0500 (EST) Subject: Announcing a reserved ASN? In-Reply-To: References: Message-ID: I strongly recommend that you read about and fully understand how 4-byte ASNs work, and their use of AS23456 before you continue this thread. On Sun, 3 Feb 2013, Suresh Ramasubramanian wrote: > I do believe, as has been pointed out to me elsewhere that this is what > shows up when there's a 64 bit ASN and router software that doesn't grok 64 > bit ASNs > > So, completely by chance that one such as belongs to what looks like a bulk > mailer > > --srs (htc one x) > On 03-Feb-2013 9:02 PM, "Dave Pooser" wrote: > >> On 2/3/13 9:04 AM, "Rich Kulawiec" wrote: >> >>> On Sun, Feb 03, 2013 at 06:12:32PM +0530, Suresh Ramasubramanian wrote: >>>> AS23456 is currently announcing a good few netblocks (which don't have a >>>> very good smtp reputation, by the way). >>> >>> To say the least. A quick rDNS scan reveals that those netblocks include: >>> >>> 8448 addresses >>> 6932 return nxdomain >>> 512 return servfail >>> 1004 with rDNS entries >>> >>> Those 1004 hosts with rDNS account for 36 domains: >> >> >> >> Just as another data point, the domain names you listed hit on enough URL >> blacklists that Spamassassin quarantined the message for me (and would >> have rejected it during the SMTP transaction had the NANOG server not been >> listed on DNSWL-High). Spam hosts plus fake ASN = paging the Spamhaus DROP >> maintainers to the white courtesy phone.... >> -- >> Dave Pooser >> Manager of Information Services >> Alford Media http://www.alfordmedia.com >> >> >> >> > -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From bicknell at ufp.org Sun Feb 3 16:58:50 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 3 Feb 2013 08:58:50 -0800 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <510DF096.60907@vaxination.ca> References: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> <510DF096.60907@vaxination.ca> Message-ID: <20130203165850.GA44479@ussenterprise.ufp.org> In a message written on Sun, Feb 03, 2013 at 12:07:34AM -0500, Jean-Francois Mezei wrote: > When municipality does the buildout, does it just pass homes, or does it > actually connect every home ? I would argue, in a pure dark muni-network, the muni would run the fiber into the prem to a patch panel, and stop at that point. I believe for fiber it should be inside the prem, not outside. The same would apply for both residential and commercial. Basically when the customer (typically the service provider, but not always) orders a loop to a customer the muni provider would OTDR shoot it from the handoff point to the service provider to the prem. They would be responsible for insuring a reasonable performance of the fiber between those two end points. The customer (again, typically the service provider) would then plug in any CPE, be it an ONT, or ethernet SFP, or WDM mux. Note I say typically the service provider, because I want to enable in this model the ability for you and I, if we both have homes in this area, to pay the same $X/month and get a patch between our two homes. No service provider involved. If we want to stand up GigE on it because that's cheap, wonderful. If we want to stand up 16x100GE WDM, excellent as well. It's very similar to me to the traditional copper model used by the ILECs. There is a demark box that terminates the outside plant and allows the customer to connect the inside plant. The facilities provider stops at that box (unless you pay them to do more, of course). The provisioning process I'm advocating is substantially similar to ordering a "dry pair" in the copper world, although perhaps with a bit more customer service since it would be a service the muni wants to sell! > In any event, you still have to worry about responsability if you allow > Service Providers to install their on ONT or whatever CPE equipment in > homes. If they damage the fibre cable when customer unsubscribes, who is > responsible for the costs of repair ? (consider a case where either > homeowner or SP just cuts the fibre as it comes out of wall when taking > the ONT out to be returned to the SP. The box is the demark. If they damage something on the customer side, that's their own issue. If the damage something on the facilities provider side, the facilities provider will charge them to fix it. There would be no "just coming out of the wall". There would be a 6-12 SC (FC?) connector patch panel in a small plastic enclosure, with the outside plant properly secured (conduit, in the wall, etc) and not exposed. The homewowner or their service provider would plug into that patch panel. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From bicknell at ufp.org Sun Feb 3 17:04:43 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 3 Feb 2013 09:04:43 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> <20130203023507.GB16918@ussenterprise.ufp.org> <20130203033203.GA19119@ussenterprise.ufp.org> Message-ID: <20130203170443.GB44479@ussenterprise.ufp.org> In a message written on Sat, Feb 02, 2013 at 10:53:04PM -0500, Scott Helms wrote: > tightly defined area that is densely populated today. I'd also say that > this is not the normal muni network in the US today, since generally > speaking muni networks spring up where the local area is poorly served by > commercial operators. Exactly, that's what I would like to fix. I personally haven't talked much about the poltical and regulatory polices that go along with the technical details I've discussed, but I want to build these muni-networks in the areas today dominated by the cablecos and telcos, and force them to use it rather than doing their own builds along with everyone else. As a citizen I get less people digging up streets and yards, and more competition since now more than just the incumbant telco and cableco can play ball. If Glasgow Kentucky (population ) can have fiber between any two buildings in town for $300 a month, why can't I? Somehow a small rural town of 14,000 can do it, but the big cities can't? http://www.epblan.com/ethernet.html I also suspect we could drop that cost a full order of magnitude with some economies of scale. People are doing this, and it does work, it's just being done in locations the big telcos and cablecos have written off... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From josmon at rigozsaurus.com Sun Feb 3 17:44:07 2013 From: josmon at rigozsaurus.com (John Osmon) Date: Sun, 3 Feb 2013 10:44:07 -0700 Subject: muni L1 example (WAS: Re: Muni fiber: L1 or L2?) In-Reply-To: <20130203170443.GB44479@ussenterprise.ufp.org> References: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> <20130203023507.GB16918@ussenterprise.ufp.org> <20130203033203.GA19119@ussenterprise.ufp.org> <20130203170443.GB44479@ussenterprise.ufp.org> Message-ID: <20130203174407.GA30037@jeeves.rigozsaurus.com> On Sun, Feb 03, 2013 at 09:04:43AM -0800, Leo Bicknell wrote: [...] > People are doing this, and it does work, it's just being done in > locations the big telcos and cablecos have written off... To re-iterate this point, and get a note into the archives -- Muni networks *can* work. Idaho Falls, ID has been offering dark fiber strands to anyone since 2007 or so: http://www.ifcirca.net/ When I last had network in the area, the cost was on the order of: - $1500/month/loop - $20/bldg on loop - one-time construction costs From richard.barnes at gmail.com Sun Feb 3 18:58:13 2013 From: richard.barnes at gmail.com (Richard Barnes) Date: Sun, 3 Feb 2013 13:58:13 -0500 Subject: Announcing a reserved ASN? In-Reply-To: References: Message-ID: Some links: http://www.nanog.org/meetings/nanog45/presentations/Tuesday/Hankins_4byteASN_N45.pdf https://tools.ietf.org/html/rfc6793 On Sun, Feb 3, 2013 at 11:15 AM, Brandon Ross wrote: > I strongly recommend that you read about and fully understand how 4-byte > ASNs work, and their use of AS23456 before you continue this thread. > > > On Sun, 3 Feb 2013, Suresh Ramasubramanian wrote: > > I do believe, as has been pointed out to me elsewhere that this is what >> shows up when there's a 64 bit ASN and router software that doesn't grok >> 64 >> bit ASNs >> >> So, completely by chance that one such as belongs to what looks like a >> bulk >> mailer >> >> --srs (htc one x) >> On 03-Feb-2013 9:02 PM, "Dave Pooser" wrote: >> >> On 2/3/13 9:04 AM, "Rich Kulawiec" wrote: >>> >>> On Sun, Feb 03, 2013 at 06:12:32PM +0530, Suresh Ramasubramanian wrote: >>>> >>>>> AS23456 is currently announcing a good few netblocks (which don't have >>>>> a >>>>> very good smtp reputation, by the way). >>>>> >>>> >>>> To say the least. A quick rDNS scan reveals that those netblocks >>>> include: >>>> >>>> 8448 addresses >>>> 6932 return nxdomain >>>> 512 return servfail >>>> 1004 with rDNS entries >>>> >>>> Those 1004 hosts with rDNS account for 36 domains: >>>> >>> >>> >>> >>> Just as another data point, the domain names you listed hit on enough URL >>> blacklists that Spamassassin quarantined the message for me (and would >>> have rejected it during the SMTP transaction had the NANOG server not >>> been >>> listed on DNSWL-High). Spam hosts plus fake ASN = paging the Spamhaus >>> DROP >>> maintainers to the white courtesy phone.... >>> -- >>> Dave Pooser >>> Manager of Information Services >>> Alford Media http://www.alfordmedia.com >>> >>> >>> >>> >>> >> > -- > Brandon Ross Yahoo & AIM: > BrandonNRoss > +1-404-635-6667 ICQ: > 2269442 > Schedule a meeting: https://doodle.com/bross Skype: > brandonross > > From khelms at zcorum.com Sun Feb 3 19:39:39 2013 From: khelms at zcorum.com (Scott Helms) Date: Sun, 3 Feb 2013 14:39:39 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <20130203165850.GA44479@ussenterprise.ufp.org> References: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> <510DF096.60907@vaxination.ca> <20130203165850.GA44479@ussenterprise.ufp.org> Message-ID: On Sun, Feb 3, 2013 at 11:58 AM, Leo Bicknell wrote: > In a message written on Sun, Feb 03, 2013 at 12:07:34AM -0500, > Jean-Francois Mezei wrote: > > When municipality does the buildout, does it just pass homes, or does it > > actually connect every home ? > > I would argue, in a pure dark muni-network, the muni would run the > fiber into the prem to a patch panel, and stop at that point. I > believe for fiber it should be inside the prem, not outside. The > same would apply for both residential and commercial. > > Basically when the customer (typically the service provider, but > not always) orders a loop to a customer the muni provider would > OTDR shoot it from the handoff point to the service provider to the > prem. They would be responsible for insuring a reasonable performance > of the fiber between those two end points. > Been tried multiple times and I've never seen it work in the US, Canada, Europe, or Latin America. That's not to say it can't work, but there lots of reasons why it doesn't and I don't think anyone has suggested anything here that I haven't already seen fail. > The customer (again, typically the service provider) would then > plug in any CPE, be it an ONT, or ethernet SFP, or WDM mux. > > Note I say typically the service provider, because I want to enable > in this model the ability for you and I, if we both have homes in > this area, to pay the same $X/month and get a patch between our two > homes. No service provider involved. If we want to stand up GigE > on it because that's cheap, wonderful. If we want to stand up > 16x100GE WDM, excellent as well. > > It's very similar to me to the traditional copper model used by the > ILECs. There is a demark box that terminates the outside plant and > allows the customer to connect the inside plant. The facilities > provider stops at that box (unless you pay them to do more, of > course). The provisioning process I'm advocating is substantially > similar to ordering a "dry pair" in the copper world, although perhaps > with a bit more customer service since it would be a service the muni > wants to sell! > Dry pairs are impossible to order these days for a reason. > > > In any event, you still have to worry about responsability if you allow > > Service Providers to install their on ONT or whatever CPE equipment in > > homes. If they damage the fibre cable when customer unsubscribes, who is > > responsible for the costs of repair ? (consider a case where either > > homeowner or SP just cuts the fibre as it comes out of wall when taking > > the ONT out to be returned to the SP. > > The box is the demark. If they damage something on the customer > side, that's their own issue. If the damage something on the > facilities provider side, the facilities provider will charge them > to fix it. > > There would be no "just coming out of the wall". There would be a 6-12 > SC (FC?) connector patch panel in a small plastic enclosure, with the > outside plant properly secured (conduit, in the wall, etc) and not > exposed. The homewowner or their service provider would plug into that > patch panel. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From owen at delong.com Sun Feb 3 19:40:11 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 3 Feb 2013 11:40:11 -0800 Subject: Announcing a reserved ASN? In-Reply-To: References: Message-ID: AS23456 is what you get if your system doesn't properly support 32-bit ASNs and an AS-PATH (or peer) uses a 32-bit ASN. There should be an extended attribute on the route that contains the full 32-bit AS-PATH called AS4_PATH associated with any such routes. Arguably any route containing AS23456 without an AS4_PATH attribute is invalid and could be filtered. Unfortunately, routers that would display AS23456 instead of restoring the full 32-bit AS_PATH may not be able to identify this. A properly transmitted route from a 4-byte ASN will be recovered as follows: 91.217.86.0/23 *[BGP/170] 1w5d 09:11:37, MED 101, localpref 100 AS path: 8121 1299 3209 197269 I > to 192.124.40.129 via ge-0/0/0.0 OTOH, you may occasionally see artifacts like this (I don't know why): 91.217.87.0/24 *[BGP/170] 1w5d 09:10:16, MED 101, localpref 100 AS path: 8121 1299 174 23456 197269 I > to 192.124.40.129 via ge-0/0/0.0 But if you are seeing 23456 on an AS4 capable router without at least some indication of a 4-byte ASN in the path, it's probably fishy. On Feb 3, 2013, at 4:57 AM, Suresh Ramasubramanian wrote: > At least the 103.x which are announced by airtel. The other netblocks (one > Indian and two brazilian) appear unrelated though also showing as23456 > > --srs (htc one x) > On 03-Feb-2013 6:12 PM, "Suresh Ramasubramanian" > 'ops.lists at gmail.com');>> > wrote: > >> AS23456 is currently announcing a good few netblocks (which don't have a >> very good smtp reputation, by the way). >> >> Funny thing is, that's a special use ASN as per rfc4893, something about >> two octet ASNs that don't have a four octet representation. >> >> Only one upstream (airtelbroadband-as-ap, as24560) that I can see >> >>>> 103.7.204.0/22 Missing AS4_PATH -- Probably a spoofed/hijacked route >>>> 103.14.208.0/22 Missing AS4_PATH -- Probably a spoofed/hijacked route >>>> 103.23.124.0/22 Missing AS4_PATH -- Probably a spoofed/hijacked route >>>> 103.30.12.0/22 Missing AS4_PATH -- Probably a spoofed/hijacked route >>>> 103.245.112.0/22 Missing AS4_PATH -- Probably a spoofed/hijacked route >>>> 111.235.148.0/22 Missing AS4_PATH -- Probably a spoofed/hijacked route >>>> 177.55.249.0/24 Missing AS4_PATH -- Probably a spoofed/hijacked route >>>> 186.251.192.0/21 Missing AS4_PATH -- Probably a spoofed/hijacked route If you're motivated to pursue this, the best thing to do is probably to contact the last legitimate AS before 23456 in the AS-PATH and inquire. Owen From khelms at zcorum.com Sun Feb 3 19:44:42 2013 From: khelms at zcorum.com (Scott Helms) Date: Sun, 3 Feb 2013 14:44:42 -0500 Subject: muni L1 example (WAS: Re: Muni fiber: L1 or L2?) In-Reply-To: <20130203174407.GA30037@jeeves.rigozsaurus.com> References: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> <20130203023507.GB16918@ussenterprise.ufp.org> <20130203033203.GA19119@ussenterprise.ufp.org> <20130203170443.GB44479@ussenterprise.ufp.org> <20130203174407.GA30037@jeeves.rigozsaurus.com> Message-ID: Absolutely muni networks can work. I'm supporting ~14 right now with an aggregate number of connections of around 40k (most are small). Having said that from my view (I work with telco's, cable MSOs, muni, and other network providers) muni networks fail more often than private networks. This is usually because they lack experience and their process is subject to interference by interested parties. In one case recently a muni network had a full page ad taken out by a operator who didn't want the city to build. That ad in the local paper caused lots of controversy, despite being largely inaccurate, and the controversy caused the city council to change the rules for the city at the last minute. On Sun, Feb 3, 2013 at 12:44 PM, John Osmon wrote: > On Sun, Feb 03, 2013 at 09:04:43AM -0800, Leo Bicknell wrote: > [...] > > People are doing this, and it does work, it's just being done in > > locations the big telcos and cablecos have written off... > > To re-iterate this point, and get a note into the archives -- Muni > networks *can* work. > > Idaho Falls, ID has been offering dark fiber strands to anyone since > 2007 or so: > http://www.ifcirca.net/ > > When I last had network in the area, the cost was on the order of: > - $1500/month/loop > - $20/bldg on loop > - one-time construction costs > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From owen at delong.com Sun Feb 3 19:53:30 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 3 Feb 2013 11:53:30 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> Message-ID: <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> On Feb 2, 2013, at 5:06 PM, Scott Helms wrote: > Owen, > I think the confusion I have is that you seem to want to create solutions for problems that have already been solved. There is no cost effective method of sharing a network at layer 1 since DWDM is expensive and requires compatible gear on both sides and no one has enough fiber (nor is cheap enough in brand new builds) to simply home run every home and maintain that. ISPs that would want to use the shared network in general (>95% in my experience) don't want to maintain the access gear and since there is no clear way to delineate responsibilities when there is an issue its hard. > > ?? Who said anything about sharing the network at L1? Is it more expensive to home-run every home than to put splitters in the neighborhood? Yes. Is it enough more expensive that the tradeoffs cannot be overcome? I remain unconvinced. I'm not sure why you think it would be hard to delineate the responsibilities? You've got a fiber path maintained by the municipality with active equipment maintained by the ISP at each end. If the light coming out of the equipment at one end doesn't come out of the fiber at the other end, you have a problem in the municipality's domain. If the light makes it through in tact, you have a problem in the ISP's domain. There is equipment available that can test that fairly easily. > The long and short of it is lots of people have tried to L1 sharing and its not economical and nothing I've seen here or elsewhere changes that. The thing you have to remember is that muni networks have to be cost effective and that's not just the capital costs. The operational cost in the long term is much greater than the cost of initial gear and fiber install. > We can agree to disagree. A muni network needs to be able to recover its costs. The costs of building out and maintaining home-run fiber are not necessarily that much greater than the costs of building out and maintaining fiber at the neighborhood. One option, for example, would be to have neighborhood B-Boxes where the fiber can either be fed into provider-specific splitters (same economy as existing PON deployments) or cross-connected to fiber on the F1 cable going back to the MMR (home-run). The only additional cost in this system over traditional PON is the larger number of fibers required in the F1 cable. Owen > On Feb 2, 2013 4:54 PM, "Owen DeLong" wrote: > It seems that you are (deliberately or otherwise) seriously misconstruing what I am saying. > > I'm saying that if you build an L1 dark fiber system as we have described, the purchasers can use it to deploy Ethernet, PON, or any other technology. > > I'm not saying it's how I would build out a PON only system. That was never the goal. > > The goal is to provide a municipal L1 service that can be used by ANY provider for ANY service, or as close to that as possible. > > To make the offering more attractive to low-budget providers, the system may also incorporate some L2 services. > > Owen > > On Feb 2, 2013, at 1:31 PM, Scott Helms wrote: > >> Owen, >> >> Cross connecting at layer 1 is what I'm saying isn't feasible. If you want to simply hand them a fiber then sell dark fiber or DWDM ports but trying to create an architecture around PON or other splitters won't work because PON splitters aren't compatible with other protocols. >> >> >> On Sat, Feb 2, 2013 at 4:26 PM, Owen DeLong wrote: >> >> On Feb 2, 2013, at 12:07 PM, Scott Helms wrote: >> >>> Owen, >>> >>> A layer 1 architecture isn't going to be an economical option for the foreseeable future so opining on its value is a waste of time...its simple not feasible now or even 5 years from now because of costs. The optimal open access network (with current or near future technology) is well known. Its called Ethernet and the methods to do triple play and open access are well documented not to mention already in wide spread use. Trying to enforce a layer 1 approach would be more expensive than the attempts to make this work with Packet Over SONET or even ATM. >>> >>> What is about a normal Ethernet deployment that you see as a negative? What problem are you tying to solve? >>> >> >> Ethernet works just fine in the L1 solution I've proposed, so I'm not sure why you say it isn't economically viable to do so. >> >> Owen >> >>> >>> On Sat, Feb 2, 2013 at 1:04 PM, Owen DeLong wrote: >>> >>> On Feb 2, 2013, at 2:19 AM, Eugen Leitl wrote: >>> >>> > On Fri, Feb 01, 2013 at 04:43:56PM -0800, Leo Bicknell wrote: >>> > >>> >> The only place PON made any sense to me was extreme rural areas. >>> >> If you could go 20km to a splitter and then hit 32 homes ~1km away >>> >> (52km fiber pair length total), that was a win. If the homes are >>> >> 2km from the CO, 32 pair (64km fiber pair length total) of home >>> >> runs was cheaper than the savings on fiber, and then the cost of >>> >> GPON splitters and equipment. I'm trying to figure out if my assessment >>> >> is correct or not... >>> > >>> > Is there any specific reason why muni networks don't use 1-10 GBit >>> > fiber mesh, using L3 switches in DSLAMs on every street corner? >>> >>> Well, one reason is that, IMHO, the goal here is to provide a flexible >>> L1 platform that will allow multiple competing providers a low barrier >>> to entry to provide a multitude of competitive services. >>> >>> Owen >>> >>> >>> >>> >>> >>> -- >>> Scott Helms >>> Vice President of Technology >>> ZCorum >>> (678) 507-5000 >>> -------------------------------- >>> http://twitter.com/kscotthelms >>> -------------------------------- >> >> >> >> >> -- >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- > From owen at delong.com Sun Feb 3 20:18:12 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 3 Feb 2013 12:18:12 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> Message-ID: <7CEA0614-05A8-48FE-A3DE-D66B9A26BAE5@delong.com> > Keep in place, but I've worked with virtually all of the nationwide guys > and most of the regional ones and they don't as a rule want anything to do > with your fiber plant. Even in major metro areas selling dark fiber > doesn't have a huge uptake because if you the network owner didn't light it > you have no idea how good or bad the splices and runs are. > The willingness to cooperate and accept using someone else's fiber will definitely be a gating issue here, but I bet there will be providers that will be willing to do so. >> >>> To make matters more complicated in cases of problems >>> you don't have a good demarcation of responsibility. What do you do as >> the >>> L1 provider when one of your ISP partners tells you one of his customers >>> can't connect or stay connected to that ISP's gear? Whose responsible in >>> that case? >> >> Well that's an interesting question, but I don't see that it's not >> orthogonal to the issue you raised earlier. >> >>> What happens when your tech goes out with an OTDR ( >>> http://en.wikipedia.org/wiki/Optical_time-domain_reflectometer) meter >>> and says the connection is fine but your ISP insists its your problem? >> >> On an L1 connection, you mean? I'll do what people always do; I'll work >> the ticket; at that level, this stuff's relatively digital, no? >> > > No, its not and I've seen several of networks fail because demarc issues. > US Carrier (a statewide network here in GA) was recently sold for pennies > on the dollar largely because of blurry demarcs. You can and will get > sucked into scenarios you don't want to be in and will lose money on. But there isn't a lot of blur to the demarc in this case. Further, since we're talking about a muni doing this on a cost-recovery pricing basis, sucking the muni into such scenarios will only increase the prices charged. The muni won't lose money, the muni will just get more expensive. As a general rule, if the providers know that cooperative debugging == resolution and uncooperative finger-pointing == increased costs, you tend to get a lot more cooperative debugging. >> >>>> You're talking about what I'm calling L2 clients. If layer 2 falls >>>> over it's my fault, and believe me, I'll know about it. >>> >>> What I'm telling you is that you can't reliably have L1 clients in >>> shared model. >> >> You're telling me that, but you're not giving me good reasons *why* you >> think so. >> > > Because: > 1) There won't be much interest in doing it from experienced operators so > you're only going to get customers for it that are also new to the > business. So your combined troubleshooting and install time will be bad > for a long time until everyone in the chain kind of understand what they're > doing. Unless you can recruit some experienced providers up front and work with them, allowing them to observe the build-out, etc. so that there is a higher degree of confidence in the quality of the runs and splices. Providing certified test results of the fiber runs can probably also help here. > 2) Unless you can home run every single connection you're going to run > into a lot of access related issues. You will be working for the city so > they won't have a problem with you getting into their building at the water > tower/sewage treatment plant/power sub station or other city owned > property. Your L1 customer isn't going to have that access (not with the > city manager/mayor/council's knowledge anyway) because of regulatory and > liability reasons. If you do home run everything you still have an access > challenge (where are you going to be able to give access to these customers > economically?) but its probably more solvable since its one spot. You also > increase your costs by home running each connection, but that may or may > not be a deal breaker in your situation. The point is to home run everything to a location where those issues are addressed. Addressing those issues is a critical part of the design. > 3) Your going to have to do a lot more work since at L1 all of the rough > edges and sharp corners are there to be dealt (like someone grabbing the > wrong cable from the patch panel) there is simply no inexpensive method of > safeguarding L1 adds, changes, and modifies so either you do them or you > let your L1 customer do them and run a risk. This is also something that > the city management is going to have concerned over. IMHO, you do them. The risk the other way is too great. However, part of the lease is the cost of those personnel, so, since you're operating on a pure cost recovery basis, that's probably OK. It's unlikely to cost significantly more (in fact likely quite a bit less) than the provider(s) would be paying for their own tech(s). > 4) Physical layer troubleshooting is much harder than layer 2 and up. > Having several organizations and potentially several different equipment > vendors and L2 technologies will be very tough to deal with over time. I've usually found physical layer troubleshooting to be quite a bit easier. If you get good OTDR results end-to-end, you don't have a physical layer problem. If you don't get good OTDR results, then if you have good records, you should be able to get a pretty good idea where the problem is. Admittedly, I haven't done a lot of this in the outside world, but light is light. Other than not knowing where your fiber actually goes, what are the additional variables that make this so insurmountable? > 5) I've seen at least 5 muni networks try this and not succeed. If you > include non-muni networks with similar characteristics (like EMCs) then > I've seen it tried more than a dozen times with no success (or interest) > beyond a few dark fiber set ups for point to point connections across town. I believe that Sweden operates largely on this model and that the Australia NBN project does as well. I would say that the Swedish model is a definite success. Owen From jabley at hopcount.ca Sun Feb 3 20:32:44 2013 From: jabley at hopcount.ca (Joe Abley) Date: Sun, 3 Feb 2013 15:32:44 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: References: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> <510DF096.60907@vaxination.ca> <20130203165850.GA44479@ussenterprise.ufp.org> Message-ID: On 2013-02-03, at 14:39, Scott Helms wrote: > Dry pairs are impossible to order these days for a reason. Dry pairs are trivial to order round these parts. Generalisations are always wrong, no doubt including this one. Joe (putting the N back in NANOG) From jra at baylink.com Sun Feb 3 20:33:28 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 3 Feb 2013 15:33:28 -0500 (EST) Subject: Rollup: Small City Municipal Broadband In-Reply-To: Message-ID: <9941705.4764.1359923608048.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > > Basically when the customer (typically the service provider, but > > not always) orders a loop to a customer the muni provider would > > OTDR shoot it from the handoff point to the service provider to the > > prem. They would be responsible for insuring a reasonable > > performance of the fiber between those two end points. > > Been tried multiple times and I've never seen it work in the US, Canada, > Europe, or Latin America. That's not to say it can't work, but there > lots of reasons why it doesn't and I don't think anyone has suggested > anything here that I haven't already seen fail. So let me be clear, here, because I'm semi-married to this idea... You're asserting that it is not practical to offer L1 optical per-sub handoffs to L2/3 ISPs, because a) the circuits can't be built reliably, b) the circuits won't run reliably over the long run, c) if something *does break*, it's hard or expensive to determine where, or d) each side will say it's the other side's fault, and things won't get fixed? I can't see any difference between building it for their L2 access box and my own. I simply don't believe (b). (c) seems questionable as well, so I assume you have to mean (d). > Dry pairs are impossible to order these days for a reason. Certainly: because you have to get them from incumbents, who don't want you to use a cheap service to provide yourself something they could charge you a lot more money for. You assert a technical reason? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From khelms at zcorum.com Sun Feb 3 20:33:40 2013 From: khelms at zcorum.com (Scott Helms) Date: Sun, 3 Feb 2013 15:33:40 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> References: <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> Message-ID: On Sun, Feb 3, 2013 at 2:53 PM, Owen DeLong wrote: > > On Feb 2, 2013, at 5:06 PM, Scott Helms wrote: > > Owen, > I think the confusion I have is that you seem to want to create solutions > for problems that have already been solved. There is no cost effective > method of sharing a network at layer 1 since DWDM is expensive and requires > compatible gear on both sides and no one has enough fiber (nor is cheap > enough in brand new builds) to simply home run every home and maintain > that. ISPs that would want to use the shared network in general (>95% in > my experience) don't want to maintain the access gear and since there is no > clear way to delineate responsibilities when there is an issue its hard. > > ?? > > Who said anything about sharing the network at L1? > You did. > > Is it more expensive to home-run every home than to put splitters in the > neighborhood? Yes. Is it enough more expensive that the tradeoffs cannot be > overcome? I remain unconvinced. > This completely depends on the area and the goals of the network. In most cases for muni networks back hauling everything is more expensive. > > I'm not sure why you think it would be hard to delineate the > responsibilities? You've got a fiber path maintained by the municipality > with active equipment maintained by the ISP at each end. If the light > coming out of the equipment at one end doesn't come out of the fiber at the > other end, you have a problem in the municipality's domain. If the light > makes it through in tact, you have a problem in the ISP's domain. > > There is equipment available that can test that fairly easily. > OK, this one made my wife get scared I laughed so hard. You clearly have never tried to do this or had to work with different operators in the same physical network. Please, go talk to someone whose worked in the field of a FTTx network and describe this scenario to them. Its clear you don't want to hear it from me via email so please go do some research. > The long and short of it is lots of people have tried to L1 sharing and > its not economical and nothing I've seen here or elsewhere changes that. > The thing you have to remember is that muni networks have to be cost > effective and that's not just the capital costs. The operational cost in > the long term is much greater than the cost of initial gear and fiber > install. > > We can agree to disagree. A muni network needs to be able to recover its > costs. The costs of building out and maintaining home-run > fiber are not necessarily that much greater than the costs of building out > and maintaining fiber at the neighborhood. One option, for > example, would be to have neighborhood B-Boxes where the fiber can either > be fed into provider-specific splitters (same economy > as existing PON deployments) or cross-connected to fiber on the F1 cable > going back to the MMR (home-run). > > We can agree all we want, that doesn't change history. Handing out connections at layer 1 is both more expensive and less efficient. Its also extremely wasteful (which is why its more expensive) since your lowest unit you can sell is a fiber strand whether the end customer wants a 3 mbps connection or a gig its the same to the city. I'm not saying you shouldn't sell dark fiber, I'm saying that in 99% of the cities you can't build a business model around doing just that unless your city doesn't want to break even on the build and maintenance. > The only additional cost in this system over traditional PON is the larger > number of fibers required in the F1 cable. > > PON networks aren't deployed this way and if you're going to backhaul all of the connections to a central point you wouldn't run PON. PON is worse in every performance related way to PON and the only reasons operators deploy it today is because its less expensive. Its less expensive because you don't have to backhaul all of the connections or have active components at the neighborhood level. > Owen > > > On Feb 2, 2013 4:54 PM, "Owen DeLong" wrote: > >> It seems that you are (deliberately or otherwise) seriously misconstruing >> what I am saying. >> >> I'm saying that if you build an L1 dark fiber system as we have >> described, the purchasers can use it to deploy Ethernet, PON, or any other >> technology. >> >> I'm not saying it's how I would build out a PON only system. That was >> never the goal. >> >> The goal is to provide a municipal L1 service that can be used by ANY >> provider for ANY service, or as close to that as possible. >> >> To make the offering more attractive to low-budget providers, the system >> may also incorporate some L2 services. >> >> Owen >> >> On Feb 2, 2013, at 1:31 PM, Scott Helms wrote: >> >> Owen, >> >> Cross connecting at layer 1 is what I'm saying isn't feasible. If you >> want to simply hand them a fiber then sell dark fiber or DWDM ports but >> trying to create an architecture around PON or other splitters won't work >> because PON splitters aren't compatible with other protocols. >> >> >> On Sat, Feb 2, 2013 at 4:26 PM, Owen DeLong wrote: >> >>> >>> On Feb 2, 2013, at 12:07 PM, Scott Helms wrote: >>> >>> Owen, >>> >>> A layer 1 architecture isn't going to be an economical option for the >>> foreseeable future so opining on its value is a waste of time...its simple >>> not feasible now or even 5 years from now because of costs. The optimal >>> open access network (with current or near future technology) is well known. >>> Its called Ethernet and the methods to do triple play and open access are >>> well documented not to mention already in wide spread use. Trying to >>> enforce a layer 1 approach would be more expensive than the attempts to >>> make this work with Packet Over SONET or even ATM. >>> >>> What is about a normal Ethernet deployment that you see as a negative? >>> What problem are you tying to solve? >>> >>> >>> Ethernet works just fine in the L1 solution I've proposed, so I'm not >>> sure why you say it isn't economically viable to do so. >>> >>> Owen >>> >>> >>> On Sat, Feb 2, 2013 at 1:04 PM, Owen DeLong wrote: >>> >>>> >>>> On Feb 2, 2013, at 2:19 AM, Eugen Leitl wrote: >>>> >>>> > On Fri, Feb 01, 2013 at 04:43:56PM -0800, Leo Bicknell wrote: >>>> > >>>> >> The only place PON made any sense to me was extreme rural areas. >>>> >> If you could go 20km to a splitter and then hit 32 homes ~1km away >>>> >> (52km fiber pair length total), that was a win. If the homes are >>>> >> 2km from the CO, 32 pair (64km fiber pair length total) of home >>>> >> runs was cheaper than the savings on fiber, and then the cost of >>>> >> GPON splitters and equipment. I'm trying to figure out if my >>>> assessment >>>> >> is correct or not... >>>> > >>>> > Is there any specific reason why muni networks don't use 1-10 GBit >>>> > fiber mesh, using L3 switches in DSLAMs on every street corner? >>>> >>>> Well, one reason is that, IMHO, the goal here is to provide a flexible >>>> L1 platform that will allow multiple competing providers a low barrier >>>> to entry to provide a multitude of competitive services. >>>> >>>> Owen >>>> >>>> >>>> >>> >>> >>> -- >>> Scott Helms >>> Vice President of Technology >>> ZCorum >>> (678) 507-5000 >>> -------------------------------- >>> http://twitter.com/kscotthelms >>> -------------------------------- >>> >>> >>> >> >> >> -- >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> >> >> > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Sun Feb 3 20:40:13 2013 From: khelms at zcorum.com (Scott Helms) Date: Sun, 3 Feb 2013 15:40:13 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <7CEA0614-05A8-48FE-A3DE-D66B9A26BAE5@delong.com> References: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> <7CEA0614-05A8-48FE-A3DE-D66B9A26BAE5@delong.com> Message-ID: I answered (I think) your other points in the last email I wrote, but I > wanted to address these specifically. > > I believe that Sweden operates largely on this model and that the Australia > NBN project does as well. > > I would say that the Swedish model is a definite success. > Australia's NBN is still the planning and arguing phase. Sweden is most certainly not a string of muni networks, the dominant form of access there is cable without open access. http://en.wikipedia.org/wiki/Internet_in_Sweden You might have meant another European country and there are several that traditionally have had good open access networks but they are NOT fiber nor are they muni run. Across much of Europe the telco's have been forced to open their DSL networks to other operators and in many countries they cannot be the layer 3 provider. This has lead to a robust set of open DSL networks using PPPoE. The problem is that the same rules have NOT been applied to fiber networks (in large part because of technical issues, some genuine and others less so). The fiber networks are largely run by the telcos themselves, but these are new deployments and so the numbers of fiber connections in Europe is quite low. > > Owen > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Sun Feb 3 20:42:46 2013 From: khelms at zcorum.com (Scott Helms) Date: Sun, 3 Feb 2013 15:42:46 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: References: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> <510DF096.60907@vaxination.ca> <20130203165850.GA44479@ussenterprise.ufp.org> Message-ID: Joe, I'm assuming from your domain that you're in Canada where yes dry pairs are still generally available. I apologize for not making it clear that my comment was specifically about the US where dry pairs are nearly impossible to order today and the CLEC market has almost entirely abandoned the residential space. In fact, the only state in the US that I still see any residentially focused CLECs is Texas which tells me there is something about the regulations in that state that makes it more feasible. On Sun, Feb 3, 2013 at 3:32 PM, Joe Abley wrote: > > On 2013-02-03, at 14:39, Scott Helms wrote: > > > Dry pairs are impossible to order these days for a reason. > > Dry pairs are trivial to order round these parts. Generalisations are > always wrong, no doubt including this one. > > > Joe (putting the N back in NANOG) -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From bicknell at ufp.org Sun Feb 3 20:49:46 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 3 Feb 2013 12:49:46 -0800 Subject: Rollup: Small City Municipal Broadband In-Reply-To: References: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> <510DF096.60907@vaxination.ca> <20130203165850.GA44479@ussenterprise.ufp.org> Message-ID: <20130203204946.GA51819@ussenterprise.ufp.org> In a message written on Sun, Feb 03, 2013 at 02:39:39PM -0500, Scott Helms wrote: > > Basically when the customer (typically the service provider, but > > not always) orders a loop to a customer the muni provider would > > OTDR shoot it from the handoff point to the service provider to the > > prem. They would be responsible for insuring a reasonable performance > > of the fiber between those two end points. > > Been tried multiple times and I've never seen it work in the US, Canada, > Europe, or Latin America. That's not to say it can't work, but there lots > of reasons why it doesn't and I don't think anyone has suggested anything > here that I haven't already seen fail. Zayo (nee AboveNet/MFN), Sunesys, Allied Fiber, FiberTech Networks, and a dozen smaller dark fiber providers work this way today, with nice healthy profitable business. Granted, none of them are in the residential space today, but I don't see any reason why the prem being residential would make the model fail. Plenty of small cities sell dark as well, at least until the incumbant carriers scare/bribe the legislatures into outlawing it. I think that's evidence it works well, they know they can't compete with a muni network, so they are trying to block it with legal and lobbying efforts. They all cost a lot more than would make sense for residential, but most of that is that they lack the economies of scale that going to every residence would bring. Their current density of customers is simply too low. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From khelms at zcorum.com Sun Feb 3 20:55:20 2013 From: khelms at zcorum.com (Scott Helms) Date: Sun, 3 Feb 2013 15:55:20 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <9941705.4764.1359923608048.JavaMail.root@benjamin.baylink.com> References: <9941705.4764.1359923608048.JavaMail.root@benjamin.baylink.com> Message-ID: On Sun, Feb 3, 2013 at 3:33 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Scott Helms" > > > > Basically when the customer (typically the service provider, but > > > not always) orders a loop to a customer the muni provider would > > > OTDR shoot it from the handoff point to the service provider to the > > > prem. They would be responsible for insuring a reasonable > > > performance of the fiber between those two end points. > > > > Been tried multiple times and I've never seen it work in the US, Canada, > > Europe, or Latin America. That's not to say it can't work, but there > > lots of reasons why it doesn't and I don't think anyone has suggested > > anything here that I haven't already seen fail. > > So let me be clear, here, because I'm semi-married to this idea... > > You're asserting that it is not practical to offer L1 optical per-sub > handoffs to L2/3 ISPs, because > I'm saying you can't build a working business model off of layer 1 connections as your primary offering in almost all cases for a muni network. I am hedging my bet here because I don't know your city's topology, density, growth, goals or a hundred other factors that might make you the 1 exception to the rule. > > a) the circuits can't be built reliably, > b) the circuits won't run reliably over the long run, > c) if something *does break*, it's hard or expensive to determine where, or > d) each side will say it's the other side's fault, and things won't get > fixed? > > Let me see if I can explain it, since clearly I'm not getting my thoughts down in my emails well enough. a) You WILL have physical layer issues. Some of these issues will be related to the initial construction of the fiber. b) Other problems will because of changes that occur over time. These could be weather related (especially for aerial cable), but also vehicle hits to fiber cabinets, and occasionally fires. Depending on your location earthquakes, flooding, and other extreme "weather" may also be a factor. c) No, WHEN something breaks it is hard and expensive to figure out where. This is true even if you're the layer 2 provider but it gets you out of the problem of it works $A_provider_gear but not $B_provider_gear. You're going to drive yourself nuts troubleshooting connections IF you do sign up several partners especially if they choose different technologies. d) No, it will always be your fault until you can prove its not. If you don't know how to troubleshoot the technology your L2 partners are using how can you ever do anything but accept their word that they have everything set up correctly? > I can't see any difference between building it for their L2 access box and > my own. I simply don't believe (b). (c) seems questionable as well, so > I assume you have to mean (d). > There are lots of differences, especially related to troubleshooting. Remember, all of these devices are doing phase modulation (QAM, QPSK, etc) so a simple OTDR test (which is similar to checking SNR on a RF system) doesn't show many of the problems that prevent data connectivity on high speed connections. > > > Dry pairs are impossible to order these days for a reason. > > Certainly: because you have to get them from incumbents, who don't want > you to use a cheap service to provide yourself something they could > charge you a lot more money for. > > You assert a technical reason? > Most of this is because the ILECs have gotten the regulations changed but they successfully used some legitimate technical reasons (and other less legitimate arguments) to get those rules changed. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Sun Feb 3 21:00:37 2013 From: khelms at zcorum.com (Scott Helms) Date: Sun, 3 Feb 2013 16:00:37 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <20130203204946.GA51819@ussenterprise.ufp.org> References: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> <510DF096.60907@vaxination.ca> <20130203165850.GA44479@ussenterprise.ufp.org> <20130203204946.GA51819@ussenterprise.ufp.org> Message-ID: On Sun, Feb 3, 2013 at 3:49 PM, Leo Bicknell wrote: > In a message written on Sun, Feb 03, 2013 at 02:39:39PM -0500, Scott Helms > wrote: > > > Basically when the customer (typically the service provider, but > > > not always) orders a loop to a customer the muni provider would > > > OTDR shoot it from the handoff point to the service provider to the > > > prem. They would be responsible for insuring a reasonable performance > > > of the fiber between those two end points. > > > > Been tried multiple times and I've never seen it work in the US, Canada, > > Europe, or Latin America. That's not to say it can't work, but there lots > > of reasons why it doesn't and I don't think anyone has suggested anything > > here that I haven't already seen fail. > > Zayo (nee AboveNet/MFN), Sunesys, Allied Fiber, FiberTech Networks, > and a dozen smaller dark fiber providers work this way today, with > nice healthy profitable business. Granted, none of them are in the > residential space today, but I don't see any reason why the prem > being residential would make the model fail. > All of these guys do sell dark fiber AND other services including their own L3 offerings. I'm not telling anyone to avoid selling dark fiber. I'm telling you that its not what you can, in the vast majority of the cases, build as your primary offering. Your examples really support my stance much more than yours. > > Plenty of small cities sell dark as well, at least until the incumbant > carriers scare/bribe the legislatures into outlawing it. I think that's > evidence it works well, they know they can't compete with a muni > network, so they are trying to block it with legal and lobbying efforts. > Most of the state legislation (in fact, I can't think of an exception to this) is specifically aimed at preventing muni networks from offering layer 2 and layer 3 services. I can't say that there isn't an exception to this, but in 45+ states there isn't anything on the books on a dark fiber network owned by a city. > > They all cost a lot more than would make sense for residential, but > most of that is that they lack the economies of scale that going > to every residence would bring. Their current density of customers > is simply too low. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Sun Feb 3 21:12:04 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 3 Feb 2013 16:12:04 -0500 (EST) Subject: Rollup: Small City Municipal Broadband In-Reply-To: Message-ID: <20308803.4778.1359925924123.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Scott Helms" > > You're asserting that it is not practical to offer L1 optical > > per-sub handoffs to L2/3 ISPs, because > > I'm saying you can't build a working business model off of layer 1 > connections as your primary offering in almost all cases for a muni > network. I am hedging my bet here because I don't know your city's > topology, density, growth, goals or a hundred other factors that might > make you the 1 exception to the rule. Oh. I'm not trying to. I'm trying to design and build a fiber plant that will *support* both L1 point-to-point circuits for clients who want those, and L1 optical subscriber pair handoffs to ISPs who are either large enough, or technically inclined to want to take those and do their own access gear either for RFoG GPON Multiplexing reasons, or whatever else have you. My primary service will be to run my own OLT and supply ONTs to subs, and hand off aggregated 10/40GE over fiber to the ISPs in my colo (or somewhere else in my city, if they want to do it themselves; there *is*, after all, going to be fiber to there :-). > Let me see if I can explain it, since clearly I'm not getting my > thoughts down in my emails well enough. You've done it now. > a) You WILL have physical layer issues. Some of these issues will be > related to the initial construction of the fiber. Sure. > b) Other problems will because of changes that occur over time. These > could be weather related (especially for aerial cable), but also > vehicle hits to fiber cabinets, and occasionally fires. Depending on your > location earthquakes, flooding, and other extreme "weather" may also be a > factor. Mostly flooding. We're 15' AMSL. Everything else, though, will be completely below-grade, and we don't freeze, and I assume how much non- backhoe fade you get can be directly related to how much you pay for the build? And flooding doesn't affect pure glass, does it? > c) No, WHEN something breaks it is hard and expensive to figure out where. > This is true even if you're the layer 2 provider but it gets you out of > the problem of it works $A_provider_gear but not $B_provider_gear. You're > going to drive yourself nuts troubleshooting connections IF you do sign up > several partners especially if they choose different technologies. It would appear that opinions vary on this point. You've clearly had your hands on some of the gear, so I'm not discounting your opinion by any means, but it seems that this may vary based on, among other things, how well one engineers the plant up front. This will *not* be a lowest-bidder contract. Or I won't do it. > d) No, it will always be your fault until you can prove its not. If you > don't know how to troubleshoot the technology your L2 partners are using > how can you ever do anything but accept their word that they have > everything set up correctly? As Owen notes, their hot-potatoing it will simply cost them more money, so they have incentive to be cooperative in finding these problems, and that helps almost an order of magnitude. > > I can't see any difference between building it for their L2 access box and > > my own. I simply don't believe (b). (c) seems questionable as well, so > > I assume you have to mean (d). > > There are lots of differences, especially related to troubleshooting. > Remember, all of these devices are doing phase modulation (QAM, QPSK, etc) > so a simple OTDR test (which is similar to checking SNR on a RF system) > doesn't show many of the problems that prevent data connectivity on high > speed connections. No, but I'm pretty sure my Fluke rep will be happy to sell me boxes that *will* test for that stuff, and I will have a contractor to back me up. Likely a division of whomever did the build, who will have reason to want it to run well, as I'll have their name plastered all over everything as well. :-) > > > Dry pairs are impossible to order these days for a reason. > > > > Certainly: because you have to get them from incumbents, who don't > > want you to use a cheap service to provide yourself something they could > > charge you a lot more money for. > > > > You assert a technical reason? > > Most of this is because the ILECs have gotten the regulations changed > but they successfully used some legitimate technical reasons (and other > less legitimate arguments) to get those rules changed. In my experience of watching it go by, nearly every reason that an ILEC has ever given for wanting something made illegal which would impact their competitive position was made up, to a greater or lesser degree. Many of them were public companies, and had open access imposed on them (some would say unfairly; I waver), and it's *expected* that this would be the case, but still... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From josmon at rigozsaurus.com Sun Feb 3 21:38:08 2013 From: josmon at rigozsaurus.com (John Osmon) Date: Sun, 3 Feb 2013 14:38:08 -0700 Subject: muni L1 example (WAS: Re: Muni fiber: L1 or L2?) In-Reply-To: References: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> <20130203023507.GB16918@ussenterprise.ufp.org> <20130203033203.GA19119@ussenterprise.ufp.org> <20130203170443.GB44479@ussenterprise.ufp.org> <20130203174407.GA30037@jeeves.rigozsaurus.com> Message-ID: <20130203213808.GD28385@jeeves.rigozsaurus.com> Scott -- you've brought up *great* info for this thread. We all know that city/county/state/federal governments sometimes throw money away on boondoggles (as fiber could become). You've been able to pull from your direct experience to show how this is true. I threw in Idaho Falls because I'm betting it will help someone doing research in the future. Can you throw out some of the positive examples you've run across? On Sun, Feb 03, 2013 at 02:44:42PM -0500, Scott Helms wrote: > Absolutely muni networks can work. I'm supporting ~14 right now with an > aggregate number of connections of around 40k (most are small). Having > said that from my view (I work with telco's, cable MSOs, muni, and other > network providers) muni networks fail more often than private networks. > This is usually because they lack experience and their process is subject > to interference by interested parties. In one case recently a muni > network had a full page ad taken out by a operator who didn't want the > city to build. That ad in the local paper caused lots of controversy, > despite being largely inaccurate, and the controversy caused the city > council to change the rules for the city at the last minute. > > On Sun, Feb 3, 2013 at 12:44 PM, John Osmon <[1]josmon at rigozsaurus.com> > wrote: > > On Sun, Feb 03, 2013 at 09:04:43AM -0800, Leo Bicknell wrote: > [...] > > People are doing this, and it does work, it's just being done in > > locations the big telcos and cablecos have written off... > > To re-iterate this point, and get a note into the archives -- Muni > networks *can* work. > > Idaho Falls, ID has been offering dark fiber strands to anyone since > 2007 or so: > [2]http://www.ifcirca.net/ > > When I last had network in the area, the cost was on the order of: > - $1500/month/loop > - $20/bldg on loop > - one-time construction costs > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > [3]http://twitter.com/kscotthelms > -------------------------------- > > References > > Visible links > 1. mailto:josmon at rigozsaurus.com > 2. http://www.ifcirca.net/ > 3. http://twitter.com/kscotthelms From jason at thebaughers.com Sun Feb 3 21:44:20 2013 From: jason at thebaughers.com (Jason Baugher) Date: Sun, 3 Feb 2013 15:44:20 -0600 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <20130203165850.GA44479@ussenterprise.ufp.org> References: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> <510DF096.60907@vaxination.ca> <20130203165850.GA44479@ussenterprise.ufp.org> Message-ID: On Sun, Feb 3, 2013 at 10:58 AM, Leo Bicknell wrote: > In a message written on Sun, Feb 03, 2013 at 12:07:34AM -0500, > Jean-Francois Mezei wrote: > > When municipality does the buildout, does it just pass homes, or does it > > actually connect every home ? > > I would argue, in a pure dark muni-network, the muni would run the > fiber into the prem to a patch panel, and stop at that point. I > believe for fiber it should be inside the prem, not outside. The > same would apply for both residential and commercial. > > > I'd argue that the demarc needs to be outside. There are certain advantages to having easy access to the demarcation when troubleshooting, without the resident needing to be home to provide access. It also simplifies drop installation, since the details of outdoor drops are quite different than those of indoor cabling. The SP of choice can charge the customer for the demarc extension on installation, at which point the customer owns the extension just like they do for DSL, T1, etc... From marka at isc.org Sun Feb 3 21:45:53 2013 From: marka at isc.org (Mark Andrews) Date: Mon, 04 Feb 2013 08:45:53 +1100 Subject: Muni fiber: L1 or L2? In-Reply-To: Your message of "Sun, 03 Feb 2013 15:40:13 CDT." References: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> <7CEA0614-05A8-48FE-A3DE-D66B9A26BAE5@delong.com> Message-ID: <20130203214553.E81B02EFDF48@drugs.dv.isc.org> In message , Scott Helms writes: > I answered (I think) your other points in the last email I wrote, but I > > wanted to address these specifically. > > > > I believe that Sweden operates largely on this model and that the Australia > > NBN project does as well. > > > > I would say that the Swedish model is a definite success. > > > > Australia's NBN is still the planning and arguing phase. They may still be arguing, but there are fiber and fixed wireless customers receiving packets. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From khelms at zcorum.com Sun Feb 3 21:49:05 2013 From: khelms at zcorum.com (Scott Helms) Date: Sun, 3 Feb 2013 16:49:05 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <20308803.4778.1359925924123.JavaMail.root@benjamin.baylink.com> References: <20308803.4778.1359925924123.JavaMail.root@benjamin.baylink.com> Message-ID: > > > And flooding doesn't affect pure glass, does it? > Not directly, so long as the cladding stays intact. The problem with flooding (for your scenario since your electronics will be centralized) is mainly that it causes things to move around inside the cable runs and depending on water flow you can end up with a lot of problems with increased scattering if the cable gets stretched. > > > c) No, WHEN something breaks it is hard and expensive to figure out > where. > > This is true even if you're the layer 2 provider but it gets you out of > > the problem of it works $A_provider_gear but not $B_provider_gear. You're > > going to drive yourself nuts troubleshooting connections IF you do sign > up > > several partners especially if they choose different technologies. > > It would appear that opinions vary on this point. You've clearly > had your hands on some of the gear, so I'm not discounting your opinion > by any means, but it seems that this may vary based on, among other > things, how well one engineers the plant up front. This will *not* > be a lowest-bidder contract. Or I won't do it. > Its not just the initial install. Its that every time you do anything new like adding in a new L2 vendor or technology or hook up a new end user. Glass doesn't suffer from ingress noise like RF driven systems but the plant itself is just as sensitive to physical damage and is more sensitive to stretching than coax or twisted pair. > > > d) No, it will always be your fault until you can prove its not. If you > > don't know how to troubleshoot the technology your L2 partners are using > > how can you ever do anything but accept their word that they have > > everything set up correctly? > > As Owen notes, their hot-potatoing it will simply cost them more money, > so they have incentive to be cooperative in finding these problems, and > that helps almost an order of magnitude. > Respectfully the guys that will be doing the hot potato shuffle won't be the owners or even people who have that much technical understanding. They'll be installers that work on the end user and their skill set is on par with the guys who do contract installs for security systems and Dish Network/Direct TV. They don't care if their boss losses money, they don't care if you lose money, all they want to is keep their install count up since that's how they get paid. If a given install is problematic and they can shift the responsibility to someone else they (as a group) will. I'm not suggesting that everyone who does that kind of work is unskilled or uncaring but as a group that's what you get. > > > I can't see any difference between building it for their L2 access box > and > > > my own. I simply don't believe (b). (c) seems questionable as well, so > > > I assume you have to mean (d). > > > > There are lots of differences, especially related to troubleshooting. > > Remember, all of these devices are doing phase modulation (QAM, QPSK, > etc) > > so a simple OTDR test (which is similar to checking SNR on a RF system) > > doesn't show many of the problems that prevent data connectivity on high > > speed connections. > > No, but I'm pretty sure my Fluke rep will be happy to sell me boxes that > *will* test for that stuff, and I will have a contractor to back me up. > No, actually they won't because Fluke doesn't sell a DOCSIS analyzer (for RFoG) nor a PON analyzer. You'll need a separate meter (for several thousand dollars) for each kind of technology you want to be able to troubleshoot. For example, to handle modulated RF (RFoG) you'd use a JDSU (or Sunrise or Trilithic). Fluke is a very basic OTDR tool and they don't address the various layer 2 technologies. > > Likely a division of whomever did the build, who will have reason to > want it to run well, as I'll have their name plastered all over everything > as well. :-) > > > > > Dry pairs are impossible to order these days for a reason. > > > > > > Certainly: because you have to get them from incumbents, who don't > > > want you to use a cheap service to provide yourself something they > could > > > charge you a lot more money for. > > > > > > You assert a technical reason? > > > > Most of this is because the ILECs have gotten the regulations changed > > but they successfully used some legitimate technical reasons (and other > > less legitimate arguments) to get those rules changed. > > In my experience of watching it go by, nearly every reason that an ILEC > has ever given for wanting something made illegal which would impact their > competitive position was made up, to a greater or lesser degree. > > Many of them were public companies, and had open access imposed on them > (some would say unfairly; I waver), and it's *expected* that this would > be the case, but still... > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From bicknell at ufp.org Sun Feb 3 21:52:26 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 3 Feb 2013 13:52:26 -0800 Subject: Is Google Fiber a model for Municipal Networks? Message-ID: <20130203215226.GA53926@ussenterprise.ufp.org> I've been searching for a few days on information about Google Fiber's Kansas City deployment. While I wouldn't call Google secretive in this particular case, they haven't been very outgoing on some of the technologies. Based on the equipment they have deployed there is speculation they are doing both GPON and active thernet (point2point). I found this presentation: http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/36936.pdf It has a very good summary of the tradeoffs we've been discussing regarding home run fibers with active ethernet compared with GPON, including costs of the eletronics compared to trenching, the space required in the CO, and many of the other issues we've touched on so far. Here's an article with some economics from several different deployments: http://fastnetnews.com/fiber-news/175-d/4835-fiber-economics-quick-and-dirty Looks like $500-$700 in capex per residence is the current gold standard. Note that the major factor is the take rate; if there are two providers doing FTTH they are both going to max at about a 50% take rate. By having one provider, a 70-80% take rate can be driven. Even with us a 4%, 10 year government bond, a muni network could finance out a $700/prem build for $7.09 per month! Add in some overhead and there's no reason a muni-network couldn't lease FTTH on a cost recovery bases to all takers for $10-$12 a month (no Internet or other services included). Anyone know of more info about the Google Fiber deployment? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jfmezei_nanog at vaxination.ca Sun Feb 3 21:54:57 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sun, 03 Feb 2013 16:54:57 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <20308803.4778.1359925924123.JavaMail.root@benjamin.baylink.com> References: <20308803.4778.1359925924123.JavaMail.root@benjamin.baylink.com> Message-ID: <510EDCB1.1020906@vaxination.ca> With regards to the layer 1 vs layer 2 arguments: At the regulatory level, it isn't about what layer is provided, it is more a question to ensure that a neutral provider of last mile only sells whoelsale and provides no retail services that compete against other retailers who buy access to that fibre. (no undue preference onto itself). In Canada, we have TPIA regulations for 3rd party access to DOCSIS cable systems. This is actually done at L3. And while it works, there are a number of issues related to a cableco acting as a L3 wholesaler. (IPs assigned to end user belong to the ISP, but are provisioned by the cableco's DHCP server etc). PPPoE/DSL systems provide layer2 tunnels which shift much of the respnsability to the ISP (IP assignements etc). However, PPPoE does not allow multicast. (and telcos don't want ISPs to use compete against their own IPTV systems). Nevertheless, a number if ISPs are starting their own IPTV services over unicast delivery. So when a municipality wants to setup a modern broadband system (which raises property values and attracts businesses to the town), it needs to consider how the system will be used. I don't think it is enough to "build it and they will come" (aka: layer 1 dark fibre). You risk it being greatly underused if small ISPs can't afford to connect to it, and incumbents are in court trying to destroy the project instead of taking advantage of it. Are there examples where a muni fibre system in the USA was adopted by incumbents ? From khelms at zcorum.com Sun Feb 3 21:55:41 2013 From: khelms at zcorum.com (Scott Helms) Date: Sun, 3 Feb 2013 16:55:41 -0500 Subject: muni L1 example (WAS: Re: Muni fiber: L1 or L2?) In-Reply-To: <20130203213808.GD28385@jeeves.rigozsaurus.com> References: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> <20130203023507.GB16918@ussenterprise.ufp.org> <20130203033203.GA19119@ussenterprise.ufp.org> <20130203170443.GB44479@ussenterprise.ufp.org> <20130203174407.GA30037@jeeves.rigozsaurus.com> <20130203213808.GD28385@jeeves.rigozsaurus.com> Message-ID: On Sun, Feb 3, 2013 at 4:38 PM, John Osmon wrote: > Scott -- you've brought up *great* info for this thread. We all know > that city/county/state/federal governments sometimes throw money away on > boondoggles (as fiber could become). You've been able to pull from your > direct experience to show how this is true. > > > I threw in Idaho Falls because I'm betting it will help someone doing > research in the future. Can you throw out some of the positive > examples you've run across? > > Jason, the best cases I've seen were all those scenarios where if the muni didn't build the access it simply wouldn't happen. I've seen lots of different kinds of technologies used ranging from wireless (not 802.11), to DOCSIS cable (this is actually the most common in the US), and fiber. I can't share my customer's names unfortunately, but the successful ones all shared several things in common: 1) They had specific goals and built the network to reach those goals. In all the "good" situations the networks at least pay for themselves and in some places make a small profit. 2) They have personnel dedicated to their broadband offering that are motivated to make it succeed and the city listens to the technical and operational recommendations of that staff. 3) They focus on a relatively small number of products, generally either just L3 services or L3 services and broadcast video (especially for DOCSIS systems). 4) They get their pricing "right". This last point is perhaps the most important but hardest to do well. -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Sun Feb 3 21:58:49 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 3 Feb 2013 16:58:49 -0500 (EST) Subject: Rollup: Small City Municipal Broadband In-Reply-To: Message-ID: <20006603.4810.1359928729419.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > > And flooding doesn't affect pure glass, does it? > > Not directly, so long as the cladding stays intact. The problem with > flooding (for your scenario since your electronics will be centralized) is > mainly that it causes things to move around inside the cable runs and > depending on water flow you can end up with a lot of problems with > increased scattering if the cable gets stretched. Yeah. The cable has like 2 or 3 more layers, including a strength member, above the cladding, though, right? > > It would appear that opinions vary on this point. You've clearly > > had your hands on some of the gear, so I'm not discounting your opinion > > by any means, but it seems that this may vary based on, among other > > things, how well one engineers the plant up front. This will *not* > > be a lowest-bidder contract. Or I won't do it. > > Its not just the initial install. Its that every time you do anything new > like adding in a new L2 vendor or technology or hook up a new end user. Since I plan to drop and terminal all the tails on the initial install, "hook up a new user" amounts to "plug an optical patch cord into a wall jack". Assuming the termination of the fiber in the wall jack was tested for level and blur at install time, that will hopefully not be too big a deal. > Glass doesn't suffer from ingress noise like RF driven systems but the > plant itself is just as sensitive to physical damage and is more > sensitive to stretching than coax or twisted pair. I thought all that stuff had been mitigated by now to make aerial plant practical; no? > > As Owen notes, their hot-potatoing it will simply cost them more money, > > so they have incentive to be cooperative in finding these problems, and > > that helps almost an order of magnitude. > > Respectfully the guys that will be doing the hot potato shuffle won't > be the owners or even people who have that much technical understanding. Well, in my particular instance, I don't actually think that will be true; I expect to be dealing with either the guy who cuts my check, or the technical lead who works for him, most of the time. I would be pretty surprised to find that the ISP I have in mind as my first mover has more than 10 employees. > They'll be installers that work on the end user and their skill set is > on par with the guys who do contract installs for security systems and > Dish Network/Direct TV. They don't care if their boss loses money, they > don't care if you lose money, all they want to is keep their install count > up since that's how they get paid. If a given install is problematic and > they can shift the responsibility to someone else they (as a group) will. > I'm not suggesting that everyone who does that kind of work is unskilled > or uncaring but as a group that's what you get. In general, I think that's true. In a city of 11000 people, I am not sure that I think it will actually work out that way in practice. > > No, but I'm pretty sure my Fluke rep will be happy to sell me boxes that > > *will* test for that stuff, and I will have a contractor to back me up. > > No, actually they won't because Fluke doesn't sell a DOCSIS analyzer > (for RFoG) nor a PON analyzer. You'll need a separate meter (for several > thousand dollars) for each kind of technology you want to be able to > troubleshoot. For example, to handle modulated RF (RFoG) you'd use a > JDSU (or Sunrise or Trilithic). Fluke is a very basic OTDR tool and they > don't address the various layer 2 technologies. Well, my snap reaction to this is "what the city's responsibility is for dark fiber pairs is spelled out in the contract, and things past that test regime are the responsibility of the L2 provider", but I gather you don't think that will be good enough. Why is protocol my responsibility? *It's a dark pair of glass fibers*. If it meets level and dispersion specs, how the hell is it still my problem? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Sun Feb 3 22:01:26 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 3 Feb 2013 17:01:26 -0500 (EST) Subject: Rollup: Small City Municipal Broadband In-Reply-To: Message-ID: <3244384.4812.1359928886339.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jason Baugher" > The SP of choice can charge the customer for the demarc extension on > installation, at which point the customer owns the extension just like > they do for DSL, T1, etc... Except that that means you have to let them into your lock box to unplug it. Do they make two-layer demarcs for 3-pr optical, like they do for copper? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From khelms at zcorum.com Sun Feb 3 22:01:53 2013 From: khelms at zcorum.com (Scott Helms) Date: Sun, 3 Feb 2013 17:01:53 -0500 Subject: Is Google Fiber a model for Municipal Networks? In-Reply-To: <20130203215226.GA53926@ussenterprise.ufp.org> References: <20130203215226.GA53926@ussenterprise.ufp.org> Message-ID: On Sun, Feb 3, 2013 at 4:52 PM, Leo Bicknell wrote: > > I've been searching for a few days on information about Google > Fiber's Kansas City deployment. While I wouldn't call Google > secretive in this particular case, they haven't been very outgoing > on some of the technologies. Based on the equipment they have deployed > there is speculation they are doing both GPON and active thernet > (point2point). > > I found this presentation: > > http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/36936.pdf > > Its active ethernet. They looked at PON but ultimately rejected it since it fell below their speed goals (can't do gig connections on any flavor of PON today). Here is the architecture document: http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/36936.pdf > It has a very good summary of the tradeoffs we've been discussing > regarding home run fibers with active ethernet compared with GPON, > including costs of the eletronics compared to trenching, the space > required in the CO, and many of the other issues we've touched on > so far. > > Here's an article with some economics from several different > deployments: > http://fastnetnews.com/fiber-news/175-d/4835-fiber-economics-quick-and-dirty > > Looks like $500-$700 in capex per residence is the current gold > standard. Note that the major factor is the take rate; if there are two > providers doing FTTH they are both going to max at about a 50% take > rate. By having one provider, a 70-80% take rate can be driven. > > Even with us a 4%, 10 year government bond, a muni network could finance > out a $700/prem build for $7.09 per month! Add in some overhead and > there's no reason a muni-network couldn't lease FTTH on a cost recovery > bases to all takers for $10-$12 a month (no Internet or other services > included). > > Anyone know of more info about the Google Fiber deployment? > The biggest factor that Google has going for them is they are their own gear manufacturer, both the in home stuff and the access network. They invited several manufacturers to test but then sent them all packing. They are doing a ring (actually several rings) of Ethernet with nodes that then connect down to the neighborhood level. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Sun Feb 3 22:03:22 2013 From: khelms at zcorum.com (Scott Helms) Date: Sun, 3 Feb 2013 17:03:22 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <20130203214553.E81B02EFDF48@drugs.dv.isc.org> References: <27689057.4704.1359856315730.JavaMail.root@benjamin.baylink.com> <7CEA0614-05A8-48FE-A3DE-D66B9A26BAE5@delong.com> <20130203214553.E81B02EFDF48@drugs.dv.isc.org> Message-ID: Mark, That's true but none (AFAIK) of those connections are being built by muni's and all of the hand offs are done to the ISPs at layer 2. On Sun, Feb 3, 2013 at 4:45 PM, Mark Andrews wrote: > > In message < > CAMrdfRw6B3+sPovj3W0xnVqkxgSe6ZB5hgLiCqX4kGzxpE7ytA at mail.gmail.com> > , Scott Helms writes: > > I answered (I think) your other points in the last email I wrote, but I > > > wanted to address these specifically. > > > > > > I believe that Sweden operates largely on this model and that the > Australia > > > NBN project does as well. > > > > > > I would say that the Swedish model is a definite success. > > > > > > > Australia's NBN is still the planning and arguing phase. > > They may still be arguing, but there are fiber and fixed wireless > customers receiving packets. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Sun Feb 3 22:03:52 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 3 Feb 2013 17:03:52 -0500 (EST) Subject: Is Google Fiber a model for Municipal Networks? In-Reply-To: <20130203215226.GA53926@ussenterprise.ufp.org> Message-ID: <25075047.4814.1359929032564.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Leo Bicknell" > Here's an article with some economics from several different > deployments: > http://fastnetnews.com/fiber-news/175-d/4835-fiber-economics-quick-and-dirty > > Looks like $500-$700 in capex per residence is the current gold > standard. Note that the major factor is the take rate; if there are > two providers doing FTTH they are both going to max at about a 50% take > rate. By having one provider, a 70-80% take rate can be driven. I was seeing 700 to drop, and another 650 to hook up; is that 5-700 supposed to include an ONT? > Even with us a 4%, 10 year government bond, a muni network could finance > out a $700/prem build for $7.09 per month! Add in some overhead and > there's no reason a muni-network couldn't lease FTTH on a cost recovery > bases to all takers for $10-$12 a month (no Internet or other services > included). This is the class of numbers I was hoping to get to, yeah. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From josmon at rigozsaurus.com Sun Feb 3 22:11:45 2013 From: josmon at rigozsaurus.com (John Osmon) Date: Sun, 3 Feb 2013 15:11:45 -0700 Subject: muni L1 example (WAS: Re: Muni fiber: L1 or L2?) In-Reply-To: References: <20130203023507.GB16918@ussenterprise.ufp.org> <20130203033203.GA19119@ussenterprise.ufp.org> <20130203170443.GB44479@ussenterprise.ufp.org> <20130203174407.GA30037@jeeves.rigozsaurus.com> <20130203213808.GD28385@jeeves.rigozsaurus.com> Message-ID: <20130203221145.GE28385@jeeves.rigozsaurus.com> Thanks Scott. Even if you can't name names, having those points stored somewhere searchable is going to help someone build a useful case when deciding to deploy or not. On Sun, Feb 03, 2013 at 04:55:41PM -0500, Scott Helms wrote: > On Sun, Feb 3, 2013 at 4:38 PM, John Osmon <[1]josmon at rigozsaurus.com> > wrote: > > Scott -- you've brought up *great* info for this thread. We all know > that city/county/state/federal governments sometimes throw money away on > boondoggles (as fiber could become). You've been able to pull from your > direct experience to show how this is true. > > I threw in Idaho Falls because I'm betting it will help someone doing > research in the future. Can you throw out some of the positive > examples you've run across? > > Jason^h^h^h^hohn, the best cases I've seen were all those scenarios where if the muni > didn't build the access it simply wouldn't happen. I've seen lots of > different kinds of technologies used ranging from wireless (not 802.11), > to DOCSIS cable (this is actually the most common in the US), and fiber. > I can't share my customer's names unfortunately, but the successful ones > all shared several things in common: > 1) They had specific goals and built the network to reach those goals. > In all the "good" situations the networks at least pay for themselves and > in some places make a small profit. > 2) They have personnel dedicated to their broadband offering that are > motivated to make it succeed and the city listens to the technical and > operational recommendations of that staff. > 3) They focus on a relatively small number of products, generally either > just L3 services or L3 services and broadcast video (especially for DOCSIS > systems). > 4) They get their pricing "right". This last point is perhaps the most > important but hardest to do well. > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > [2]http://twitter.com/kscotthelms > -------------------------------- > > References > > Visible links > 1. mailto:josmon at rigozsaurus.com > 2. http://twitter.com/kscotthelms From khelms at zcorum.com Sun Feb 3 22:14:54 2013 From: khelms at zcorum.com (Scott Helms) Date: Sun, 3 Feb 2013 17:14:54 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <20006603.4810.1359928729419.JavaMail.root@benjamin.baylink.com> References: <20006603.4810.1359928729419.JavaMail.root@benjamin.baylink.com> Message-ID: On Sun, Feb 3, 2013 at 4:58 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Scott Helms" > > > > And flooding doesn't affect pure glass, does it? > > > > Not directly, so long as the cladding stays intact. The problem with > > flooding (for your scenario since your electronics will be centralized) > is > > mainly that it causes things to move around inside the cable runs and > > depending on water flow you can end up with a lot of problems with > > increased scattering if the cable gets stretched. > > Yeah. The cable has like 2 or 3 more layers, including a strength > member, above the cladding, though, right? > Yep, but glass is much (an order of magnitude) more sensitive to stretching than coax or twisted pair (electrons don't mind, but light diffracts). That's not to say that aerial isn't doable it is, but you're going to be doing maintenance on your plant most years. > > > > It would appear that opinions vary on this point. You've clearly > > > had your hands on some of the gear, so I'm not discounting your opinion > > > by any means, but it seems that this may vary based on, among other > > > things, how well one engineers the plant up front. This will *not* > > > be a lowest-bidder contract. Or I won't do it. > > > > Its not just the initial install. Its that every time you do anything new > > like adding in a new L2 vendor or technology or hook up a new end user. > > Since I plan to drop and terminal all the tails on the initial install, > "hook up a new user" amounts to "plug an optical patch cord into a wall > jack". > > Assuming the termination of the fiber in the wall jack was tested for > level and blur at install time, that will hopefully not be too big > a deal. > How is it tested? Just looking at it with an OTDR meter doesn't mean it will work with RFoG or PON. > > > > > As Owen notes, their hot-potatoing it will simply cost them more money, > > > so they have incentive to be cooperative in finding these problems, and > > > that helps almost an order of magnitude. > > > > Respectfully the guys that will be doing the hot potato shuffle won't > > be the owners or even people who have that much technical understanding. > > Well, in my particular instance, I don't actually think that will be true; > I expect to be dealing with either the guy who cuts my check, or the > technical lead who works for him, most of the time. > > I would be pretty surprised to find that the ISP I have in mind as my > first mover has more than 10 employees. > Sure, but are those 10 guys the only ones who do end user installs? If so then you will hopefully have fewer problems, but that depends on how good those 10 people are and the kinds of technologies you're working on. > > > They'll be installers that work on the end user and their skill set is > > on par with the guys who do contract installs for security systems and > > Dish Network/Direct TV. They don't care if their boss loses money, they > > don't care if you lose money, all they want to is keep their install > count > > up since that's how they get paid. If a given install is problematic and > > they can shift the responsibility to someone else they (as a group) will. > > I'm not suggesting that everyone who does that kind of work is unskilled > > or uncaring but as a group that's what you get. > > In general, I think that's true. In a city of 11000 people, I am not > sure that I think it will actually work out that way in practice. > I'd disagree, that's definitely of the scale where you'll have 4-5 people who do this kind of contract installs on a regular basis. Now, your ISP may choose to not use one of them, but they're certainly out there. > > > > No, but I'm pretty sure my Fluke rep will be happy to sell me boxes > that > > > *will* test for that stuff, and I will have a contractor to back me up. > > > > No, actually they won't because Fluke doesn't sell a DOCSIS analyzer > > (for RFoG) nor a PON analyzer. You'll need a separate meter (for several > > thousand dollars) for each kind of technology you want to be able to > > troubleshoot. For example, to handle modulated RF (RFoG) you'd use a > > JDSU (or Sunrise or Trilithic). Fluke is a very basic OTDR tool and they > > don't address the various layer 2 technologies. > > Well, my snap reaction to this is "what the city's responsibility is > for dark fiber pairs is spelled out in the contract, and things past > that test regime are the responsibility of the L2 provider", but I > gather you don't think that will be good enough. > > Why is protocol my responsibility? > > *It's a dark pair of glass fibers*. If it meets level and dispersion > specs, how the hell is it still my problem? > That's what I've been trying to tell you. You're basing your idea of troubleshooting on AM or FM modulation when all of the broadband connectivity is PM (phase modulation). That means your light power meter from Fluke can tell you everything is good when a specific connection is in fact unusable. http://en.wikipedia.org/wiki/Phase_modulation Take a look at the write up a friend of mine did on a QAM analyzer. This one is specifically for cable systems, but the concept of phase constellations works the same in any PM set up. http://volpefirm.com/tech-review-devisor-s7000-tv-analyzer/ This PDF (search for constellation) describes how phase modulation is used in EPON: http://www.broadcom.com/docs/features/DOCSIS_EoC_EPONinChina.pdf > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jason at thebaughers.com Sun Feb 3 22:22:18 2013 From: jason at thebaughers.com (Jason Baugher) Date: Sun, 3 Feb 2013 16:22:18 -0600 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <3244384.4812.1359928886339.JavaMail.root@benjamin.baylink.com> References: <3244384.4812.1359928886339.JavaMail.root@benjamin.baylink.com> Message-ID: I'm pretty sure they do, although I can't point you to one without doing some checking. I'm assuming you want something to keep them out of the network side where the splice tray is, but let them access the customer side? Around here, the network side isn't so much locked as just secured with a screw that takes a security wrench. On Sun, Feb 3, 2013 at 4:01 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Jason Baugher" > > > The SP of choice can charge the customer for the demarc extension on > > installation, at which point the customer owns the extension just like > > they do for DSL, T1, etc... > > Except that that means you have to let them into your lock box to unplug > it. > Do they make two-layer demarcs for 3-pr optical, like they do for copper? > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > From owen at delong.com Sun Feb 3 22:24:17 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 3 Feb 2013 14:24:17 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> Message-ID: On Feb 3, 2013, at 12:33 PM, Scott Helms wrote: > > > > On Sun, Feb 3, 2013 at 2:53 PM, Owen DeLong wrote: > > On Feb 2, 2013, at 5:06 PM, Scott Helms wrote: > >> Owen, >> I think the confusion I have is that you seem to want to create solutions for problems that have already been solved. There is no cost effective method of sharing a network at layer 1 since DWDM is expensive and requires compatible gear on both sides and no one has enough fiber (nor is cheap enough in brand new builds) to simply home run every home and maintain that. ISPs that would want to use the shared network in general (>95% in my experience) don't want to maintain the access gear and since there is no clear way to delineate responsibilities when there is an issue its hard. >> >> > ?? > > Who said anything about sharing the network at L1? > > You did. No, I didn't. I said build out an L1 infrastructure such that individual connections can be leased from it. Not shared L1 connections. I have never advocated shared L1 connections. > > Is it more expensive to home-run every home than to put splitters in the neighborhood? Yes. Is it enough more expensive that the tradeoffs cannot be overcome? I remain unconvinced. > > > This completely depends on the area and the goals of the network. In most cases for muni networks back hauling everything is more expensive. I agree it's more expensive. The question is whether it's enough more expensive to make it infeasible. You still haven't come anywhere near addressing that question. > > > I'm not sure why you think it would be hard to delineate the responsibilities? You've got a fiber path maintained by the municipality with active equipment maintained by the ISP at each end. If the light coming out of the equipment at one end doesn't come out of the fiber at the other end, you have a problem in the municipality's domain. If the light makes it through in tact, you have a problem in the ISP's domain. > > There is equipment available that can test that fairly easily. > > OK, this one made my wife get scared I laughed so hard. You clearly have never tried to do this or had to work with different operators in the same physical network. Please, go talk to someone whose worked in the field of a FTTx network and describe this scenario to them. Its clear you don't want to hear it from me via email so please go do some research. I've talked to a few people doing exactly that. Yes, you need different test sets depending on which L2 gear is involved, but, in virtually ever case, there is a piece of test gear that can be used to test a loop independent of the configuration of the L2 gear in question. For providers getting L1 service, it wouldn't be too hard to make this testing / providing necessary test equipment part of their contract. >> The long and short of it is lots of people have tried to L1 sharing and its not economical and nothing I've seen here or elsewhere changes that. The thing you have to remember is that muni networks have to be cost effective and that's not just the capital costs. The operational cost in the long term is much greater than the cost of initial gear and fiber install. >> > We can agree to disagree. A muni network needs to be able to recover its costs. The costs of building out and maintaining home-run > fiber are not necessarily that much greater than the costs of building out and maintaining fiber at the neighborhood. One option, for > example, would be to have neighborhood B-Boxes where the fiber can either be fed into provider-specific splitters (same economy > as existing PON deployments) or cross-connected to fiber on the F1 cable going back to the MMR (home-run). > > > We can agree all we want, that doesn't change history. Handing out connections at layer 1 is both more expensive and less efficient. Its also extremely wasteful (which is why its more expensive) since your lowest unit you can sell is a fiber strand whether the end customer wants a 3 mbps connection or a gig its the same to the city. I'm not saying you shouldn't sell dark fiber, I'm saying that in 99% of the cities you can't build a business model around doing just that unless your city doesn't want to break even on the build and maintenance. If it's $700 per home passed to build out home-run fibers (which seems to be a reasonable approximation from earlier discussions), then there's no reason you can't sell $40/month service over that where the L1 component is a $10/month ($7 for capital recovery, $3 for operations and support) pricing component. By my estimates, to become truly impractical, you'd have to get somewhere north of $1500 per home passed. > > > The only additional cost in this system over traditional PON is the larger number of fibers required in the F1 cable. > > > PON networks aren't deployed this way and if you're going to backhaul all of the connections to a central point you wouldn't run PON. PON is worse in every performance related way to PON and the only reasons operators deploy it today is because its less expensive. Its less expensive because you don't have to backhaul all of the connections or have active components at the neighborhood level. Then don't deploy PON. I don't care whether PON gets deployed or not. You keep coming back at this as if PON is somehow the goal. Personally, I'd rather see Gig-E in every home and be done with it. However, the point is that building the infrastructure in that manner doesn't cost much more than building out traditional PON infrastructure (if you're doing it from greenfield) and it can support either technology. Owen From bicknell at ufp.org Sun Feb 3 22:40:14 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 3 Feb 2013 14:40:14 -0800 Subject: Is Google Fiber a model for Municipal Networks? In-Reply-To: <25075047.4814.1359929032564.JavaMail.root@benjamin.baylink.com> References: <20130203215226.GA53926@ussenterprise.ufp.org> <25075047.4814.1359929032564.JavaMail.root@benjamin.baylink.com> Message-ID: <20130203224014.GA55641@ussenterprise.ufp.org> In a message written on Sun, Feb 03, 2013 at 05:03:52PM -0500, Jay Ashworth wrote: > > From: "Leo Bicknell" > > Looks like $500-$700 in capex per residence is the current gold > > standard. Note that the major factor is the take rate; if there are > > two providers doing FTTH they are both going to max at about a 50% take > > rate. By having one provider, a 70-80% take rate can be driven. > > I was seeing 700 to drop, and another 650 to hook up; is that 5-700 supposed > to include an ONT? I believe the $500-$700 would include an ONT, if required, but nothing beyond that. "Hook up" would include installing a home gateway, testing, setting up WiFi, installing TV boxes, etc. So in the model I advocate, the muni-network would have $500-$700/home to get fiber into the prem, and the L3-L7 service provider would truck roll a guy and supply the equipment that comprise another $500-$700 to turn up the customer. In Google Fiber's model they are both, so it's probably $1000-$1400 a home inclusive. $1400 @4% for 10 years is $14.17 a month per house passed. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From khelms at zcorum.com Sun Feb 3 22:57:38 2013 From: khelms at zcorum.com (Scott Helms) Date: Sun, 3 Feb 2013 17:57:38 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> Message-ID: On Sun, Feb 3, 2013 at 5:24 PM, Owen DeLong wrote: > > On Feb 3, 2013, at 12:33 PM, Scott Helms wrote: > > > > > On Sun, Feb 3, 2013 at 2:53 PM, Owen DeLong wrote: > >> >> On Feb 2, 2013, at 5:06 PM, Scott Helms wrote: >> >> Owen, >> I think the confusion I have is that you seem to want to create solutions >> for problems that have already been solved. There is no cost effective >> method of sharing a network at layer 1 since DWDM is expensive and requires >> compatible gear on both sides and no one has enough fiber (nor is cheap >> enough in brand new builds) to simply home run every home and maintain >> that. ISPs that would want to use the shared network in general (>95% in >> my experience) don't want to maintain the access gear and since there is no >> clear way to delineate responsibilities when there is an issue its hard. >> >> ?? >> >> Who said anything about sharing the network at L1? >> > > You did. > > > No, I didn't. I said build out an L1 infrastructure such that individual > connections can be leased from it. Not shared L1 connections. > I have never advocated shared L1 connections. > Sharing the entire network at layer 1 is what I and I believe you were talking about. Not sharing individual fiber connections, but using the same fiber plant for multiple layer 2 technologies. This is what you're suggesting, correct? > > >> Is it more expensive to home-run every home than to put splitters in the >> neighborhood? Yes. Is it enough more expensive that the tradeoffs cannot be >> overcome? I remain unconvinced. >> > > > This completely depends on the area and the goals of the network. In most > cases for muni networks back hauling everything is more expensive. > > > I agree it's more expensive. The question is whether it's enough more > expensive to make it infeasible. You still haven't come anywhere near > addressing that question. > I've said repeatedly that this a network by network analysis. I've never said its infeasible, but that it is more expensive both initially and long term in MOST installs. That by itself is generally enough to invalidate the design since in almost all cases there's no benefit to home running all the connections. It doesn't make the connection faster nor do ISPs (as a group) care about a layer 1 versus layer 2 hand off. > > > >> >> I'm not sure why you think it would be hard to delineate the >> responsibilities? You've got a fiber path maintained by the municipality >> with active equipment maintained by the ISP at each end. If the light >> coming out of the equipment at one end doesn't come out of the fiber at the >> other end, you have a problem in the municipality's domain. If the light >> makes it through in tact, you have a problem in the ISP's domain. >> >> There is equipment available that can test that fairly easily. >> > > OK, this one made my wife get scared I laughed so hard. You clearly have > never tried to do this or had to work with different operators in the same > physical network. Please, go talk to someone whose worked in the field of > a FTTx network and describe this scenario to them. Its clear you don't > want to hear it from me via email so please go do some research. > > > > I've talked to a few people doing exactly that. Yes, you need different > test sets depending on which L2 gear is involved, but, in virtually ever > case, there is a piece of test gear that can be used to test a loop > independent of the configuration of the L2 gear in question. > Yes, there is a meter for all the different kinds of technologies that you might want to support. For example a DOCSIS 3.0 DSAM from JDSU will run you around $8000.00 A PON meter with long range lasers (more than 10 miles) from JDSU or Trilithic will cost you nearly $10,000. Exactly how many of those kinds of meters do you want to have to buy? How many of your staff are you going to train on them (they do require training and knowledge to use)? > > For providers getting L1 service, it wouldn't be too hard to make this > testing / providing necessary test equipment part of their contract. > > The long and short of it is lots of people have tried to L1 sharing and >> its not economical and nothing I've seen here or elsewhere changes that. >> The thing you have to remember is that muni networks have to be cost >> effective and that's not just the capital costs. The operational cost in >> the long term is much greater than the cost of initial gear and fiber >> install. >> >> We can agree to disagree. A muni network needs to be able to recover its >> costs. The costs of building out and maintaining home-run >> fiber are not necessarily that much greater than the costs of building >> out and maintaining fiber at the neighborhood. One option, for >> example, would be to have neighborhood B-Boxes where the fiber can either >> be fed into provider-specific splitters (same economy >> as existing PON deployments) or cross-connected to fiber on the F1 cable >> going back to the MMR (home-run). >> >> > We can agree all we want, that doesn't change history. Handing out > connections at layer 1 is both more expensive and less efficient. Its also > extremely wasteful (which is why its more expensive) since your lowest unit > you can sell is a fiber strand whether the end customer wants a 3 mbps > connection or a gig its the same to the city. I'm not saying you shouldn't > sell dark fiber, I'm saying that in 99% of the cities you can't build a > business model around doing just that unless your city doesn't want to > break even on the build and maintenance. > > > If it's $700 per home passed to build out home-run fibers (which seems to > be a reasonable approximation from earlier discussions), then there's no > reason you can't sell $40/month service over that where the L1 component is > a $10/month ($7 for capital recovery, $3 for operations and support) > pricing component. > Nope, no reason at all if you don't care about covering your costs. > > By my estimates, to become truly impractical, you'd have to get somewhere > north of $1500 per home passed. > > > > > >> The only additional cost in this system over traditional PON is the >> larger number of fibers required in the F1 cable. >> >> > PON networks aren't deployed this way and if you're going to backhaul all > of the connections to a central point you wouldn't run PON. PON is worse > in every performance related way to PON and the only reasons operators > deploy it today is because its less expensive. Its less expensive because > you don't have to backhaul all of the connections or have active components > at the neighborhood level. > > > Then don't deploy PON. I don't care whether PON gets deployed or not. You > keep coming back at this as if PON is somehow the goal. Personally, I'd > rather see Gig-E in every home and be done with it. > > However, the point is that building the infrastructure in that manner > doesn't cost much more than building out traditional PON infrastructure (if > you're doing it from greenfield) and it can support either technology. > Sure it does, even in greenfield and whats more it costs more over the long term UNLESS you know where every home and business will be located 10 years from now. > > Owen > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Sun Feb 3 22:58:09 2013 From: khelms at zcorum.com (Scott Helms) Date: Sun, 3 Feb 2013 17:58:09 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <510EE992.3050601@nic-naa.net> References: <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510EE992.3050601@nic-naa.net> Message-ID: Eric, Lol, yeah should have been Gig-E :) On Sun, Feb 3, 2013 at 5:49 PM, Eric Brunner-Williams wrote: > On 2/3/13 12:33 PM, Scott Helms wrote: > > PON is worse > > in every performance related way to PON > > typo??? > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From fkittred at gwi.net Mon Feb 4 00:17:57 2013 From: fkittred at gwi.net (Fletcher Kittredge) Date: Sun, 3 Feb 2013 19:17:57 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <001a01ce00ce$6d230e40$47692ac0$@iname.com> References: <20130129170500.GA38295@ussenterprise.ufp.org> <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <59C8B6BD-5759-4FEF-A7C8-2D3D93B97D73@delong.com> <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <001a01ce00ce$6d230e40$47692ac0$@iname.com> Message-ID: On Fri, Feb 1, 2013 at 5:49 PM, Frank Bulk (iname.com) wrote: > Fletcher: > > Many rural LECs are homerunning their fiber back to the CO, such that the > optical splitters are only in the CO. It gives them one management point, > the highest possible efficiency (you can maximize any every splitter and > therefore PON) and a pathway to ActiveE. > Frank; That is the architecture I am familar with. I would like to get a sense of how wide-spread its adoption is. regards, Fletcher -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From fkittred at gwi.net Mon Feb 4 02:29:08 2013 From: fkittred at gwi.net (Fletcher Kittredge) Date: Sun, 3 Feb 2013 21:29:08 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: References: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> <510DF096.60907@vaxination.ca> <20130203165850.GA44479@ussenterprise.ufp.org> Message-ID: In this particular post, your making stuff up. There are still "residential focused" CLECs and ordering Unbundled Network Elements(UNEs) is not more difficult than in the past. The rules haven't changed. What is certainly true is that many CLECs have found that it is more lucrative to sell to businesses, but I don't think there is a correlation with residential getting more difficult. We used to be 75%/25% residential/business and are now 45%/55% business, but that reflects the *rapid* growth of the business market. regards, Fletcher On Sun, Feb 3, 2013 at 3:42 PM, Scott Helms wrote: > Joe, > > I'm assuming from your domain that you're in Canada where yes dry pairs are > still generally available. I apologize for not making it clear that my > comment was specifically about the US where dry pairs are nearly impossible > to order today and the CLEC market has almost entirely abandoned the > residential space. In fact, the only state in the US that I still see any > residentially focused CLECs is Texas which tells me there is something > about the regulations in that state that makes it more feasible. > > > On Sun, Feb 3, 2013 at 3:32 PM, Joe Abley wrote: > > > > > On 2013-02-03, at 14:39, Scott Helms wrote: > > > > > Dry pairs are impossible to order these days for a reason. > > > > Dry pairs are trivial to order round these parts. Generalisations are > > always wrong, no doubt including this one. > > > > > > Joe (putting the N back in NANOG) > > > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From khelms at zcorum.com Mon Feb 4 02:53:52 2013 From: khelms at zcorum.com (Scott Helms) Date: Sun, 3 Feb 2013 21:53:52 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: References: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> <510DF096.60907@vaxination.ca> <20130203165850.GA44479@ussenterprise.ufp.org> Message-ID: Fletcher, Your specific case may vary, but I am most certainly _not_ "making stuff up". In many territories, especially outside of major metro areas, you cannot order dry pairs. This has been because of a combination of relaxed rules (if you really want I can dig up the NTCA reports on this) and because the rules never required the ILEC to add capacity once they were used up. On Sun, Feb 3, 2013 at 9:29 PM, Fletcher Kittredge wrote: > > In this particular post, your making stuff up. There are still > "residential focused" CLECs and ordering Unbundled Network Elements(UNEs) > is not more difficult than in the past. The rules haven't changed. > > What is certainly true is that many CLECs have found that it is more > lucrative to sell to businesses, but I don't think there is a correlation > with residential getting more difficult. We used to be 75%/25% > residential/business and are now 45%/55% business, but that reflects the > *rapid* growth of the business market. > > regards, > Fletcher > > On Sun, Feb 3, 2013 at 3:42 PM, Scott Helms wrote: > >> Joe, >> >> I'm assuming from your domain that you're in Canada where yes dry pairs >> are >> still generally available. I apologize for not making it clear that my >> comment was specifically about the US where dry pairs are nearly >> impossible >> to order today and the CLEC market has almost entirely abandoned the >> residential space. In fact, the only state in the US that I still see any >> residentially focused CLECs is Texas which tells me there is something >> about the regulations in that state that makes it more feasible. >> >> >> On Sun, Feb 3, 2013 at 3:32 PM, Joe Abley wrote: >> >> > >> > On 2013-02-03, at 14:39, Scott Helms wrote: >> > >> > > Dry pairs are impossible to order these days for a reason. >> > >> > Dry pairs are trivial to order round these parts. Generalisations are >> > always wrong, no doubt including this one. >> > >> > >> > Joe (putting the N back in NANOG) >> >> >> >> >> -- >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> > > > > -- > Fletcher Kittredge > GWI > 8 Pomerleau Street > Biddeford, ME 04005-9457 > 207-602-1134 -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jason at thebaughers.com Mon Feb 4 03:06:50 2013 From: jason at thebaughers.com (Jason Baugher) Date: Sun, 3 Feb 2013 21:06:50 -0600 Subject: Rollup: Small City Municipal Broadband In-Reply-To: References: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> <510DF096.60907@vaxination.ca> <20130203165850.GA44479@ussenterprise.ufp.org> Message-ID: What we've seen is that the RBOC typically has a lot of crap copper in the ground, in a lot of cases air-core (pre gel-fill) that hasn't held up well. With the popularity of DSL, they ran out of good pairs to use. As they ran out of pairs, they eventually had to put in remote terminals to handle any new voice orders. They knew the future was fiber, at least to the node, so they had no incentive to build new copper plant, and little incentive to maintain the existing plant. On Sun, Feb 3, 2013 at 8:53 PM, Scott Helms wrote: > Fletcher, > > Your specific case may vary, but I am most certainly _not_ "making stuff > up". In many territories, especially outside of major metro areas, you > cannot order dry pairs. This has been because of a combination of relaxed > rules (if you really want I can dig up the NTCA reports on this) and > because the rules never required the ILEC to add capacity once they were > used up. > > > On Sun, Feb 3, 2013 at 9:29 PM, Fletcher Kittredge > wrote: > > > > > In this particular post, your making stuff up. There are still > > "residential focused" CLECs and ordering Unbundled Network Elements(UNEs) > > is not more difficult than in the past. The rules haven't changed. > > > > What is certainly true is that many CLECs have found that it is more > > lucrative to sell to businesses, but I don't think there is a correlation > > with residential getting more difficult. We used to be 75%/25% > > residential/business and are now 45%/55% business, but that reflects the > > *rapid* growth of the business market. > > > > regards, > > Fletcher > > > > On Sun, Feb 3, 2013 at 3:42 PM, Scott Helms wrote: > > > >> Joe, > >> > >> I'm assuming from your domain that you're in Canada where yes dry pairs > >> are > >> still generally available. I apologize for not making it clear that my > >> comment was specifically about the US where dry pairs are nearly > >> impossible > >> to order today and the CLEC market has almost entirely abandoned the > >> residential space. In fact, the only state in the US that I still see > any > >> residentially focused CLECs is Texas which tells me there is something > >> about the regulations in that state that makes it more feasible. > >> > >> > >> On Sun, Feb 3, 2013 at 3:32 PM, Joe Abley wrote: > >> > >> > > >> > On 2013-02-03, at 14:39, Scott Helms wrote: > >> > > >> > > Dry pairs are impossible to order these days for a reason. > >> > > >> > Dry pairs are trivial to order round these parts. Generalisations are > >> > always wrong, no doubt including this one. > >> > > >> > > >> > Joe (putting the N back in NANOG) > >> > >> > >> > >> > >> -- > >> Scott Helms > >> Vice President of Technology > >> ZCorum > >> (678) 507-5000 > >> -------------------------------- > >> http://twitter.com/kscotthelms > >> -------------------------------- > >> > > > > > > > > -- > > Fletcher Kittredge > > GWI > > 8 Pomerleau Street > > Biddeford, ME 04005-9457 > > 207-602-1134 > > > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > From frnkblk at iname.com Mon Feb 4 03:53:50 2013 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 3 Feb 2013 21:53:50 -0600 Subject: Is Google Fiber a model for Municipal Networks? In-Reply-To: <20130203224014.GA55641@ussenterprise.ufp.org> References: <20130203215226.GA53926@ussenterprise.ufp.org> <25075047.4814.1359929032564.JavaMail.root@benjamin.baylink.com> <20130203224014.GA55641@ussenterprise.ufp.org> Message-ID: <002901ce028b$3e002670$ba007350$@iname.com> Sure, Verizon has been able to get their cost per home passed down to $700 (http://www.isuppli.com/Home-and-Consumer-Electronics/MarketWatch/Pages/Veri zons-FTTH-Expansion-Stoppage-Takes-Many-by-Surprise.aspx), but that does not include the drop, ONT, nor any home wiring to get from the ONT to the CPE within the home. That's still another $650 or so (slide 11 of http://www.natoa.org/events/NATOAPresentationCalix.pdf and http://www.nytimes.com/2008/08/19/technology/19fios.html?pagewanted=all&_r=0 ). That's down from $1,021 in 2005 and $850 at the end of 2006 (http://connectedplanetonline.com/home/news/verizon_touts_fios_092706/). While my $DAYJOB's access vendor has a range of outdoor ONTs with different features, they generally cost from $400 to $700 apiece (plus ONT housing, power supply, battery, and power cable). If we assume Verizon, because of their purchasing power, can negotiate a fantastic discount, their average ONT cost probably still exceeds $200 apiece. Google is not concerned with traditional POTS in their offering, so they don't have to worry about backup power requirements (and costs), plus they're doing ActiveE, not GPON, so despite their low volume, Google probably has ONT costs somewhat similar or less than Verizon. Real-world FTTH complete overbuilds among RLECs (rural incumbent LECs) are typically between $2,000 and $5,000 per home served (that includes the ONT and customer turn-up). Slide 13 of http://www.natoa.org/events/NATOAPresentationCalix.pdf shows an average of $2,377 per home passed (100% take rate). You can see on Slide 14 how the lower households per square mile leads to substantially greater costs. Looking again at the Verizon FiOS build, where there may be a complete overbuild but not every copper customer is converted to FiOS, the cost per home passed does not equal cost per home served. Note this BusinessWeek quote regarding FiOS, "He estimates the project will end up having cost Verizon $4,000 per connected home." (http://www.businessweek.com/magazine/content/11_13/b4221046109606.htm) And for Verizon's cost per home passed: "Consider the total project cost of Verizon's FiOS, $23B, and then divide that not by the 17M homes passed (as I did), but with the actual subscribers (5,1M), This would result in a cost per subscriber of $23B/5.1M = $4,500." (http://seekingalpha.com/article/778871-challenges-and-opportunities-for-goo gle-s-fiber-project-a-reality-and-sanity-check). From the same Seeking Alpha article, FiOS' cumulative historical cost per home passed is $1,352. Remember that Google cherry-picked which city it would serve, so it was able to identify location that is likely less challenging and expensive to serve than the average. A lot of Google's Kansas City build will not be buried but hung on power poles, and they're starting their builds in areas of the city where there was a significant level of customer interest. All of that is going to translate into a lower cost per customer served than a service provider who decides to overbuild an entire locale, regardless of customer interest. So while Google may be able to pull off a $1,400 expenditure per home passed, Jay can't use that price point in his own calculation unless he's in similar construction environment and takes Google's selective deployment approach. Frank -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Sunday, February 03, 2013 4:40 PM To: NANOG Subject: Re: Is Google Fiber a model for Municipal Networks? In a message written on Sun, Feb 03, 2013 at 05:03:52PM -0500, Jay Ashworth wrote: > > From: "Leo Bicknell" > > Looks like $500-$700 in capex per residence is the current gold > > standard. Note that the major factor is the take rate; if there are > > two providers doing FTTH they are both going to max at about a 50% take > > rate. By having one provider, a 70-80% take rate can be driven. > > I was seeing 700 to drop, and another 650 to hook up; is that 5-700 supposed > to include an ONT? I believe the $500-$700 would include an ONT, if required, but nothing beyond that. "Hook up" would include installing a home gateway, testing, setting up WiFi, installing TV boxes, etc. So in the model I advocate, the muni-network would have $500-$700/home to get fiber into the prem, and the L3-L7 service provider would truck roll a guy and supply the equipment that comprise another $500-$700 to turn up the customer. In Google Fiber's model they are both, so it's probably $1000-$1400 a home inclusive. $1400 @4% for 10 years is $14.17 a month per house passed. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From frnkblk at iname.com Mon Feb 4 04:25:18 2013 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 3 Feb 2013 22:25:18 -0600 Subject: Rollup: Small City Municipal Broadband In-Reply-To: References: <9941705.4764.1359923608048.JavaMail.root@benjamin.baylink.com> Message-ID: <004001ce028f$a384c790$ea8e56b0$@iname.com> Scott: While we less than ten thousand FTTH subs, our OSP operational costs are much less with fiber than copper. Our maintenance costs, in order of greatest to least, have been locating, cable moves (i.e. bridge project), monitoring digs, and damage to fiber (rodents and vehicles that hit peds). We have had many more ONT issues than fiber issues, and most fiber issues can be resolved by cleaning both sides of the fiber (customer and head end). And we've had to replace the 50' patch cable between the OLTG and optical splitter a two of three times. While finger-pointing is always a risk when multiple players are involved in delivering any service, I don't perceive that as being as much of a problem as you think it will be. With the right fiber testing gear, any suspected problems can pretty quickly be identified. Frank -----Original Message----- From: Scott Helms [mailto:khelms at zcorum.com] Sent: Sunday, February 03, 2013 2:55 PM To: Jay Ashworth Cc: NANOG Subject: Re: Rollup: Small City Municipal Broadband On Sun, Feb 3, 2013 at 3:33 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Scott Helms" > > > > Basically when the customer (typically the service provider, but > > > not always) orders a loop to a customer the muni provider would > > > OTDR shoot it from the handoff point to the service provider to the > > > prem. They would be responsible for insuring a reasonable > > > performance of the fiber between those two end points. > > > > Been tried multiple times and I've never seen it work in the US, Canada, > > Europe, or Latin America. That's not to say it can't work, but there > > lots of reasons why it doesn't and I don't think anyone has suggested > > anything here that I haven't already seen fail. > > So let me be clear, here, because I'm semi-married to this idea... > > You're asserting that it is not practical to offer L1 optical per-sub > handoffs to L2/3 ISPs, because > I'm saying you can't build a working business model off of layer 1 connections as your primary offering in almost all cases for a muni network. I am hedging my bet here because I don't know your city's topology, density, growth, goals or a hundred other factors that might make you the 1 exception to the rule. > > a) the circuits can't be built reliably, > b) the circuits won't run reliably over the long run, > c) if something *does break*, it's hard or expensive to determine where, or > d) each side will say it's the other side's fault, and things won't get > fixed? > > Let me see if I can explain it, since clearly I'm not getting my thoughts down in my emails well enough. a) You WILL have physical layer issues. Some of these issues will be related to the initial construction of the fiber. b) Other problems will because of changes that occur over time. These could be weather related (especially for aerial cable), but also vehicle hits to fiber cabinets, and occasionally fires. Depending on your location earthquakes, flooding, and other extreme "weather" may also be a factor. c) No, WHEN something breaks it is hard and expensive to figure out where. This is true even if you're the layer 2 provider but it gets you out of the problem of it works $A_provider_gear but not $B_provider_gear. You're going to drive yourself nuts troubleshooting connections IF you do sign up several partners especially if they choose different technologies. d) No, it will always be your fault until you can prove its not. If you don't know how to troubleshoot the technology your L2 partners are using how can you ever do anything but accept their word that they have everything set up correctly? > I can't see any difference between building it for their L2 access box and > my own. I simply don't believe (b). (c) seems questionable as well, so > I assume you have to mean (d). > There are lots of differences, especially related to troubleshooting. Remember, all of these devices are doing phase modulation (QAM, QPSK, etc) so a simple OTDR test (which is similar to checking SNR on a RF system) doesn't show many of the problems that prevent data connectivity on high speed connections. > > > Dry pairs are impossible to order these days for a reason. > > Certainly: because you have to get them from incumbents, who don't want > you to use a cheap service to provide yourself something they could > charge you a lot more money for. > > You assert a technical reason? > Most of this is because the ILECs have gotten the regulations changed but they successfully used some legitimate technical reasons (and other less legitimate arguments) to get those rules changed. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From frnkblk at iname.com Mon Feb 4 04:43:25 2013 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 3 Feb 2013 22:43:25 -0600 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: References: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> <020901ce01d3$0da88c00$28f9a400$@iname.com> Message-ID: <004301ce0292$2b85c1b0$82914510$@iname.com> Brandon: My apologies, I didn't mean to suggest that providers would be unable to provide video services across the muni fiber infrastructure. I was just pointing out that many customers want a triple play, so that should be a factor that Jay considers when considering a GPON-only or ActiveE design, as an RF-overlay on a GPON network is likely more profitable than an IP TV service on top of GPON or ActiveE. And Jay wants to attract multiple providers, so he wants a fiber design that's as attractive to as many parties as reasonably possible. Frank -----Original Message----- From: Brandon Ross [mailto:bross at pobox.com] Sent: Sunday, February 03, 2013 9:56 AM To: Frank Bulk Cc: NANOG; Jay Ashworth Subject: RE: Will wholesale-only muni actually bring the boys to your yard? On Sat, 2 Feb 2013, Frank Bulk wrote: > Yes, but IP TV is not profitable on stand-alone basis -- it's just a > necessary part of the triple play. A lot of the discussion has been about > Internet and network design, but not much about the other two "plays". I don't know if that's true or not, but so what? The concern was that providers would be unable to provide television services across this muni fiber infrastructure and that customers would demand triple play. I showed that they absolutely can provide this service by doing it across IP. If a provider can't make money at it, then they don't have to provide it. This whole exercise, I thought, was about removing the tyranny of the monopoly of the last mine so that these other innovations could take place in an open market. And as far as the "other" triple play, it's even more well established that delivery of voice over IP can be done economically. Or do you need me to send you URLs of companies that do it to prove it? > -----Original Message----- > From: Brandon Ross [mailto:bross at pobox.com] > Sent: Saturday, February 02, 2013 3:53 PM > To: Jay Ashworth > Cc: NANOG > Subject: Re: Will wholesale-only muni actually bring the boys to your yard? > > On Sat, 2 Feb 2013, Jay Ashworth wrote: > >>> Perhaps I live in a different world, but just about all of the small to >>> midsize service providers I work with offer triple play today, and nearly >>> all of them are migrating their triple play services to IP. >> >> Really. Citations? I'd love to see it play that way, myself. > > Okay: > > South Central Rural Telephone > Glasgow, KY > http://www.scrtc.com/ > Left side of page, "Digital TV service". See this news article: > > http://www.wcluradio.com/index.php?option=com_content&view=article&id=15567: > capacity-crowd-hears-good-report-at-scrtc-annuan-mee > > "He also reported that SCRTC is continuing to upgrade our services, > converting customers to the new IPTV service and trying to get as much > fiber optic cable built as possible." > > Camellia Communications > Greenville, AL > http://camelliacom.com/services/ctv-dvr.html > Note the models of set-top boxes they are using are IP based > > Griswold Cooperative Telephone > Griswold, IA > http://www.griswoldtelco.com/griswold-coop-iptv-video > > Farmer's Mutual Coopeative Telephone > Moulton, IA > http://farmersmutualcoop.com/ > > Citizens > Floyd, VA > http://www.citizens.coop/ > > > How about a Canadian example you say? > > CoopTel > Valcourt, QB > http://www.cooptel.qc.ca/en-residentiel-tele-guidesusager.php > Check out the models of set-top boxes here too. > > Oh, also, have you heard of ATT U-Verse? > > http://www.att.com/gen/press-room?pid=4800&cdvn=news&newsarticleid=26580 > > "AT&T U-verse TV is the only 100 percent Internet Protocol-based > television (IPTV) service offered by a national service provider" > > So even the likes of AT&T, in this scheme, could buy fiber paths to their > subs and provide TV service. I'm pretty sure AT&T knows how to deliver > voice services over IP as well. > > Do you want more examples? I bet I can come up with 50 small/regional > telecom companies that are providing TV services over IP in North America > if I put my mind to it. > > -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From jfmezei_nanog at vaxination.ca Mon Feb 4 04:56:15 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sun, 03 Feb 2013 23:56:15 -0500 Subject: Is Google Fiber a model for Municipal Networks? In-Reply-To: <002901ce028b$3e002670$ba007350$@iname.com> References: <20130203215226.GA53926@ussenterprise.ufp.org> <25075047.4814.1359929032564.JavaMail.root@benjamin.baylink.com> <20130203224014.GA55641@ussenterprise.ufp.org> <002901ce028b$3e002670$ba007350$@iname.com> Message-ID: <510F3F6F.102@vaxination.ca> When comparing costs of building (per home passed/connected), it is also important to see if those quoted costs include the regulatory costs of dealing with cities. If a municipal project won't suffer costs of negotiating for diggging/building permits, already has the land to build the "CO", and won't be delayed by stalled paperwork, this could represent a significant difference compared to an incumbent that constant hits a brick wall of bureaucracy which cost money and delays the project. (In Canada, a delay of a couple of months can cause a delay of 1 year due to winter). In the case of Google, with cities begging on their knees to get Google's project, I suspect they didn't have many problems getting the city's cooperation. Yet, there have been stories of delays due to bureaucracy. In the case of Verizon, I suspect those bureaucracy costs are much higher. The other aspect which you need to compare is existing infrastructure. If there are already conduits between CO and neighbourhood, and there is room inside, you can just blow your new fibre through them which costs a lot less than having to dig and install new conduits. (and "space available" is one of the issues that lead telcos to go GPON instead of wanting 1:1 strand to home ratios since that requires much more conduit capacity the closer you get to your point of aggregation. So when comparing both Verizon and Google projects, you need to factor exactly how much needed to be built for them, and how much will be needed for you. If you have 0 existing conduits and need to build 100% of your FTTH plant, while Verizon had x% of conduits already built, then your cost per home may be higher. BTW, out of curiosity, how many spare copper pairs were traditionally provisionsed on a cable run that passed 100 homes ? And in a fibre system, do you keep the same ratio of extra strands for each home passed ? From owen at delong.com Mon Feb 4 05:30:20 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 3 Feb 2013 21:30:20 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> Message-ID: On Feb 3, 2013, at 2:57 PM, Scott Helms wrote: > > > > On Sun, Feb 3, 2013 at 5:24 PM, Owen DeLong wrote: > > On Feb 3, 2013, at 12:33 PM, Scott Helms wrote: > >> >> >> >> On Sun, Feb 3, 2013 at 2:53 PM, Owen DeLong wrote: >> >> On Feb 2, 2013, at 5:06 PM, Scott Helms wrote: >> >>> Owen, >>> I think the confusion I have is that you seem to want to create solutions for problems that have already been solved. There is no cost effective method of sharing a network at layer 1 since DWDM is expensive and requires compatible gear on both sides and no one has enough fiber (nor is cheap enough in brand new builds) to simply home run every home and maintain that. ISPs that would want to use the shared network in general (>95% in my experience) don't want to maintain the access gear and since there is no clear way to delineate responsibilities when there is an issue its hard. >>> >>> >> ?? >> >> Who said anything about sharing the network at L1? >> >> You did. > > No, I didn't. I said build out an L1 infrastructure such that individual connections can be leased from it. Not shared L1 connections. > I have never advocated shared L1 connections. > > Sharing the entire network at layer 1 is what I and I believe you were talking about. Not sharing individual fiber connections, but using the same fiber plant for multiple layer 2 technologies. This is what you're suggesting, correct? > So long as you recognize that it's on a pair-by-pair basis end-to-end and not expecting any mixing/sharing/etc. by the L1 infrastructure provider, yes. > >> >> Is it more expensive to home-run every home than to put splitters in the neighborhood? Yes. Is it enough more expensive that the tradeoffs cannot be overcome? I remain unconvinced. >> >> >> This completely depends on the area and the goals of the network. In most cases for muni networks back hauling everything is more expensive. > > I agree it's more expensive. The question is whether it's enough more expensive to make it infeasible. You still haven't come anywhere near addressing that question. > > I've said repeatedly that this a network by network analysis. I've never said its infeasible, but that it is more expensive both initially and long term in MOST installs. That by itself is generally enough to invalidate the design since in almost all cases there's no benefit to home running all the connections. It doesn't make the connection faster nor do ISPs (as a group) care about a layer 1 versus layer 2 hand off. That's where we disagree. The benefit is that: 1. It doesn't lock the entire area into a single current technology. 2. It allows for individual subscribers (probably mostly businesses, but I have had a few occasions where this would have been useful as an individual) to get dark XC to other locations. 3. Subscribers who want individualized services from different vendors have a choice. 4. Providers have to compete on a leveled playing field and there is thus incentive to innovate even if the innovation moves away from PON. > > >> >> >> I'm not sure why you think it would be hard to delineate the responsibilities? You've got a fiber path maintained by the municipality with active equipment maintained by the ISP at each end. If the light coming out of the equipment at one end doesn't come out of the fiber at the other end, you have a problem in the municipality's domain. If the light makes it through in tact, you have a problem in the ISP's domain. >> >> There is equipment available that can test that fairly easily. >> >> OK, this one made my wife get scared I laughed so hard. You clearly have never tried to do this or had to work with different operators in the same physical network. Please, go talk to someone whose worked in the field of a FTTx network and describe this scenario to them. Its clear you don't want to hear it from me via email so please go do some research. > > > I've talked to a few people doing exactly that. Yes, you need different test sets depending on which L2 gear is involved, but, in virtually ever case, there is a piece of test gear that can be used to test a loop independent of the configuration of the L2 gear in question. > > Yes, there is a meter for all the different kinds of technologies that you might want to support. For example a DOCSIS 3.0 DSAM from JDSU will run you around $8000.00 A PON meter with long range lasers (more than 10 miles) from JDSU or Trilithic will cost you nearly $10,000. Exactly how many of those kinds of meters do you want to have to buy? How many of your staff are you going to train on them (they do require training and knowledge to use)? For my proposed methods of build-out, no need for the long range lasers. As I said, everything should be within 8km of the MMR. As I suggested, the simpler approach is to require the complaining L2 provider to cooperate in the diagnostic process and provide access to the applicable meters if necessary. The standard offered absent assistance from the L2 provider is OTDR success. > > For providers getting L1 service, it wouldn't be too hard to make this testing / providing necessary test equipment part of their contract. >>> The long and short of it is lots of people have tried to L1 sharing and its not economical and nothing I've seen here or elsewhere changes that. The thing you have to remember is that muni networks have to be cost effective and that's not just the capital costs. The operational cost in the long term is much greater than the cost of initial gear and fiber install. >>> >> We can agree to disagree. A muni network needs to be able to recover its costs. The costs of building out and maintaining home-run >> fiber are not necessarily that much greater than the costs of building out and maintaining fiber at the neighborhood. One option, for >> example, would be to have neighborhood B-Boxes where the fiber can either be fed into provider-specific splitters (same economy >> as existing PON deployments) or cross-connected to fiber on the F1 cable going back to the MMR (home-run). >> >> >> We can agree all we want, that doesn't change history. Handing out connections at layer 1 is both more expensive and less efficient. Its also extremely wasteful (which is why its more expensive) since your lowest unit you can sell is a fiber strand whether the end customer wants a 3 mbps connection or a gig its the same to the city. I'm not saying you shouldn't sell dark fiber, I'm saying that in 99% of the cities you can't build a business model around doing just that unless your city doesn't want to break even on the build and maintenance. > > If it's $700 per home passed to build out home-run fibers (which seems to be a reasonable approximation from earlier discussions), then there's no reason you can't sell $40/month service over that where the L1 component is a $10/month ($7 for capital recovery, $3 for operations and support) pricing component. > > Nope, no reason at all if you don't care about covering your costs. I just explained where the expected costs get covered, so you're going to have to explain that statement. > > By my estimates, to become truly impractical, you'd have to get somewhere north of $1500 per home passed. > > >> >> >> The only additional cost in this system over traditional PON is the larger number of fibers required in the F1 cable. >> >> >> PON networks aren't deployed this way and if you're going to backhaul all of the connections to a central point you wouldn't run PON. PON is worse in every performance related way to PON and the only reasons operators deploy it today is because its less expensive. Its less expensive because you don't have to backhaul all of the connections or have active components at the neighborhood level. > > Then don't deploy PON. I don't care whether PON gets deployed or not. You keep coming back at this as if PON is somehow the goal. Personally, I'd rather see Gig-E in every home and be done with it. > > However, the point is that building the infrastructure in that manner doesn't cost much more than building out traditional PON infrastructure (if you're doing it from greenfield) and it can support either technology. > > Sure it does, even in greenfield and whats more it costs more over the long term UNLESS you know where every home and business will be located 10 years from now. More yes, much more, I'm not so convinced. Owen From mohta at necom830.hpcl.titech.ac.jp Mon Feb 4 11:58:10 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 04 Feb 2013 20:58:10 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> Message-ID: <510FA252.2000405@necom830.hpcl.titech.ac.jp> Scott Helms wrote: >> Is it more expensive to home-run every home than to put splitters in the >> neighborhood? Yes. Is it enough more expensive that the tradeoffs cannot be >> overcome? I remain unconvinced. > This completely depends on the area and the goals of the network. In most > cases for muni networks back hauling everything is more expensive. Bot of you are wrong. There is no reason fiber is more expensive than copper, which means SS is cheap, as cheap as copper. As most of the cost is cable laying, which is little sensitive to the number of twisted pairs or fibers in the cable, PON, with splitters and lengthy drop cables (if you want a fiber shared by many subscribers, you need a lengthy drop cables from a splitter), can not be less expensive than SS. PON, which is expensive, is preferred by some carriers merely because it makes competition impossible. Masataka Ohta From joshua.klubi at gmail.com Mon Feb 4 12:00:30 2013 From: joshua.klubi at gmail.com (Joshua William Klubi) Date: Mon, 4 Feb 2013 12:00:30 +0000 Subject: WhoisGuard Message-ID: Is there any person from WhoisGuard . com on this group. or any one can help me with an effective contact, all mails to their ' support at whoisguard.com' is not been acknowledged or answered. Joshua From Kyle.Camilleri at melitaplc.com Mon Feb 4 14:03:54 2013 From: Kyle.Camilleri at melitaplc.com (Kyle Camilleri) Date: Mon, 4 Feb 2013 14:03:54 +0000 Subject: Global caches Message-ID: Dear Nanog Community, Some CDN providers such as Akamai and Google (often called Global Google Cache) are offering caches to ISPs. It is very convenient for small ISPs to alleviate bandwidth towards the provider, but also the CDN provider benefits by putting source of data closer to the user resulting in far better performance. Does anybody know of any other CDN providers that offer similar caches? Looking forward for your replies. Regards, Kyle From dwhite at olp.net Mon Feb 4 14:33:11 2013 From: dwhite at olp.net (Dan White) Date: Mon, 4 Feb 2013 08:33:11 -0600 Subject: Global caches In-Reply-To: References: Message-ID: <20130204143311.GC6481@dan.olp.net> On 02/04/13?14:03?+0000, Kyle Camilleri wrote: >Some CDN providers such as Akamai and Google (often called Global Google >Cache) are offering caches to ISPs. It is very convenient for small ISPs >to alleviate bandwidth towards the provider, but also the CDN provider >benefits by putting source of data closer to the user resulting in far >better performance. > >Does anybody know of any other CDN providers that offer similar caches? Netflix does as well: https://signup.netflix.com/openconnect/hardware The last time I asked, they required 5GB/s of peak traffic to consider you. -- Dan White From patrick at ianai.net Mon Feb 4 14:33:48 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 4 Feb 2013 09:33:48 -0500 Subject: Global caches In-Reply-To: References: Message-ID: <6590C582-14E0-4371-A2E1-57BBD6CF7AEA@ianai.net> On Feb 04, 2013, at 09:03 , Kyle Camilleri wrote: > Some CDN providers such as Akamai and Google (often called Global Google Cache) are offering caches to ISPs. It is very convenient for small ISPs to alleviate bandwidth towards the provider, but also the CDN provider benefits by putting source of data closer to the user resulting in far better performance. > > Does anybody know of any other CDN providers that offer similar caches? Don't know if you would call them a CDN, but . -- TTFN, patrick From dwhite at olp.net Mon Feb 4 14:35:39 2013 From: dwhite at olp.net (Dan White) Date: Mon, 4 Feb 2013 08:35:39 -0600 Subject: Global caches In-Reply-To: <20130204143311.GC6481@dan.olp.net> References: <20130204143311.GC6481@dan.olp.net> Message-ID: <20130204143539.GD6481@dan.olp.net> On 02/04/13?08:33?-0600, Dan White wrote: >On 02/04/13?14:03?+0000, Kyle Camilleri wrote: >>Some CDN providers such as Akamai and Google (often called Global Google >>Cache) are offering caches to ISPs. It is very convenient for small ISPs >>to alleviate bandwidth towards the provider, but also the CDN provider >>benefits by putting source of data closer to the user resulting in far >>better performance. >> >>Does anybody know of any other CDN providers that offer similar caches? > >Netflix does as well: > >https://signup.netflix.com/openconnect/hardware > >The last time I asked, they required 5GB/s of peak traffic to consider you. Make that: 5 gigabits/s of peak traffic. -- Dan White From simon at slimey.org Mon Feb 4 14:50:58 2013 From: simon at slimey.org (Simon Lockhart) Date: Mon, 4 Feb 2013 14:50:58 +0000 Subject: Global caches In-Reply-To: References: Message-ID: <20130204145057.GD6663@virtual.bogons.net> On Mon Feb 04, 2013 at 02:03:54PM +0000, Kyle Camilleri wrote: > Does anybody know of any other CDN providers that offer similar caches? Most CDN providers also provide free access to "super node" caches at major datacentres and peering points - depending on where you are located, which datacentres you're in, and what your network looks like, you may find that it's cheaper for you to interconnect with the CDNs within a datacentre (particularly if you can do it via an IX), than the provide space and power for CDN nodes within your own network. Simon From jeff.richmond at gmail.com Mon Feb 4 14:59:16 2013 From: jeff.richmond at gmail.com (Jeff Richmond) Date: Mon, 4 Feb 2013 06:59:16 -0800 Subject: Global caches In-Reply-To: <20130204145057.GD6663@virtual.bogons.net> References: <20130204145057.GD6663@virtual.bogons.net> Message-ID: <2C8CF907-DC58-46B8-8D03-AC6394ECAB21@gmail.com> While I would agree with that, having peering helps but certainly doesn't replace a localized CDN. Certainly better than nothing though. It also of course depends on the size of your network. If you are paying to carry that traffic (leased backhaul, etc.) from your peering point to your customers, you are still paying the same amount to deliver that content to your users (excluding any transit savings if moving from transit to get that CDN content). That is where an on-net CDN really saves you significantly as you can bury it deep into your network. I can't speak specifics here but I can tell you that the CDNs we have are filled at off-peak, so it really does become a win-win from a technical perspective (business case and politics are a completely different conversation though). -Jeff On Feb 4, 2013, at 6:50 AM, Simon Lockhart wrote: > On Mon Feb 04, 2013 at 02:03:54PM +0000, Kyle Camilleri wrote: >> Does anybody know of any other CDN providers that offer similar caches? > > Most CDN providers also provide free access to "super node" caches at major > datacentres and peering points - depending on where you are located, which > datacentres you're in, and what your network looks like, you may find that it's > cheaper for you to interconnect with the CDNs within a datacentre (particularly > if you can do it via an IX), than the provide space and power for CDN nodes > within your own network. > > Simon > From jra at baylink.com Mon Feb 4 15:18:15 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 4 Feb 2013 10:18:15 -0500 (EST) Subject: Is Google Fiber a model for Municipal Networks? In-Reply-To: Message-ID: <31653397.4820.1359991095653.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > Here is the architecture document: > http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/36936.pdf Nice get; that will make very interesting reading today. Thanks. -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Mon Feb 4 15:20:52 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 4 Feb 2013 10:20:52 -0500 (EST) Subject: Rollup: Small City Municipal Broadband In-Reply-To: Message-ID: <10908428.4822.1359991252263.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jason Baugher" > What we've seen is that the RBOC typically has a lot of crap copper in the > ground, in a lot of cases air-core (pre gel-fill) that hasn't held up well. > With the popularity of DSL, they ran out of good pairs to use. As they ran > out of pairs, they eventually had to put in remote terminals to handle any > new voice orders. They knew the future was fiber, at least to the node, so > they had no incentive to build new copper plant, and little incentive to > maintain the existing plant. I have been saying, out loud, in public places, for at least 15 years, that Verizon's *real* incentive in doing FiOS was to clean up after 3 decades of GTE doing cut-to-clear rather than fixing actual problems in their copper OSP... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From fredan-nanog at fredan.se Mon Feb 4 16:06:28 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Mon, 04 Feb 2013 17:06:28 +0100 Subject: Global caches In-Reply-To: References: Message-ID: <510FDC84.9070805@fredan.se> > Does anybody know of any other CDN providers that offer similar caches? > Yes. The Last Mile Cache. http://tlmc.fredan.se It's an completely open solution for everybody, both the ISP (Internet Service Provider) and CSP (Content Service Provider). -- //fredan From mohta at necom830.hpcl.titech.ac.jp Mon Feb 4 17:03:52 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 05 Feb 2013 02:03:52 +0900 Subject: Is Google Fiber a model for Municipal Networks? In-Reply-To: References: <20130203215226.GA53926@ussenterprise.ufp.org> Message-ID: <510FE9F8.6010409@necom830.hpcl.titech.ac.jp> Scott Helms wrote: > Here is the architecture document: > http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/36936.pdf The document, seemingly, does not address drop cable cost difference. It does not address L1 unbundling with WDM-PON, which requires fiber patch panel identical to that required for SS, either. As for power consumption at CO, all the transmitters do not have to have power consuming LDs but can just have modulators to modulate light from a shared light source, which has already happened with QSFP+: http://www.luxtera.com/faqs/ How do you generate light in silicon? Actually, we don't. Silicon is a bad material to try and build lasers in. Some silicon lasers have been demonstrated, but these are completely impractical. As it turns out there's no need to build a silicon laser: lasers are already very inexpensive (remember, there's already one in every PC - inside the CD/DVD player). The challenge has been finding an inexpensive way to attach the lasers to silicon. Solving this problem, and the related one of inexpensively attaching optical fibers to silicon, is a key piece of Luxtera's intellectual property. We think of a laser as being just like a DC power supply ? only it provides a steady stream of photons rather than electrons. Masataka Ohta From bicknell at ufp.org Mon Feb 4 17:05:30 2013 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 4 Feb 2013 09:05:30 -0800 Subject: Is Google Fiber a model for Municipal Networks? In-Reply-To: <002901ce028b$3e002670$ba007350$@iname.com> References: <20130203215226.GA53926@ussenterprise.ufp.org> <25075047.4814.1359929032564.JavaMail.root@benjamin.baylink.com> <20130203224014.GA55641@ussenterprise.ufp.org> <002901ce028b$3e002670$ba007350$@iname.com> Message-ID: <20130204170530.GA91182@ussenterprise.ufp.org> In a message written on Sun, Feb 03, 2013 at 09:53:50PM -0600, Frank Bulk wrote: > Sure, Verizon has been able to get their cost per home passed down to $700 To be fair, Verizon has chosen to build their FIOS network in many expensive to build locations, because that's where they believe there to be the most high profit customers. While perhaps not the most expensive builds possible, I would expect Verizon's FIOS experience to be on the upper end of the cost scale. > Real-world FTTH complete overbuilds among RLECs (rural incumbent LECs) are > typically between $2,000 and $5,000 per home served (that includes the ONT > and customer turn-up). Slide 13 of > http://www.natoa.org/events/NATOAPresentationCalix.pdf shows an average of > $2,377 per home passed (100% take rate). You can see on Slide 14 how the > lower households per square mile leads to substantially greater costs. Rural deployments present an entirely different problem of geography. I suspect the dark fiber model I advocate for is appropriate for 80% of the population from large cities to small towns; but for the 20% in truely rural areas it doesn't work and there is no cheap option as far as I can tell. > And for Verizon's cost per home passed: "Consider the total project cost of > Verizon's FiOS, $23B, and then divide that not by the 17M homes passed (as I > did), but with the actual subscribers (5,1M), This would result in a cost > per subscriber of $23B/5.1M = $4,500." But Verizon knows that take rate will go up over time. Going from a 5.1M -> 10M take rate would cut that number in half, going to the full 17M would cut it by 70%. Fiber to the home is a long term play, paybacks in 10-20 year timeframes. I'm sure wall-street doesn't want to hear that, but it's the truth. > Remember that Google cherry-picked which city it would serve, so it was able > to identify location that is likely less challenging and expensive to serve > than the average. A lot of Google's Kansas City build will not be buried True, but I think it means we've bound the problem. It appears to take $1400-$4500 to deploy fiber to the home in urban and suburban areas, depending on all the fun local factors that effect costs. Again, if the ROI calculation is done on a realistic for infrastructure 10-20 year time line, that's actually very small money per home. If it's done on a 3 year, wall street turnaround it will never happen as it's not profitable. Which is a big part of why I want municipalities to finance it on 10-30 year government bonds, rather than try and have BigTelco and BigCableCo raise capital on wall street to do the job. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From mpetach at netflight.com Mon Feb 4 17:55:57 2013 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 4 Feb 2013 09:55:57 -0800 Subject: 2013.02.04 NANOG57 day 1 morning session notes posted Message-ID: I jotted down some notes from this morning's session in case people are curious; they should be up visible at http://kestrel3.netflight.com/2013.02.04-day1-morning-session.txt apache's kinda flakey on the box; if it stops responding, ping me and I'll bounce the server. ^_^; Thanks! Matt From jra at baylink.com Mon Feb 4 17:59:04 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 4 Feb 2013 12:59:04 -0500 (EST) Subject: Is Google Fiber a model for Municipal Networks? In-Reply-To: <20130204170530.GA91182@ussenterprise.ufp.org> Message-ID: <5619592.4902.1360000744438.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Leo Bicknell" > > Remember that Google cherry-picked which city it would serve, so it was able > > to identify location that is likely less challenging and expensive to serve > > than the average. A lot of Google's Kansas City build will not be buried > > True, but I think it means we've bound the problem. It appears to > take $1400-$4500 to deploy fiber to the home in urban and suburban > areas, depending on all the fun local factors that effect costs. And look what appeared in my mailbox just now: http://broadcastengineering.com/ip-network/google-s-high-speed-fiber-installation-provides-economic-growth-kc Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mpetach at netflight.com Mon Feb 4 18:04:04 2013 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 4 Feb 2013 10:04:04 -0800 Subject: Is Google Fiber a model for Municipal Networks? In-Reply-To: <20130204170530.GA91182@ussenterprise.ufp.org> References: <20130203215226.GA53926@ussenterprise.ufp.org> <25075047.4814.1359929032564.JavaMail.root@benjamin.baylink.com> <20130203224014.GA55641@ussenterprise.ufp.org> <002901ce028b$3e002670$ba007350$@iname.com> <20130204170530.GA91182@ussenterprise.ufp.org> Message-ID: On Mon, Feb 4, 2013 at 9:05 AM, Leo Bicknell wrote: > > True, but I think it means we've bound the problem. It appears to > take $1400-$4500 to deploy fiber to the home in urban and suburban > areas, depending on all the fun local factors that effect costs. *sigh* I'd gladly pay $5000 NRC to get fiber to my house. I only wish it were that simple. :( Heck, if they wanted longer-term ROI, I'd pay $5000 NRC and $200 MRC for a fiber connection to my house, if only there were someone who could provide it. I suspect the real costs are much higher, and that's why there's nobody willing to do it for that cheap. Matt From jra at baylink.com Mon Feb 4 18:08:50 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 4 Feb 2013 13:08:50 -0500 (EST) Subject: Is Google Fiber a model for Municipal Networks? In-Reply-To: Message-ID: <32705291.4908.1360001330734.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Matthew Petach" > On Mon, Feb 4, 2013 at 9:05 AM, Leo Bicknell wrote: > > True, but I think it means we've bound the problem. It appears to > > take $1400-$4500 to deploy fiber to the home in urban and suburban > > areas, depending on all the fun local factors that effect costs. > > *sigh* > > I'd gladly pay $5000 NRC to get fiber to my house. I only wish it > were that simple. :( Heck, if they wanted longer-term ROI, I'd pay > $5000 NRC and $200 MRC for a fiber connection to my house, if > only there were someone who could provide it. I suspect the real > costs are much higher, and that's why there's nobody willing to do > it for that cheap. No, Matt; in a sufficiently dense deployment, it appears you can actually get it done for that money, based on actual deployment results. If my project pans out, I'll give it to you for less than that. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mpetach at netflight.com Mon Feb 4 18:23:12 2013 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 4 Feb 2013 10:23:12 -0800 Subject: Is Google Fiber a model for Municipal Networks? In-Reply-To: <32705291.4908.1360001330734.JavaMail.root@benjamin.baylink.com> References: <32705291.4908.1360001330734.JavaMail.root@benjamin.baylink.com> Message-ID: On Mon, Feb 4, 2013 at 10:08 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Matthew Petach" > >> On Mon, Feb 4, 2013 at 9:05 AM, Leo Bicknell wrote: >> > True, but I think it means we've bound the problem. It appears to >> > take $1400-$4500 to deploy fiber to the home in urban and suburban >> > areas, depending on all the fun local factors that effect costs. >> >> *sigh* >> >> I'd gladly pay $5000 NRC to get fiber to my house. I only wish it >> were that simple. :( Heck, if they wanted longer-term ROI, I'd pay >> $5000 NRC and $200 MRC for a fiber connection to my house, if >> only there were someone who could provide it. I suspect the real >> costs are much higher, and that's why there's nobody willing to do >> it for that cheap. > > No, Matt; in a sufficiently dense deployment, it appears you can actually > get it done for that money, based on actual deployment results. > > If my project pans out, I'll give it to you for less than that. :-) I think the problem with your model is that the same one Google faced; you don't divide your cost based on the number of homes connected, you divide by the number of people forking out money for it. Building infrastructure to 10,000 homes doesn't work if 9,999 of them say "no thanks, I'm happy with my current cable TV"; that last person's gonna have a heck of a bill, or you're going to go bankrupt subsidizing them. Google Fiber's "sign up, and if we get enough signups, then we'll build" model seems to be the only sane way to ensure that you won't be left holding the bag if not enough subscribers opt in to the service to fund it. Now, if only we had a system for signing up to show our support for a build like that here in the bay area... ^_^; Matt From Kyle.Camilleri at melitaplc.com Mon Feb 4 16:11:33 2013 From: Kyle.Camilleri at melitaplc.com (Kyle Camilleri) Date: Mon, 4 Feb 2013 16:11:33 +0000 Subject: Global caches In-Reply-To: References: Message-ID: Hi Alex, We already have Google Cache although we don't peer with them directly. As said earlier, what I'm after is to cache content to provide better performance to our customers and alleviating some bandwidth towards provider. Taking an example of Global Google Cache, they provide and manage the servers themselves, absolutely no huge effort needed from the ISP. Making it very convenient. I know of Akamai and Netfix that does this in a fairly similar way, but would like to know if there are any other CDNs that do this. Regards, Kyle From: askoorb at gmail.com [mailto:askoorb at gmail.com] On Behalf Of Alex Brooks Sent: 04 February 2013 16:13 To: Kyle Camilleri Subject: Re: Global caches Hi, On Mon, Feb 4, 2013 at 2:03 PM, Kyle Camilleri > wrote: Dear Nanog Community, Some CDN providers such as Akamai and Google (often called Global Google Cache) are offering caches to ISPs. It is very convenient for small ISPs to alleviate bandwidth towards the provider, but also the CDN provider benefits by putting source of data closer to the user resulting in far better performance. Does anybody know of any other CDN providers that offer similar caches? I think I should give a note of caution first. Normally, CDNs will only consider you for caching if you already peer with them - in most cases the majority of any performance or cost improvements come from direct peering with a CDN first. Unfortunately, I can't find an entry for you on PeeringDB, but assuming that you are AS12709, you only seem to be peering with a few 'major' networks (Vodafone Malta (AS33874) WIND Italy (AS1267), Global Crossing (AS3549) and Level3 (AS3356)). If you don't (or can't) peer with, say, Google or Akamai, they are unlikely to invite you to join their caching systems. I'm guessing that because you are on an Island in the middle of the Mediterranean; with nobody wanting to peer on the Island, you are looking to cache as much as possible on the Island, as undersea cables are expensive. Is this correct? If you give the list a bit more information about what the problem you are trying to solve is, the people here are pretty good at coming up with solutions or putting you in contact with people who may be able to help. Best wishes, Alex From fkittred at gwi.net Mon Feb 4 19:57:13 2013 From: fkittred at gwi.net (Fletcher Kittredge) Date: Mon, 4 Feb 2013 14:57:13 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: References: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> <510DF096.60907@vaxination.ca> <20130203165850.GA44479@ussenterprise.ufp.org> Message-ID: Scott; I apologize. You could very well sincerely not realize you are wrong. Obviously, erroneous thinking is not the same as making things up. However, it is not good that bad information is out there and it should be corrected. First you refer to them as "dry copper" or "dry pair" which has no regulatory meaning. I don't know if using the wrong term is part of the reason you have had difficulty ordering them. The proper term is Unbundled Network Elements(UNE) copper loops. UNEs are the elements the ILECs are required to sell to CLECs. There are a variety of different types of UNE loops. The most accurate way to identify them is probably referring to an ILEC wholesale tariff filed on a state-by-state basis. The FCC defines Section 251 requirements, but individual state PUCs administer the tariffs for their locations. Second, going to any document by the NTCA, an advocacy organization, for information on this topic is a mistake for obvious bias reasons. The controlling documents are the Telecommunications Act of 1996 (Telco Act), the FCC's Triennial Review Order[s](TRO), various ILEC tariffs and the individual InterConnection Agreements(ICA) between ILECs and CLECs. Under the Telco Act, UNE loops are a Section 251 requirement. The FCC has primary responsibility for administering Section 251 requirements and the FCC's rules for doing so are put forth in the TROs. The last TROs were released in 2004, so that would be the last time "the rules changed" as you put it. So there has not been a recent change in the rules resulting in residential CLEC demise. Third, it is true that an ILEC is not required to add capacity. However, it is hard for me to believe anyone would say with a straight face that any residential CLECs went out of business primarily because ILECs are not required to add copper. In a period where there is steady erosion of landlines resulting in a lot of unused copper loops, lack of copper loops is a small issue. Some residential CLECs went out of business because they had broken business models. Some residential CLECs became successful business CLECs as well, check out Earthlink (NASDAQ: ELNK). The controlling issues are more financial than regulatory. We have had the same regulatory regime for almost a decade. Any prudent DSL provider, ILEC or CLEC, should have plans for a transition to copper, but the copper network still has useful life in it for residential CLECs as well as other markets. Fletcher On Sun, Feb 3, 2013 at 9:53 PM, Scott Helms wrote: > Fletcher, > > Your specific case may vary, but I am most certainly _not_ "making stuff > up". In many territories, especially outside of major metro areas, you > cannot order dry pairs. This has been because of a combination of relaxed > rules (if you really want I can dig up the NTCA reports on this) and > because the rules never required the ILEC to add capacity once they were > used up. > > > On Sun, Feb 3, 2013 at 9:29 PM, Fletcher Kittredge wrote: > >> >> In this particular post, your making stuff up. There are still >> "residential focused" CLECs and ordering Unbundled Network Elements(UNEs) >> is not more difficult than in the past. The rules haven't changed. >> >> What is certainly true is that many CLECs have found that it is more >> lucrative to sell to businesses, but I don't think there is a correlation >> with residential getting more difficult. We used to be 75%/25% >> residential/business and are now 45%/55% business, but that reflects the >> *rapid* growth of the business market. >> >> regards, >> Fletcher >> >> On Sun, Feb 3, 2013 at 3:42 PM, Scott Helms wrote: >> >>> Joe, >>> >>> I'm assuming from your domain that you're in Canada where yes dry pairs >>> are >>> still generally available. I apologize for not making it clear that my >>> comment was specifically about the US where dry pairs are nearly >>> impossible >>> to order today and the CLEC market has almost entirely abandoned the >>> residential space. In fact, the only state in the US that I still see any >>> residentially focused CLECs is Texas which tells me there is something >>> about the regulations in that state that makes it more feasible. >>> >>> >>> On Sun, Feb 3, 2013 at 3:32 PM, Joe Abley wrote: >>> >>> > >>> > On 2013-02-03, at 14:39, Scott Helms wrote: >>> > >>> > > Dry pairs are impossible to order these days for a reason. >>> > >>> > Dry pairs are trivial to order round these parts. Generalisations are >>> > always wrong, no doubt including this one. >>> > >>> > >>> > Joe (putting the N back in NANOG) >>> >>> >>> >>> >>> -- >>> Scott Helms >>> Vice President of Technology >>> ZCorum >>> (678) 507-5000 >>> -------------------------------- >>> http://twitter.com/kscotthelms >>> -------------------------------- >>> >> >> >> >> -- >> Fletcher Kittredge >> GWI >> 8 Pomerleau Street >> Biddeford, ME 04005-9457 >> 207-602-1134 > > > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From jfmezei_nanog at vaxination.ca Mon Feb 4 20:26:38 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 04 Feb 2013 15:26:38 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: References: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> <510DF096.60907@vaxination.ca> <20130203165850.GA44479@ussenterprise.ufp.org> Message-ID: <5110197E.1030904@vaxination.ca> On 13-02-04 14:57, Fletcher Kittredge wrote: > of the reason you have had difficulty ordering them. The proper term is > Unbundled Network Elements(UNE) copper loops. The Bell Canada tariff on ADSL acess (5410) uses the following terminology: (GAS = wholesale DSL service operated by incumbent telco that provides PPPoE (there are some variations that provide ethernet connection) between end users and independent ISPs) ## (h) GAS Access will only be provisioned over Company provided primary exchange service, unbundled local loops used to provide CLEC primary exchange service, or dry loops. ## "Dry Loop" refers to a local loop that has no phone service attached to it (either telco or CLEC) but has the telco's wholesale DSL service. As I recall, it is tariffed separatly and differently from unbundled local loops. (If an ISP has its own DSLAM, it would need an unbundled local loop since it isn't buying the wholesale DSL service from Bell). In the USA, is access to the last mile copper mandated only for CLECs or can a company that is not a CLEC (aka: an ISP) also get access to the copper between CO and homes ? From fkittred at gwi.net Mon Feb 4 20:36:44 2013 From: fkittred at gwi.net (Fletcher Kittredge) Date: Mon, 4 Feb 2013 15:36:44 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <5110197E.1030904@vaxination.ca> References: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> <510DF096.60907@vaxination.ca> <20130203165850.GA44479@ussenterprise.ufp.org> <5110197E.1030904@vaxination.ca> Message-ID: Jean-Francois; The only regulatory regime I am familiar with is the US and the original poster specifically specified the US regime. In the US, only CLECs have the right to order UNEs. Many ISPs became CLECs for that reason. In the states in which we operate, becoming a CLEC is a minimal burden. Being a CLEC has the added advantage of access to utility poles. regards, Fletcher On Mon, Feb 4, 2013 at 3:26 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > On 13-02-04 14:57, Fletcher Kittredge wrote: > > > of the reason you have had difficulty ordering them. The proper term is > > Unbundled Network Elements(UNE) copper loops. > > The Bell Canada tariff on ADSL acess (5410) uses the following > terminology: (GAS = wholesale DSL service operated by incumbent telco > that provides PPPoE (there are some variations that provide ethernet > connection) between end users and independent ISPs) > > ## > (h) GAS Access will only be provisioned over Company provided primary > exchange service, unbundled local loops used to provide CLEC primary > exchange service, or dry loops. > ## > > "Dry Loop" refers to a local loop that has no phone service attached to > it (either telco or CLEC) but has the telco's wholesale DSL service. > As I recall, it is tariffed separatly and differently from unbundled > local loops. (If an ISP has its own DSLAM, it would need an unbundled > local loop since it isn't buying the wholesale DSL service from Bell). > > > In the USA, is access to the last mile copper mandated only for CLECs or > can a company that is not a CLEC (aka: an ISP) also get access to the > copper between CO and homes ? > > > -- Fletcher Kittredge GWI 8 Pomerleau Street Biddeford, ME 04005-9457 207-602-1134 From khelms at zcorum.com Mon Feb 4 20:46:57 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 4 Feb 2013 15:46:57 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <004001ce028f$a384c790$ea8e56b0$@iname.com> References: <9941705.4764.1359923608048.JavaMail.root@benjamin.baylink.com> <004001ce028f$a384c790$ea8e56b0$@iname.com> Message-ID: Frank, I certainly agree that fiber plant is in general easier than copper plant to maintain. My main concern is that in this case Jay is considering allowing not only different vendors but different technologies on the same fiber plant. That, in a small system without a ton of technical experience, is a very difficult scenario mainly because the city will almost invariably under price their wholesale (layer 1, 2, or 3) rates and the ISPs that operate in these situations are also usually quite shallow in terms or technical skill set. Its not a matter of it being impossible, but its much more difficult to just break even in this scenario. I'd personally advocate taking the approach that San Diego took when they built their network (which IIRC they don't offer access to) several years back. The buried all their fiber plant but in trenches that allow easy (relatively) access and they lease space in those runs so if private operators want to pull their own fiber to some or all of the places the city reaches they can without having to worry about supporting unfamiliar technology on their plant. Our maintenance costs, in order of greatest to least, have been locating, > cable moves (i.e. bridge project), monitoring digs, and damage to fiber > (rodents and vehicles that hit peds). We have had many more ONT issues > than > fiber issues, and most fiber issues can be resolved by cleaning both sides > of the fiber (customer and head end). And we've had to replace the 50' > patch cable between the OLTG and optical splitter a two of three times. > > While finger-pointing is always a risk when multiple players are involved > in > delivering any service, I don't perceive that as being as much of a problem > as you think it will be. With the right fiber testing gear, any suspected > problems can pretty quickly be identified. > > Frank > Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Mon Feb 4 20:49:48 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 4 Feb 2013 15:49:48 -0500 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: <004301ce0292$2b85c1b0$82914510$@iname.com> References: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> <020901ce01d3$0da88c00$28f9a400$@iname.com> <004301ce0292$2b85c1b0$82914510$@iname.com> Message-ID: Frank, One thing to keep in mind is that I don't believe its possible to get a contract with the bulk of the content owners in a wholesale scenario. This would be a different kind of situation than I've seen attempted in the past but in general the content guys get very picky about how video delivery is done. I'd certainly not claim to be authoritative on this, but I've never seen it done and I have seen the content guys strike down shared head end systems in almost all cases. Also, apologies for the rash of emails since this is the first time I've been able to get back to this thread. On Sun, Feb 3, 2013 at 11:43 PM, Frank Bulk wrote: > Brandon: > > My apologies, I didn't mean to suggest that providers would be unable to > provide video services across the muni fiber infrastructure. I was just > pointing out that many customers want a triple play, so that should be a > factor that Jay considers when considering a GPON-only or ActiveE design, > as > an RF-overlay on a GPON network is likely more profitable than an IP TV > service on top of GPON or ActiveE. And Jay wants to attract multiple > providers, so he wants a fiber design that's as attractive to as many > parties as reasonably possible. > > Frank > > -----Original Message----- > From: Brandon Ross [mailto:bross at pobox.com] > Sent: Sunday, February 03, 2013 9:56 AM > To: Frank Bulk > Cc: NANOG; Jay Ashworth > Subject: RE: Will wholesale-only muni actually bring the boys to your yard? > > On Sat, 2 Feb 2013, Frank Bulk wrote: > > > Yes, but IP TV is not profitable on stand-alone basis -- it's just a > > necessary part of the triple play. A lot of the discussion has been > about > > Internet and network design, but not much about the other two "plays". > > I don't know if that's true or not, but so what? > > The concern was that providers would be unable to provide television > services across this muni fiber infrastructure and that customers would > demand triple play. I showed that they absolutely can provide this > service by doing it across IP. > > If a provider can't make money at it, then they don't have to provide it. > > This whole exercise, I thought, was about removing the tyranny of the > monopoly of the last mine so that these other innovations could take place > in an open market. > > And as far as the "other" triple play, it's even more well established > that delivery of voice over IP can be done economically. Or do you need > me to send you URLs of companies that do it to prove it? > > > -----Original Message----- > > From: Brandon Ross [mailto:bross at pobox.com] > > Sent: Saturday, February 02, 2013 3:53 PM > > To: Jay Ashworth > > Cc: NANOG > > Subject: Re: Will wholesale-only muni actually bring the boys to your > yard? > > > > On Sat, 2 Feb 2013, Jay Ashworth wrote: > > > >>> Perhaps I live in a different world, but just about all of the small to > >>> midsize service providers I work with offer triple play today, and > nearly > >>> all of them are migrating their triple play services to IP. > >> > >> Really. Citations? I'd love to see it play that way, myself. > > > > Okay: > > > > South Central Rural Telephone > > Glasgow, KY > > http://www.scrtc.com/ > > Left side of page, "Digital TV service". See this news article: > > > > > http://www.wcluradio.com/index.php?option=com_content&view=article&id=15567 > : > > capacity-crowd-hears-good-report-at-scrtc-annuan-mee > > > > "He also reported that SCRTC is continuing to upgrade our services, > > converting customers to the new IPTV service and trying to get as much > > fiber optic cable built as possible." > > > > Camellia Communications > > Greenville, AL > > http://camelliacom.com/services/ctv-dvr.html > > Note the models of set-top boxes they are using are IP based > > > > Griswold Cooperative Telephone > > Griswold, IA > > http://www.griswoldtelco.com/griswold-coop-iptv-video > > > > Farmer's Mutual Coopeative Telephone > > Moulton, IA > > http://farmersmutualcoop.com/ > > > > Citizens > > Floyd, VA > > http://www.citizens.coop/ > > > > > > How about a Canadian example you say? > > > > CoopTel > > Valcourt, QB > > http://www.cooptel.qc.ca/en-residentiel-tele-guidesusager.php > > Check out the models of set-top boxes here too. > > > > Oh, also, have you heard of ATT U-Verse? > > > > http://www.att.com/gen/press-room?pid=4800&cdvn=news&newsarticleid=26580 > > > > "AT&T U-verse TV is the only 100 percent Internet Protocol-based > > television (IPTV) service offered by a national service provider" > > > > So even the likes of AT&T, in this scheme, could buy fiber paths to their > > subs and provide TV service. I'm pretty sure AT&T knows how to deliver > > voice services over IP as well. > > > > Do you want more examples? I bet I can come up with 50 small/regional > > telecom companies that are providing TV services over IP in North America > > if I put my mind to it. > > > > > > -- > Brandon Ross Yahoo & AIM: > BrandonNRoss > +1-404-635-6667 ICQ: > 2269442 > Schedule a meeting: https://doodle.com/bross Skype: > brandonross > > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jfmezei_nanog at vaxination.ca Mon Feb 4 21:01:04 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 04 Feb 2013 16:01:04 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: References: <9941705.4764.1359923608048.JavaMail.root@benjamin.baylink.com> <004001ce028f$a384c790$ea8e56b0$@iname.com> Message-ID: <51102190.6020103@vaxination.ca> On 13-02-04 15:46, Scott Helms wrote: > I certainly agree that fiber plant is in general easier than copper plant > to maintain. My main concern is that in this case Jay is considering > allowing not only different vendors but different technologies on the same > fiber plant. If you are strictly a layer 1 provider, I would assume that you have setup properly documented procedures and responsabilities in case of faults. Perhaps the ISP is responsible for debugging their problems and if they can show a layer 1 problem, then the city steps in, disconnects the strand at both ends and uses its own L1 equipment to test the strand. If the rules are clear, then ISPs would choose OLT and ONT equipment which provides remote debugging capabilities since physical visits to the city owned aggregation point will be difficult. From khelms at zcorum.com Mon Feb 4 21:04:34 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 4 Feb 2013 16:04:34 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> Message-ID: Owen, I'm trimming this for my own sanity if I snip out something important please let me know. > So long as you recognize that it's on a pair-by-pair basis end-to-end and > not expecting any mixing/sharing/etc. by the L1 infrastructure provider, > yes. > OK good, now we're speaking on the same topic :) > > >> >>> Is it more expensive to home-run every home than to put splitters in the >>> neighborhood? Yes. Is it enough more expensive that the tradeoffs cannot be >>> overcome? I remain unconvinced. >>> >> >> >> This completely depends on the area and the goals of the network. In >> most cases for muni networks back hauling everything is more expensive. >> >> >> I agree it's more expensive. The question is whether it's enough more >> expensive to make it infeasible. You still haven't come anywhere near >> addressing that question. >> > > I've said repeatedly that this a network by network analysis. I've never > said its infeasible, but that it is more expensive both initially and long > term in MOST installs. That by itself is generally enough to invalidate > the design since in almost all cases there's no benefit to home running all > the connections. It doesn't make the connection faster nor do ISPs (as a > group) care about a layer 1 versus layer 2 hand off. > > > That's where we disagree. The benefit is that: > > 1. It doesn't lock the entire area into a single current technology. > Neither does a ring architecture. > 2. It allows for individual subscribers (probably mostly businesses, but > I have had a few occasions > where this would have been useful as an individual) to get dark XC to > other locations. > Neither does a ring architecture, you do have fewer long runs, but in any build you're going to end up with spare pairs to use for this and in my experience the number of businesses who want this in given area are very small. I can't think of a network where this is more than 1% of the business connections. > 3. Subscribers who want individualized services from different vendors > have a choice. > Subscribers don't care if the hand off is at layer 1 or layer 2 so this is moot as well. > 4. Providers have to compete on a leveled playing field and there is thus > incentive to innovate > even if the innovation moves away from PON. > Again, this is a completely moot point. There is nothing in a ring or hub & spoke architecture that makes open access more difficult EXCEPT if you want to share lots of L1 connections. > > > >> >> >> >>> >>> I'm not sure why you think it would be hard to delineate the >>> responsibilities? You've got a fiber path maintained by the municipality >>> with active equipment maintained by the ISP at each end. If the light >>> coming out of the equipment at one end doesn't come out of the fiber at the >>> other end, you have a problem in the municipality's domain. If the light >>> makes it through in tact, you have a problem in the ISP's domain. >>> >>> There is equipment available that can test that fairly easily. >>> >> >> OK, this one made my wife get scared I laughed so hard. You clearly have >> never tried to do this or had to work with different operators in the same >> physical network. Please, go talk to someone whose worked in the field of >> a FTTx network and describe this scenario to them. Its clear you don't >> want to hear it from me via email so please go do some research. >> >> >> >> I've talked to a few people doing exactly that. Yes, you need different >> test sets depending on which L2 gear is involved, but, in virtually ever >> case, there is a piece of test gear that can be used to test a loop >> independent of the configuration of the L2 gear in question. >> > > Yes, there is a meter for all the different kinds of technologies that you > might want to support. For example a DOCSIS 3.0 DSAM from JDSU will run > you around $8000.00 A PON meter with long range lasers (more than 10 > miles) from JDSU or Trilithic will cost you nearly $10,000. Exactly how > many of those kinds of meters do you want to have to buy? How many of your > staff are you going to train on them (they do require training and > knowledge to use)? > > > For my proposed methods of build-out, no need for the long range lasers. > As I said, everything should be within 8km of the MMR. > > As I suggested, the simpler approach is to require the complaining L2 > provider to cooperate in the diagnostic process and provide access to the > applicable meters if necessary. The standard offered absent assistance from > the L2 provider is OTDR success. > Medium range lasers (anything that's running on single mode fiber) versus long range don't drive the cost. OTDR is not and cannot test for any phase modulated system and that includes every form of PON, Active Ethernet, and RFoG. You _might_ be able to use one to test RS-232 over fiber depending on the vendor. This is where you're really not getting it. As the owner of the physical medium you WILL be the blame of every problem until you prove differently. Every end user install that goes poorly, every time there is a connection drop, and every time some end user of $L1 partner calls them complaining the city will get the blame. > > > >> For providers getting L1 service, it wouldn't be too hard to make this >> testing / providing necessary test equipment part of their contract. >> >> The long and short of it is lots of people have tried to L1 sharing and >>> its not economical and nothing I've seen here or elsewhere changes that. >>> The thing you have to remember is that muni networks have to be cost >>> effective and that's not just the capital costs. The operational cost in >>> the long term is much greater than the cost of initial gear and fiber >>> install. >>> >>> We can agree to disagree. A muni network needs to be able to recover its >>> costs. The costs of building out and maintaining home-run >>> fiber are not necessarily that much greater than the costs of building >>> out and maintaining fiber at the neighborhood. One option, for >>> example, would be to have neighborhood B-Boxes where the fiber can >>> either be fed into provider-specific splitters (same economy >>> as existing PON deployments) or cross-connected to fiber on the F1 cable >>> going back to the MMR (home-run). >>> >>> >> We can agree all we want, that doesn't change history. Handing out >> connections at layer 1 is both more expensive and less efficient. Its also >> extremely wasteful (which is why its more expensive) since your lowest unit >> you can sell is a fiber strand whether the end customer wants a 3 mbps >> connection or a gig its the same to the city. I'm not saying you shouldn't >> sell dark fiber, I'm saying that in 99% of the cities you can't build a >> business model around doing just that unless your city doesn't want to >> break even on the build and maintenance. >> >> >> If it's $700 per home passed to build out home-run fibers (which seems to >> be a reasonable approximation from earlier discussions), then there's no >> reason you can't sell $40/month service over that where the L1 component is >> a $10/month ($7 for capital recovery, $3 for operations and support) >> pricing component. >> > > Nope, no reason at all if you don't care about covering your costs. > > > I just explained where the expected costs get covered, so you're going to > have to explain that statement. > No, you listed some more than optimistic numbers and passed that off as evidence. If you seriously think that the fiber connection is only worth $10 per month then you're off by ~100%. However, the point is that building the infrastructure in that manner >> doesn't cost much more than building out traditional PON infrastructure (if >> you're doing it from greenfield) and it can support either technology. >> > > Sure it does, even in greenfield and whats more it costs more over the > long term UNLESS you know where every home and business will be located 10 > years from now. > > > More yes, much more, I'm not so convinced. > > You think the fiber connectivity is only worth $10 too.... > Owen > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Mon Feb 4 21:07:56 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 4 Feb 2013 16:07:56 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <510FA252.2000405@necom830.hpcl.titech.ac.jp> References: <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> Message-ID: On Mon, Feb 4, 2013 at 6:58 AM, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > Scott Helms wrote: > > >> Is it more expensive to home-run every home than to put splitters in the > >> neighborhood? Yes. Is it enough more expensive that the tradeoffs > cannot be > >> overcome? I remain unconvinced. > > > This completely depends on the area and the goals of the network. In > most > > cases for muni networks back hauling everything is more expensive. > > Bot of you are wrong. > > There is no reason fiber is more expensive than copper, which means SS > is cheap, as cheap as copper. > Copper isn't cheap, its just there already. What is SS? > > As most of the cost is cable laying, which is little sensitive to the > number of twisted pairs or fibers in the cable, PON, with splitters > and lengthy drop cables (if you want a fiber shared by many > subscribers, you need a lengthy drop cables from a splitter), > can not be less expensive than SS. > No, most of the cost isn't in running the cabling. Today most of the cost is in lighting the fiber, though that varies on where you're running the cabling and what gear you're using to light it. > > PON, which is expensive, is preferred by some carriers merely because it > makes competition impossible. > PON is preferred by carriers because it works in their existing equipment and often with their existing fiber plant. Planning for a carrier network is very different (different requirements) than for a greenfield muni system. > > Masataka Ohta > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Mon Feb 4 21:10:50 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 4 Feb 2013 16:10:50 -0500 Subject: Is Google Fiber a model for Municipal Networks? In-Reply-To: <510FE9F8.6010409@necom830.hpcl.titech.ac.jp> References: <20130203215226.GA53926@ussenterprise.ufp.org> <510FE9F8.6010409@necom830.hpcl.titech.ac.jp> Message-ID: On Mon, Feb 4, 2013 at 12:03 PM, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > Scott Helms wrote: > > Here is the architecture document: >> http://static.**googleusercontent.com/**external_content/untrusted_** >> dlcp/research.google.com/en/**us/pubs/archive/36936.pdf >> > > The document, seemingly, does not address drop cable cost > difference. > > It does not address L1 unbundling with WDM-PON, which > requires fiber patch panel identical to that required > for SS, either. > They're not doing WDM-PON or any flavor of PON at all. Its entirely an Active Ethernet deployment. > > As for power consumption at CO, all the transmitters do not > have to have power consuming LDs but can just have modulators > to modulate light from a shared light source, which has already > happened with QSFP+: > > http://www.luxtera.com/faqs/ > > How do you generate light in silicon? > > Actually, we don't. Silicon is a bad material to try and > build lasers in. Some silicon lasers have been demonstrated, > but these are completely impractical. As it turns out there's > no need to build a silicon laser: lasers are already very > inexpensive (remember, there's already one in every PC > - inside the CD/DVD player). The challenge has been finding > an inexpensive way to attach the lasers to silicon. Solving > this problem, and the related one of inexpensively attaching > optical fibers to silicon, is a key piece of Luxtera's > intellectual property. We think of a laser as being just > like a DC power supply ? only it provides a steady stream of > photons rather than electrons. > > Masataka, are your trying to participate in the conversation or sell gear? The laser used in your DVD player is NOT suitable for a broadband deployment. > Masataka Ohta > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From bross at pobox.com Mon Feb 4 21:14:41 2013 From: bross at pobox.com (Brandon Ross) Date: Mon, 4 Feb 2013 16:14:41 -0500 (EST) Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: References: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> <020901ce01d3$0da88c00$28f9a400$@iname.com> <004301ce0292$2b85c1b0$82914510$@iname.com> Message-ID: On Mon, 4 Feb 2013, Scott Helms wrote: > One thing to keep in mind is that I don't believe its possible to get a > contract with the bulk of the content owners in a wholesale scenario. You do really need to read the thread before you post. I already pointed out that there are several companies that will handle or aggregate programming for you. See here: http://www.itvdictionary.com/tv_content_aggregators.html And this company here: http://www.telechannel.tv/overview.php I'm no expert in this space, but as I've pointed out multiple times, there are probably 50-100 small service providers in the US that provide video programming to their communities. I guarantee you at least most of them don't negotiate with all of the content providers themselves, on an individual basis. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From khelms at zcorum.com Mon Feb 4 21:15:07 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 4 Feb 2013 16:15:07 -0500 Subject: Is Google Fiber a model for Municipal Networks? In-Reply-To: <20130204170530.GA91182@ussenterprise.ufp.org> References: <20130203215226.GA53926@ussenterprise.ufp.org> <25075047.4814.1359929032564.JavaMail.root@benjamin.baylink.com> <20130203224014.GA55641@ussenterprise.ufp.org> <002901ce028b$3e002670$ba007350$@iname.com> <20130204170530.GA91182@ussenterprise.ufp.org> Message-ID: > Rural deployments present an entirely different problem of geography. I > suspect the dark fiber model I advocate for is appropriate for 80% of > the population from large cities to small towns; but for the 20% in > truely rural areas it doesn't work and there is no cheap option as far > as I can tell. > Why do you want a muni to put in fiber but not light it? Wouldn't it make more sense to simply put in fiber runs and let company's lease space? Trenches don't really degrade over time and there is a lot less of a requirement for cooperative troubleshooting and far less blame game. > > > Which is a big part of why I want municipalities to finance it on 10-30 > year government bonds, rather than try and have BigTelco and BigCableCo > raise capital on wall street to do the job. > I certainly sympathize with wanting independent connections but most cities have their own budget concerns and doing a bond on a fiber network they can't or don't light is a harder pay back on one that they do light. I'd suggest either layer 2 sharing (ethernet with per sub VLANs) or trench sharing as above. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jfmezei_nanog at vaxination.ca Mon Feb 4 21:17:35 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 04 Feb 2013 16:17:35 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> Message-ID: <5110256F.6000009@vaxination.ca> On 13-02-04 16:04, Scott Helms wrote: > Subscribers don't care if the hand off is at layer 1 or layer 2 so this is > moot as well. This is where one has to be carefull. The wholesale scenario in Canada leaves indepdendant ISPs having to explain to their customers that they can't fix certain problems and that they must call the telco/cableco to get it fixed. (in the case of a certain cable company, they can't even call them, it has to be done by email with response of at least 48 hours). So splitting responsabilities can be an annoyance if it becomes very visible to the end users. Another aspect: customers espect to be able to switch seamlessly from one ISP to the next. But ISP-2 can't take over from ISP-1 until ISP-1 has relinquised control over the line to the end user. In a layer 1 scenario, it means ISP-1 has to physically go and deinstall their CPE and disconnect strand from their OLT, and then ISP-2 can do the reverse and reconnect evrything to provide services. What happens when ISP-1 isn't interested in a quick disconnect and ISP-2 has to wait days/weeks with end use without service ? In a layer2 service, it is a matter of reconfiguring the OLT to pass ethernet packets to a different VLAN to a different ISP. No physical changes required and it can be almost tranparent to the end user who just has to make a new DHCP request and be provisioned by ISP-2. From khelms at zcorum.com Mon Feb 4 21:36:07 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 4 Feb 2013 16:36:07 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: References: <29129689.4720.1359865052763.JavaMail.root@benjamin.baylink.com> <510DF096.60907@vaxination.ca> <20130203165850.GA44479@ussenterprise.ufp.org> Message-ID: On Mon, Feb 4, 2013 at 2:57 PM, Fletcher Kittredge wrote: > > Scott; > > I apologize. You could very well sincerely not realize you are wrong. > Obviously, erroneous thinking is not the same as making things up. > Thanks, I think ;) I looked back and what I had written and I will say that I could have been expressed it along these lines; "It would be difficult in most RBOC territories today today offer residential scale broadband access because of the lack of good UNE loops. This is further complicated by the fact that in many territories local number are too expensive for the relatively low density of a given area and that retards the uptake of residential CLEC voice services." > > However, it is not good that bad information is out there and it should be > corrected. First you refer to them as "dry copper" or "dry pair" which > has no regulatory meaning. I don't know if using the wrong term is part > of the reason you have had difficulty ordering them. The proper term is > Unbundled Network Elements(UNE) copper loops. UNEs are the elements the > ILECs are required to sell to CLECs. There are a variety of different > types of UNE loops. The most accurate way to identify them is probably > referring to an ILEC wholesale tariff filed on a state-by-state basis. > The FCC defines Section 251 requirements, but individual state PUCs > administer the tariffs for their locations. > Agreed, dry pair is trade speak and not sufficiently accurate for a discussion on telco regulations. UNE is the correct term and we are both talking about the same item. > Second, going to any document by the NTCA, an advocacy organization, for > information on this topic is a mistake for obvious bias reasons. True, the NTCA is an advocacy group but they're also a communication group that tracks regulatory changes for the industry. I'll try and pull up the relevant documentation. > The controlling documents are the Telecommunications Act of 1996 (Telco > Act), the FCC's Triennial Review Order[s](TRO), various ILEC tariffs and > the individual InterConnection Agreements(ICA) between ILECs and CLECs. > Under the Telco Act, UNE loops are a Section 251 requirement. The FCC > has primary responsibility for administering Section 251 requirements and > the FCC's rules for doing so are put forth in the TROs. The last TROs > were released in 2004, so that would be the last time "the rules changed" > as you put it. So there has not been a recent change in the rules > resulting in residential CLEC demise. > I don't know why I gave you any reason to think I was referring to anything but the Supreme Court refusing to even hear the 2004 case as the primary regulatory shift for CLECs. That was the last year we had a formal change in Federal regulation, though its certainly not the end of cases and the FCC has a docket of CLEC/ILEC cases pretty much every week and those have been consistently in favor of the ILEC side of things. There are also state level actions and inactions that have made the climate harsher for CLECs. > > Third, it is true that an ILEC is not required to add capacity. However, > it is hard for me to believe anyone would say with a straight face that any > residential CLECs went out of business primarily because ILECs are not > required to add copper. In a period where there is steady erosion of > landlines resulting in a lot of unused copper loops, lack of copper loops > is a small issue. Some residential CLECs went out of business because > they had broken business models. Some residential CLECs became successful > business CLECs as well, check out Earthlink (NASDAQ: ELNK). The > controlling issues are more financial than regulatory. We have had the > same regulatory regime for almost a decade. > Earthlink is in the residential business because that's where they came from. They've been busy buying and building commercial services ever since the Mindspring merger. If it weren't for the fact that ITC-Deltacom ended up with a poor reputation that's what their name would likely be today. > > Any prudent DSL provider, ILEC or CLEC, should have plans for a transition > to copper, but the copper network still has useful life in it for > residential CLECs as well as other markets. > I'm not sure what you're trying to say here. Should this have been "a transition from copper"? > > Fletcher > > > On Sun, Feb 3, 2013 at 9:53 PM, Scott Helms wrote: > >> Fletcher, >> >> Your specific case may vary, but I am most certainly _not_ "making stuff >> up". In many territories, especially outside of major metro areas, you >> cannot order dry pairs. This has been because of a combination of relaxed >> rules (if you really want I can dig up the NTCA reports on this) and >> because the rules never required the ILEC to add capacity once they were >> used up. >> >> >> On Sun, Feb 3, 2013 at 9:29 PM, Fletcher Kittredge wrote: >> >>> >>> In this particular post, your making stuff up. There are still >>> "residential focused" CLECs and ordering Unbundled Network Elements(UNEs) >>> is not more difficult than in the past. The rules haven't changed. >>> >>> What is certainly true is that many CLECs have found that it is more >>> lucrative to sell to businesses, but I don't think there is a correlation >>> with residential getting more difficult. We used to be 75%/25% >>> residential/business and are now 45%/55% business, but that reflects the >>> *rapid* growth of the business market. >>> >>> regards, >>> Fletcher >>> >>> On Sun, Feb 3, 2013 at 3:42 PM, Scott Helms wrote: >>> >>>> Joe, >>>> >>>> I'm assuming from your domain that you're in Canada where yes dry pairs >>>> are >>>> still generally available. I apologize for not making it clear that my >>>> comment was specifically about the US where dry pairs are nearly >>>> impossible >>>> to order today and the CLEC market has almost entirely abandoned the >>>> residential space. In fact, the only state in the US that I still see >>>> any >>>> residentially focused CLECs is Texas which tells me there is something >>>> about the regulations in that state that makes it more feasible. >>>> >>>> >>>> On Sun, Feb 3, 2013 at 3:32 PM, Joe Abley wrote: >>>> >>>> > >>>> > On 2013-02-03, at 14:39, Scott Helms wrote: >>>> > >>>> > > Dry pairs are impossible to order these days for a reason. >>>> > >>>> > Dry pairs are trivial to order round these parts. Generalisations are >>>> > always wrong, no doubt including this one. >>>> > >>>> > >>>> > Joe (putting the N back in NANOG) >>>> >>>> >>>> >>>> >>>> -- >>>> Scott Helms >>>> Vice President of Technology >>>> ZCorum >>>> (678) 507-5000 >>>> -------------------------------- >>>> http://twitter.com/kscotthelms >>>> -------------------------------- >>>> >>> >>> >>> >>> -- >>> Fletcher Kittredge >>> GWI >>> 8 Pomerleau Street >>> Biddeford, ME 04005-9457 >>> 207-602-1134 >> >> >> >> >> -- >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- >> > > > > -- > Fletcher Kittredge > GWI > 8 Pomerleau Street > Biddeford, ME 04005-9457 > 207-602-1134 -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Mon Feb 4 21:39:13 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 4 Feb 2013 16:39:13 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: <5110256F.6000009@vaxination.ca> Message-ID: <28706127.4940.1360013953633.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jean-Francois Mezei" > > Subscribers don't care if the hand off is at layer 1 or layer 2 so > > this is moot as well. > > This is where one has to be carefull. The wholesale scenario in Canada > leaves indepdendant ISPs having to explain to their customers that they > can't fix certain problems and that they must call the telco/cableco to > get it fixed. (in the case of a certain cable company, they can't even > call them, it has to be done by email with response of at least 48 > hours). Yes, and Scott is *horribly* pessimistic (in my opinion) about how difficult it will be to have ISP clients who a) understand this and b) don't tolerate it. I will have more to say on this below. > Another aspect: customers espect to be able to switch seamlessly from > one ISP to the next. But ISP-2 can't take over from ISP-1 until ISP-1 > has relinquised control over the line to the end user. In a layer 1 > scenario, it means ISP-1 has to physically go and deinstall their CPE > and disconnect strand from their OLT, and then ISP-2 can do the > reverse and reconnect evrything to provide services. > > What happens when ISP-1 isn't interested in a quick disconnect and > ISP-2 has to wait days/weeks with end use without service ? What happens is that they tell us, the hometown fiber network operator that they're switching to ISP-2, who has already put in their own Take order to us, and we splash cut the pair, with no responsibility to ISP-1 whose contract warns them that *our residents* take priority, and if they screw up, they'll lose by it. Customer happy, and foot-dragging ISP -- who should -- takes the brunt. They do it too much, they pay. > In a layer2 service, it is a matter of reconfiguring the OLT to pass > ethernet packets to a different VLAN to a different ISP. No physical > changes required and it can be almost tranparent to the end user who > just has to make a new DHCP request and be provisioned by ISP-2. Yes, and that's why my *primary* goal will be to provide L2 service with city-owned ONTs. Making sure the plant is L1 *compliant* is my secondary goal, so I don't lock out PtP or L1 clients. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From khelms at zcorum.com Mon Feb 4 21:41:57 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 4 Feb 2013 16:41:57 -0500 Subject: Rollup: Small City Municipal Broadband In-Reply-To: <51102190.6020103@vaxination.ca> References: <9941705.4764.1359923608048.JavaMail.root@benjamin.baylink.com> <004001ce028f$a384c790$ea8e56b0$@iname.com> <51102190.6020103@vaxination.ca> Message-ID: On Mon, Feb 4, 2013 at 4:01 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > On 13-02-04 15:46, Scott Helms wrote: > > > I certainly agree that fiber plant is in general easier than copper plant > > to maintain. My main concern is that in this case Jay is considering > > allowing not only different vendors but different technologies on the > same > > fiber plant. > > If you are strictly a layer 1 provider, I would assume that you have > setup properly documented procedures and responsabilities in case of > faults. > Operationally you're never gonna get here. Installers are guys making $200 bucks an install whether it takes them 30 minutes or 4 hours. Most major operators (all I've worked with) struggle to get their own employees to do troubleshooting and installs correctly. We actually had to write software to ensure that installers are doing basic verification of levels before they leave home. > > Perhaps the ISP is responsible for debugging their problems and if they > can show a layer 1 problem, then the city steps in, disconnects the > strand at both ends and uses its own L1 equipment to test the strand. > > If the rules are clear, then ISPs would choose OLT and ONT equipment > which provides remote debugging capabilities since physical visits to > the city owned aggregation point will be difficult. > In really small numbers this is OK. The problem is that there seems to be a thought that a given network will have more than 4-5 dark fiber connections and that they will be a part of the pay back. Getting staff to even log into the web client of the OLT is generally problematic since the guys who do installs aren't normally allowed or even capable of safely using the EMS console. If they can even get the "right" version of Java running to get the JIMC working :( -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Mon Feb 4 21:46:33 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 4 Feb 2013 16:46:33 -0500 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: References: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> <020901ce01d3$0da88c00$28f9a400$@iname.com> <004301ce0292$2b85c1b0$82914510$@iname.com> Message-ID: Brandon, On Mon, Feb 4, 2013 at 4:14 PM, Brandon Ross wrote: > On Mon, 4 Feb 2013, Scott Helms wrote: > > One thing to keep in mind is that I don't believe its possible to get a >> contract with the bulk of the content owners in a wholesale scenario. >> > > You do really need to read the thread before you post. > There are tons and tons and tons of organizations that will sell the operator of a network content to sell to that operator's subscribers directly. Most well known is the cable coop, who only exists to do just that. The problem is that what's been proposed is that the network operator be able to then turn around and offer those services as a whole sale level to another operator, on the same physical but not not layer 2, plant. That's what I don't think you can get contracts inked for. > > I already pointed out that there are several companies that will handle or > aggregate programming for you. > > See here: > > http://www.itvdictionary.com/**tv_content_aggregators.html > > And this company here: > > http://www.telechannel.tv/**overview.php > > I'm no expert in this space, but as I've pointed out multiple times, there > are probably 50-100 small service providers in the US that provide video > programming to their communities. I guarantee you at least most of them > don't negotiate with all of the content providers themselves, on an > individual basis. There are way more than 100. NCTC has more than 1000 members themselves http://www.nctconline.org/ > > > -- > Brandon Ross Yahoo & AIM: > BrandonNRoss > +1-404-635-6667 ICQ: > 2269442 > Schedule a meeting: https://doodle.com/bross Skype: > brandonross > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Mon Feb 4 21:47:09 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 4 Feb 2013 16:47:09 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <5110256F.6000009@vaxination.ca> References: <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <5110256F.6000009@vaxination.ca> Message-ID: Exactly! On Mon, Feb 4, 2013 at 4:17 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > On 13-02-04 16:04, Scott Helms wrote: > > > Subscribers don't care if the hand off is at layer 1 or layer 2 so this > is > > moot as well. > > This is where one has to be carefull. The wholesale scenario in Canada > leaves indepdendant ISPs having to explain to their customers that they > can't fix certain problems and that they must call the telco/cableco to > get it fixed. (in the case of a certain cable company, they can't even > call them, it has to be done by email with response of at least 48 hours). > > So splitting responsabilities can be an annoyance if it becomes very > visible to the end users. > > Another aspect: customers espect to be able to switch seamlessly from > one ISP to the next. But ISP-2 can't take over from ISP-1 until ISP-1 > has relinquised control over the line to the end user. In a layer 1 > scenario, it means ISP-1 has to physically go and deinstall their CPE > and disconnect strand from their OLT, and then ISP-2 can do the reverse > and reconnect evrything to provide services. > > What happens when ISP-1 isn't interested in a quick disconnect and ISP-2 > has to wait days/weeks with end use without service ? > > > In a layer2 service, it is a matter of reconfiguring the OLT to pass > ethernet packets to a different VLAN to a different ISP. No physical > changes required and it can be almost tranparent to the end user who > just has to make a new DHCP request and be provisioned by ISP-2. > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From bross at pobox.com Mon Feb 4 21:58:19 2013 From: bross at pobox.com (Brandon Ross) Date: Mon, 4 Feb 2013 16:58:19 -0500 (EST) Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: References: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> <020901ce01d3$0da88c00$28f9a400$@iname.com> <004301ce0292$2b85c1b0$82914510$@iname.com> Message-ID: On Mon, 4 Feb 2013, Scott Helms wrote: > On Mon, Feb 4, 2013 at 4:14 PM, Brandon Ross wrote: > > There are tons and tons and tons of organizations that will sell the > operator of a network content to sell to that operator's subscribers > directly. Most well known is the cable coop, who only exists to do just > that. The problem is that what's been proposed is that the network > operator be able to then turn around and offer those services as a whole > sale level to another operator, on the same physical but not not layer 2, > plant. That's what I don't think you can get contracts inked for. How is that different from what the aggregators that I've already pointed out are doing? Why does anyone need to resell anything, anyway, what we are talking about are service providers connected to this muni fiber network being able to deliver triple play to their subs. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From khelms at zcorum.com Mon Feb 4 22:04:54 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 4 Feb 2013 17:04:54 -0500 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: References: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> <020901ce01d3$0da88c00$28f9a400$@iname.com> <004301ce0292$2b85c1b0$82914510$@iname.com> Message-ID: > > How is that different from what the aggregators that I've already pointed > out are doing? Why does anyone need to resell anything, anyway, what we > are talking about are service providers connected to this muni fiber > network being able to deliver triple play to their subs. Its not, that was kind of the point. What you're pointing out is NOT what I was saying is problematic. I work with companies that get there content from the coop or another aggregator every single day. This is fine and common as dirt: Video_content(from an aggregato or direct)--->Muni_operator-->End_user What I think Jay and some others were suggesting is: Video_content--->Muni_operator--->End_user AND/OR --->L1/L2 partner--->End_user That last bit where the content is being delivered to the customer of another operator that doesn't have a contract with either the content owner or an aggregator isn't (IMO) possible today. -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Mon Feb 4 22:09:19 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 4 Feb 2013 17:09:19 -0500 (EST) Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: Message-ID: <25512814.4942.1360015759010.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > There are tons and tons and tons of organizations that will sell the > operator of a network content to sell to that operator's subscribers > directly. Most well known is the cable coop, who only exists to do just > that. The problem is that what's been proposed is that the network > operator be able to then turn around and offer those services as a whole > sale level to another operator, on the same physical but not not layer > 2, plant. That's what I don't think you can get contracts inked for. I proposed it, and I immediately scratched the idea, when I found out that my notional ISP clients could themselves get it from such vendors to offer at retail. So we can stop trying to make that *particular* type of glue now. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mohta at necom830.hpcl.titech.ac.jp Mon Feb 4 22:28:27 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 05 Feb 2013 07:28:27 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: <5110256F.6000009@vaxination.ca> References: <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <5110256F.6000009@vaxination.ca> Message-ID: <5110360B.1030904@necom830.hpcl.titech.ac.jp> Jean-Francois Mezei wrote: > This is where one has to be carefull. The wholesale scenario in Canada > leaves indepdendant ISPs having to explain to their customers that they > can't fix certain problems and that they must call the telco/cableco to > get it fixed. (in the case of a certain cable company, they can't even > call them, it has to be done by email with response of at least 48 hours). > > So splitting responsabilities can be an annoyance if it becomes very > visible to the end users. No different from competing ISPs using DSL or PON. > Another aspect: customers espect to be able to switch seamlessly from > one ISP to the next. But ISP-2 can't take over from ISP-1 until ISP-1 > has relinquised control over the line to the end user. No different from competing ISPs using DSL or PON. > In a layer 1 > scenario, it means ISP-1 has to physically go and deinstall their CPE > and disconnect strand from their OLT, and then ISP-2 can do the reverse > and reconnect evrything to provide services. No. Just say optical MDF. > What happens when ISP-1 isn't interested in a quick disconnect and ISP-2 > has to wait days/weeks with end use without service ? You assume ISP-1 quickly stop servicing the end user, don't you? > In a layer2 service, it is a matter of reconfiguring the OLT to pass > ethernet packets to a different VLAN to a different ISP. No physical What happens when OLT operator isn't interested in a quick reconfiguration, ISP-1 quickly stop servicing the end user and ISP-2 has to wait days/weeks with end user without service? Masataka Ohta From jra at baylink.com Mon Feb 4 22:39:31 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 4 Feb 2013 17:39:31 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: <5110360B.1030904@necom830.hpcl.titech.ac.jp> Message-ID: <13407120.4948.1360017571290.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Masataka Ohta" > Jean-Francois Mezei wrote: > > So splitting responsabilities can be an annoyance if it becomes very > > visible to the end users. > > No different from competing ISPs using DSL or PON. Sure it is: competing ISPs in a traditional situation would be using each their own PHY. > > Another aspect: customers espect to be able to switch seamlessly from > > one ISP to the next. But ISP-2 can't take over from ISP-1 until ISP-1 > > has relinquised control over the line to the end user. > > No different from competing ISPs using DSL or PON. Sure it is: there it's *much worse*. > > In a layer 1 > > scenario, it means ISP-1 has to physically go and deinstall their > > CPE > > and disconnect strand from their OLT, and then ISP-2 can do the > > reverse > > and reconnect evrything to provide services. > > No. Just say optical MDF. Doesn't preclude the need to swap different models of ONTs. > > What happens when ISP-1 isn't interested in a quick disconnect and > > ISP-2 > > has to wait days/weeks with end use without service ? > > You assume ISP-1 quickly stop servicing the end user, don't you? I assume everyone will behave, because they're all *the customers of me, the municipality*, and they have a vested interest in being good actors. > > In a layer2 service, it is a matter of reconfiguring the OLT to pass > > ethernet packets to a different VLAN to a different ISP. No physical > > What happens when OLT operator isn't interested in a quick > reconfiguration, ISP-1 quickly stop servicing the end user > and ISP-2 has to wait days/weeks with end user without service? Again, *the city* is the OLT operator, in a L2 scenario, and I will flip the customer over almost immediately. Yes, I know subs will try to game things occasionally; we'll likely be able to cope with that. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mohta at necom830.hpcl.titech.ac.jp Mon Feb 4 22:56:50 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 05 Feb 2013 07:56:50 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: <13407120.4948.1360017571290.JavaMail.root@benjamin.baylink.com> References: <13407120.4948.1360017571290.JavaMail.root@benjamin.baylink.com> Message-ID: <51103CB2.5090606@necom830.hpcl.titech.ac.jp> Jay Ashworth wrote: >>> In a layer 1 >>> scenario, it means ISP-1 has to physically go and deinstall their >>> CPE >>> and disconnect strand from their OLT, and then ISP-2 can do the >>> reverse >>> and reconnect evrything to provide services. >> >> No. Just say optical MDF. > > Doesn't preclude the need to swap different models of ONTs. No different from competing ISPs using DSL or PON. >>> What happens when ISP-1 isn't interested in a quick disconnect and >>> ISP-2 >>> has to wait days/weeks with end use without service ? >> >> You assume ISP-1 quickly stop servicing the end user, don't you? > > I assume everyone will behave, because they're all *the customers of > me, the municipality*, and they have a vested interest in being good > actors. So, if the city is the MDF operator, L1 configuration should change almost immediately. > Again, *the city* is the OLT operator, in a L2 scenario, and I will > flip the customer over almost immediately. See above. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Mon Feb 4 22:58:22 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 05 Feb 2013 07:58:22 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> Message-ID: <51103D0E.4050905@necom830.hpcl.titech.ac.jp> Scott Helms wrote: >> Bot of you are wrong. >> >> There is no reason fiber is more expensive than copper, which means SS >> is cheap, as cheap as copper. > Copper isn't cheap, its just there already. Unbundled copper costs about $10/M or so, which means SS fiber can't be more expensive. > What is SS? Single star. > No, most of the cost isn't in running the cabling. Today most of the cost > is in lighting the fiber, though that varies on where you're running the > cabling and what gear you're using to light it. On page 11 of google slide, http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/36936.pdf it is stated that "Trenching consists of 70-80% of the total cost for infrastructure build". > PON is preferred by carriers because it works in their existing equipment Their existing equipment was SS copper and MDF. > Planning for a carrier network > is very different (different requirements) than for a greenfield muni > system. Surely, transition from copper to fiber is not trivial, but it helps a lot that fiber cables are thinner than copper cables. Masataka Ohta From khelms at zcorum.com Mon Feb 4 23:08:21 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 4 Feb 2013 18:08:21 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <51103D0E.4050905@necom830.hpcl.titech.ac.jp> References: <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> Message-ID: On Mon, Feb 4, 2013 at 5:58 PM, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > Scott Helms wrote: > > >> Bot of you are wrong. > >> > >> There is no reason fiber is more expensive than copper, which means SS > >> is cheap, as cheap as copper. > > > Copper isn't cheap, its just there already. > > Unbundled copper costs about $10/M or so, which means SS fiber > can't be more expensive. > Why is that? > > > What is SS? > > Single star. > I'm not sure what you're trying to describe here, the cost of fiber from an ongoing standpoint isn't strongly correlated to the architecture. Upgrades to the fiber and adding service to new areas is a different animal. > > > No, most of the cost isn't in running the cabling. Today most of the > cost > > is in lighting the fiber, though that varies on where you're running the > > cabling and what gear you're using to light it. > > On page 11 of google slide, > > > http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/pubs/archive/36936.pdf > > it is stated that "Trenching consists of 70-80% of the total cost > for infrastructure build". > Trenching != cabling and the total initial CAPEX is less than 25% of the total cost over 10 years. > > > PON is preferred by carriers because it works in their existing equipment > > Their existing equipment was SS copper and MDF. > No, their existing equipment was Adtran, Calix, Occam, Alcatel, Zhone, AFC, and a host of others but not SS copper or MDF. By MDF I assume your'e talking about main distribution frame which has nothing to do with the discussion here. > > > Planning for a carrier network > > is very different (different requirements) than for a greenfield muni > > system. > > Surely, transition from copper to fiber is not trivial, but it > helps a lot that fiber cables are thinner than copper cables. > Really, so you think that the thickness of the cable has an impact on how much it should cost? So, tell you what I'll exchange some nice thick 10 gauge copper wire for 4 gauge platinum, since its much thinner that ought to be a good trade for you, right? ;) > > Masataka Ohta > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Mon Feb 4 23:11:20 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 4 Feb 2013 18:11:20 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> Message-ID: > Really, so you think that the thickness of the cable has an impact on how > much it should cost? So, tell you what I'll exchange some nice thick > 10 gauge copper wire for > correction---> > 14 gauge platinum, since its much thinner that ought to be a good trade > for you, right? ;) > > >> >> -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From mohta at necom830.hpcl.titech.ac.jp Mon Feb 4 23:13:45 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 05 Feb 2013 08:13:45 +0900 Subject: Is Google Fiber a model for Municipal Networks? In-Reply-To: References: <20130203215226.GA53926@ussenterprise.ufp.org> <510FE9F8.6010409@necom830.hpcl.titech.ac.jp> Message-ID: <511040A9.3010409@necom830.hpcl.titech.ac.jp> Scott Helms wrote: >> The document, seemingly, does not address drop cable cost >> difference. >> >> It does not address L1 unbundling with WDM-PON, which >> requires fiber patch panel identical to that required >> for SS, either. > They're not doing WDM-PON or any flavor of PON at all. Its entirely an > Active Ethernet deployment. My point is that their comparison between SS and PON is insufficient. >> As for power consumption at CO, all the transmitters do not >> have to have power consuming LDs but can just have modulators >> to modulate light from a shared light source, which has already >> happened with QSFP+: > Masataka, are your trying to participate in the conversation or sell gear? My point is that form factor reduction by silicon photonics excludes LDs. > The laser used in your DVD player is NOT suitable for a broadband > deployment. Do you understand that QSFP+ is for 10G Ethernet? One or two (or three, maybe) shared light source in CO can have much better quality, which can be distributed to all the transmitters using splitters and EDFA, which does not consume a lot of power. Masataka Ohta From owen at delong.com Mon Feb 4 23:14:56 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Feb 2013 15:14:56 -0800 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: References: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> <020901ce01d3$0da88c00$28f9a400$@iname.com> <004301ce0292$2b85c1b0$82914510$@iname.com> Message-ID: <9D0C2E52-042D-4AFB-8462-6A210AD66DA2@delong.com> On Feb 4, 2013, at 13:46 , Scott Helms wrote: > Brandon, > > > On Mon, Feb 4, 2013 at 4:14 PM, Brandon Ross wrote: > >> On Mon, 4 Feb 2013, Scott Helms wrote: >> >> One thing to keep in mind is that I don't believe its possible to get a >>> contract with the bulk of the content owners in a wholesale scenario. >>> >> >> You do really need to read the thread before you post. >> > > There are tons and tons and tons of organizations that will sell the > operator of a network content to sell to that operator's subscribers > directly. Most well known is the cable coop, who only exists to do just > that. The problem is that what's been proposed is that the network > operator be able to then turn around and offer those services as a whole > sale level to another operator, on the same physical but not not layer 2, > plant. That's what I don't think you can get contracts inked for. > Actually, as I understood what was proposed, you would bring Cable Coop and/or other such vendors into the colo space adjacent to the MMR and let them sell directly to the other service providers and/or customers. Owen From mohta at necom830.hpcl.titech.ac.jp Mon Feb 4 23:29:41 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 05 Feb 2013 08:29:41 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> Message-ID: <51104465.6050606@necom830.hpcl.titech.ac.jp> Scott Helms wrote: >> Unbundled copper costs about $10/M or so, which means SS fiber >> can't be more expensive. > I'm not sure what you're trying to describe here, the cost of fiber from an > ongoing standpoint isn't strongly correlated to the architecture. Upgrades > to the fiber and adding service to new areas is a different animal. They are not soo different, as long as you try to recover initial cost not so quickly, which is why copper costs about $10/M or so. >> it is stated that "Trenching consists of 70-80% of the total cost >> for infrastructure build". > Trenching != cabling and the total initial CAPEX is less than 25% of the > total cost over 10 years. My statement of "cable laying" includes trenching, sorry if it is not clear. And, you can see the slide contain "POP Active Equipment Cost", which you thought "most of the cost is in lighting the fiber", is already included. > No, their existing equipment was Adtran, Calix, Occam, Alcatel, Zhone, AFC, > and a host of others but not SS copper or MDF. By MDF I assume your'e > talking about main distribution frame which has nothing to do with the > discussion here. If you throw away optical MDF, there is no point to discuss L1 unbundling. >> Surely, transition from copper to fiber is not trivial, but it >> helps a lot that fiber cables are thinner than copper cables. > Really, so you think that the thickness of the cable has an impact on how > much it should cost? So, tell you what I'll exchange some nice thick > 10 gauge copper wire for 4 gauge platinum, since its much thinner that > ought to be a good trade for you, right? ;) My point is that a conduit capable of storing additional 10 guage copper can, instead, store 10 guage fiber. Or, if you assume a conduit without any extra space, upgrading to PON is also impossible. Masataka Ohta From mpetach at netflight.com Mon Feb 4 23:31:35 2013 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 4 Feb 2013 15:31:35 -0800 Subject: 2013.02.04 NANOG57 day 1 afternoon notes Message-ID: Notes from the afternoon session, including the community meeting, but minus most of the BCOP presentation have been posted: http://kestrel3.netflight.com/2013.02.04-NANOG57-day1-afternoon-session.txt it looks like apache2 serves up about 100 connections, then wedges. :( No time to troubleshoot it, but i'll try to check back once an hour and kick it in the head. Thank you Dave, our hero of the day for making sure the WCIT talk contents did *not* get sealed behind closed doors! round two begins tomorrow morning, bright and early. ^_^ Matt From owen at delong.com Mon Feb 4 23:31:41 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Feb 2013 15:31:41 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> Message-ID: <8B3FD08C-AF80-45BD-9B1A-BB3ACABBE328@delong.com> On Feb 4, 2013, at 13:04 , Scott Helms wrote: > Owen, > > I'm trimming this for my own sanity if I snip out something important please let me know. > > > So long as you recognize that it's on a pair-by-pair basis end-to-end and not expecting any mixing/sharing/etc. by the L1 infrastructure provider, yes. > > OK good, now we're speaking on the same topic :) > > >> >>> >>> Is it more expensive to home-run every home than to put splitters in the neighborhood? Yes. Is it enough more expensive that the tradeoffs cannot be overcome? I remain unconvinced. >>> >>> >>> This completely depends on the area and the goals of the network. In most cases for muni networks back hauling everything is more expensive. >> >> I agree it's more expensive. The question is whether it's enough more expensive to make it infeasible. You still haven't come anywhere near addressing that question. >> >> I've said repeatedly that this a network by network analysis. I've never said its infeasible, but that it is more expensive both initially and long term in MOST installs. That by itself is generally enough to invalidate the design since in almost all cases there's no benefit to home running all the connections. It doesn't make the connection faster nor do ISPs (as a group) care about a layer 1 versus layer 2 hand off. > > That's where we disagree. The benefit is that: > > 1. It doesn't lock the entire area into a single current technology. > Neither does a ring architecture. > Yes it does... It locks you into whatever is supported on the ring. > 2. It allows for individual subscribers (probably mostly businesses, but I have had a few occasions > where this would have been useful as an individual) to get dark XC to other locations. > Neither does a ring architecture, you do have fewer long runs, but in any build you're going to end up with spare pairs to use for this and in my experience the number of businesses who want this in given area are very small. I can't think of a network where this is more than 1% of the business connections. That's because today, it's expensive and the price is usually way way way above cost-recovery (or, it's cost recovery of the build cost / n where n is a very small number of fibers). Lower the price per instance and you very likely find new demands. > > 3. Subscribers who want individualized services from different vendors have a choice. > > Subscribers don't care if the hand off is at layer 1 or layer 2 so this is moot as well. But the vendors do and it makes a huge difference to the barrier to entry price for competing vendors offering different services. (I'm talking about more than just IP at this point). > > 4. Providers have to compete on a leveled playing field and there is thus incentive to innovate > even if the innovation moves away from PON. > > Again, this is a completely moot point. There is nothing in a ring or hub & spoke architecture that makes open access more difficult EXCEPT if you want to share lots of L1 connections. What I'm proposing is a hub and spoke architecture. It's just a much larger hub with much longer spokes. > > >> >> >>> >>> >>> I'm not sure why you think it would be hard to delineate the responsibilities? You've got a fiber path maintained by the municipality with active equipment maintained by the ISP at each end. If the light coming out of the equipment at one end doesn't come out of the fiber at the other end, you have a problem in the municipality's domain. If the light makes it through in tact, you have a problem in the ISP's domain. >>> >>> There is equipment available that can test that fairly easily. >>> >>> OK, this one made my wife get scared I laughed so hard. You clearly have never tried to do this or had to work with different operators in the same physical network. Please, go talk to someone whose worked in the field of a FTTx network and describe this scenario to them. Its clear you don't want to hear it from me via email so please go do some research. >> >> >> I've talked to a few people doing exactly that. Yes, you need different test sets depending on which L2 gear is involved, but, in virtually ever case, there is a piece of test gear that can be used to test a loop independent of the configuration of the L2 gear in question. >> >> Yes, there is a meter for all the different kinds of technologies that you might want to support. For example a DOCSIS 3.0 DSAM from JDSU will run you around $8000.00 A PON meter with long range lasers (more than 10 miles) from JDSU or Trilithic will cost you nearly $10,000. Exactly how many of those kinds of meters do you want to have to buy? How many of your staff are you going to train on them (they do require training and knowledge to use)? > > For my proposed methods of build-out, no need for the long range lasers. As I said, everything should be within 8km of the MMR. > > As I suggested, the simpler approach is to require the complaining L2 provider to cooperate in the diagnostic process and provide access to the applicable meters if necessary. The standard offered absent assistance from the L2 provider is OTDR success. > > Medium range lasers (anything that's running on single mode fiber) versus long range don't drive the cost. OTDR is not and cannot test for any phase modulated system and that includes every form of PON, Active Ethernet, and RFoG. You _might_ be able to use one to test RS-232 over fiber depending on the vendor. This is where you're really not getting it. As the owner of the physical medium you WILL be the blame of every problem until you prove differently. Every end user install that goes poorly, every time there is a connection drop, and every time some end user of $L1 partner calls them complaining the city will get the blame. > You're assuming the current business model of incumbent-provider owned fiber. In a case where you have service providers not allowed to own fiber and a fiber provider not allowed to provide services, the incentives all work towards cooperation and the conflicts of interest between them are eliminated. I understand what you're saying about field technicians and their motivations, but, again those are based largely on the current business models and compensation schemes. In the proposed arena, there's no reason management at the service provider and management at the fiber provider cannot work together to address these issues. Further, the technician that blames the fiber plant for everything rather than cooperating to resolve said issues together will inherently have his installations take longer than the ones that cooperate, so he is actually already automatically incentivized in the correct direction. Admittedly, without some education, that may not be intuitively obvious to him, but I find that education is usually possible when attempted. >> For providers getting L1 service, it wouldn't be too hard to make this testing / providing necessary test equipment part of their contract. >>>> The long and short of it is lots of people have tried to L1 sharing and its not economical and nothing I've seen here or elsewhere changes that. The thing you have to remember is that muni networks have to be cost effective and that's not just the capital costs. The operational cost in the long term is much greater than the cost of initial gear and fiber install. >>>> >>> We can agree to disagree. A muni network needs to be able to recover its costs. The costs of building out and maintaining home-run >>> fiber are not necessarily that much greater than the costs of building out and maintaining fiber at the neighborhood. One option, for >>> example, would be to have neighborhood B-Boxes where the fiber can either be fed into provider-specific splitters (same economy >>> as existing PON deployments) or cross-connected to fiber on the F1 cable going back to the MMR (home-run). >>> >>> >>> We can agree all we want, that doesn't change history. Handing out connections at layer 1 is both more expensive and less efficient. Its also extremely wasteful (which is why its more expensive) since your lowest unit you can sell is a fiber strand whether the end customer wants a 3 mbps connection or a gig its the same to the city. I'm not saying you shouldn't sell dark fiber, I'm saying that in 99% of the cities you can't build a business model around doing just that unless your city doesn't want to break even on the build and maintenance. >> >> If it's $700 per home passed to build out home-run fibers (which seems to be a reasonable approximation from earlier discussions), then there's no reason you can't sell $40/month service over that where the L1 component is a $10/month ($7 for capital recovery, $3 for operations and support) pricing component. >> >> Nope, no reason at all if you don't care about covering your costs. > > I just explained where the expected costs get covered, so you're going to have to explain that statement. > > No, you listed some more than optimistic numbers and passed that off as evidence. If you seriously think that the fiber connection is only worth $10 per month then you're off by ~100%. Even if it's $20/month and you charge $50/month for L3 service and you're still in good shape. However, the real world numbers presented so far show costs closer to $10/month, so I'm not sure where your data is coming from. > > >> However, the point is that building the infrastructure in that manner doesn't cost much more than building out traditional PON infrastructure (if you're doing it from greenfield) and it can support either technology. >> >> Sure it does, even in greenfield and whats more it costs more over the long term UNLESS you know where every home and business will be located 10 years from now. > > More yes, much more, I'm not so convinced. > > You think the fiber connectivity is only worth $10 too.... $20/subscriber/month still strikes me as being within the realm of "not much more". So, based on your statement above... Owen > From owen at delong.com Mon Feb 4 23:34:33 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Feb 2013 15:34:33 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: <5110256F.6000009@vaxination.ca> References: <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <5110256F.600! 0009@vaxination.ca> Message-ID: <9D9AEE3E-7879-4541-900F-B70670DA1DBD@delong.com> On Feb 4, 2013, at 13:17 , Jean-Francois Mezei wrote: > On 13-02-04 16:04, Scott Helms wrote: > >> Subscribers don't care if the hand off is at layer 1 or layer 2 so this is >> moot as well. > > This is where one has to be carefull. The wholesale scenario in Canada > leaves indepdendant ISPs having to explain to their customers that they > can't fix certain problems and that they must call the telco/cableco to > get it fixed. (in the case of a certain cable company, they can't even > call them, it has to be done by email with response of at least 48 hours). > > So splitting responsabilities can be an annoyance if it becomes very > visible to the end users. > > Another aspect: customers espect to be able to switch seamlessly from > one ISP to the next. But ISP-2 can't take over from ISP-1 until ISP-1 > has relinquised control over the line to the end user. In a layer 1 > scenario, it means ISP-1 has to physically go and deinstall their CPE > and disconnect strand from their OLT, and then ISP-2 can do the reverse > and reconnect evrything to provide services. > Only if you insist on re-using the same strand. More likely in the proposed scenario, the customer is only using 1 of the 3 pairs of fiber to their prem. In such a case, just light the second strand with ISP-2 and ISP-1 can do their de-install at their leisure (or not). > What happens when ISP-1 isn't interested in a quick disconnect and ISP-2 > has to wait days/weeks with end use without service ? Nope. See above. > > > In a layer2 service, it is a matter of reconfiguring the OLT to pass > ethernet packets to a different VLAN to a different ISP. No physical > changes required and it can be almost tranparent to the end user who > just has to make a new DHCP request and be provisioned by ISP-2. > I agree this can be an advantage in some scenarios. That's one of the reasons I think allowing the muni to provide optional L2 aggregation services is worth while. Owen From khelms at zcorum.com Tue Feb 5 00:48:42 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 4 Feb 2013 19:48:42 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <51104465.6050606@necom830.hpcl.titech.ac.jp> References: <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> Message-ID: On Mon, Feb 4, 2013 at 6:29 PM, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > Scott Helms wrote: > > >> Unbundled copper costs about $10/M or so, which means SS fiber > >> can't be more expensive. > > > I'm not sure what you're trying to describe here, the cost of fiber from > an > > ongoing standpoint isn't strongly correlated to the architecture. > Upgrades > > to the fiber and adding service to new areas is a different animal. > > They are not soo different, as long as you try to recover initial > cost not so quickly, which is why copper costs about $10/M or so. > I know several dozen companies that do this kind of construction and they don't agree. > > >> it is stated that "Trenching consists of 70-80% of the total cost > >> for infrastructure build". > > > Trenching != cabling and the total initial CAPEX is less than 25% of the > > total cost over 10 years. > > My statement of "cable laying" includes trenching, sorry if it is > not clear. > > And, you can see the slide contain "POP Active Equipment Cost", > which you thought "most of the cost is in lighting the fiber", > is already included. > Google is making their own access gear. Their economy is very very different from all of us here. > > > No, their existing equipment was Adtran, Calix, Occam, Alcatel, Zhone, > AFC, > > and a host of others but not SS copper or MDF. By MDF I assume your'e > > talking about main distribution frame which has nothing to do with the > > discussion here. > > If you throw away optical MDF, there is no point to discuss > L1 unbundling. > OK, historically the main distribution frame was where all of the copper pairs came into a central office note that a phone company often had several central offices to cover their territory in the time before there were remotes (Digital Loop Carriers). Today even when you home run all of your fiber connections you bring it to a central patch panel(s) which really doesn't look like a main distribution frame. From a logical standpoint that central set of patch panels is similar to a MDF but I personally don't think about them the same way because a MDF is constructed very differently. (Google wire wraping telco tool) > > >> Surely, transition from copper to fiber is not trivial, but it > >> helps a lot that fiber cables are thinner than copper cables. > > > Really, so you think that the thickness of the cable has an impact on how > > much it should cost? So, tell you what I'll exchange some nice thick > > 10 gauge copper wire for 4 gauge platinum, since its much thinner that > > ought to be a good trade for you, right? ;) > > My point is that a conduit capable of storing additional 10 guage > copper can, instead, store 10 guage fiber. > > Or, if you assume a conduit without any extra space, upgrading to > PON is also impossible. > OK, twisted pair cabling isn't run in conduit. Its not pulled the way that fiber is. Twisted pair plant is in a wiring bundle with a certain number of pairs in that bundle. You cannot remove the twisted pair in whole or part and then run fiber through that cabling. You can of course use the same trench IF you have buried cable and there is room. If you have aerial plant (common in rural telco deployments, less common in muni networks) you can also string your fiber on the same poles that you either own or have attachment rights to but the thickness of the cable doesn't change your costs any. > > Masataka Ohta > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Tue Feb 5 01:05:23 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 4 Feb 2013 20:05:23 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <8B3FD08C-AF80-45BD-9B1A-BB3ACABBE328@delong.com> References: <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <8B3FD08C-AF80-45BD-9B1A-BB3ACABBE328@delong.com> Message-ID: >> That's where we disagree. The benefit is that: >> >> 1. It doesn't lock the entire area into a single current technology. >> > Neither does a ring architecture. > > > > Yes it does... It locks you into whatever is supported on the ring. > I don't know how I can explain this more plainly, I can (more accurately have) taken a fiber build that was created as a ring & spoke SONET system and with the same fiber plant overlaid that with GigE and ATM (further back in time) to backhaul for PON, DSL, VOIP, and direct Active Ethernet. There is nothing about a hub & spoke architecture is this harmful or even suboptimal for doing Gig-E directly to end users today. This wasn't always true because we've only had 40G and 100G Ethernet for carrier networks for a few years. In the past we were limited by how big of an etherchannel network we could use for the ring. I'd also point out that the ring architecture is optimal for redundancy since you have fewer fiber bundles to get cut in the field and any cut to your ring gets routed around the ring by ERPS (http://en.wikipedia.org/wiki/ERPS) in less than 50 milliseconds. > > 2. It allows for individual subscribers (probably mostly businesses, but >> I have had a few occasions >> where this would have been useful as an individual) to get dark XC to >> other locations. >> > Neither does a ring architecture, you do have fewer long runs, but in any > build you're going to end up with spare pairs to use for this and in my > experience the number of businesses who want this in given area are very > small. I can't think of a network where this is more than 1% of the > business connections. > > > That's because today, it's expensive and the price is usually way way way > above cost-recovery (or, it's cost > recovery of the build cost / n where n is a very small number of fibers). > > Lower the price per instance and you very likely find new demands. > The vast majority of business don't WANT that kind of connectivity. How many MPLS connections get purchased by SMBs? That's the same kind of connectivity at layer 3 and that's a market that is almost entirely used by large corportations. > > > >> 3. Subscribers who want individualized services from different vendors >> have a choice. >> > > Subscribers don't care if the hand off is at layer 1 or layer 2 so this is > moot as well. > > > But the vendors do and it makes a huge difference to the barrier to entry > price for competing > vendors offering different services. (I'm talking about more than just IP > at this point). > What vendors? ISPs don't. > > > >> 4. Providers have to compete on a leveled playing field and there is >> thus incentive to innovate >> even if the innovation moves away from PON. >> > > Again, this is a completely moot point. There is nothing in a ring or hub > & spoke architecture that makes open access more difficult EXCEPT if you > want to share lots of L1 connections. > > > What I'm proposing is a hub and spoke architecture. It's just a much > larger hub with much longer spokes. > That's called home running, but as I've said that's ok in some scenarios, its just that in most cases there is no benefit. > > > > >> >> >> >>> >>> >>> >>>> >>>> I'm not sure why you think it would be hard to delineate the >>>> responsibilities? You've got a fiber path maintained by the municipality >>>> with active equipment maintained by the ISP at each end. If the light >>>> coming out of the equipment at one end doesn't come out of the fiber at the >>>> other end, you have a problem in the municipality's domain. If the light >>>> makes it through in tact, you have a problem in the ISP's domain. >>>> >>>> There is equipment available that can test that fairly easily. >>>> >>> >>> OK, this one made my wife get scared I laughed so hard. You clearly >>> have never tried to do this or had to work with different operators in the >>> same physical network. Please, go talk to someone whose worked in the >>> field of a FTTx network and describe this scenario to them. Its clear you >>> don't want to hear it from me via email so please go do some research. >>> >>> >>> >>> I've talked to a few people doing exactly that. Yes, you need different >>> test sets depending on which L2 gear is involved, but, in virtually ever >>> case, there is a piece of test gear that can be used to test a loop >>> independent of the configuration of the L2 gear in question. >>> >> >> Yes, there is a meter for all the different kinds of technologies that >> you might want to support. For example a DOCSIS 3.0 DSAM from JDSU will >> run you around $8000.00 A PON meter with long range lasers (more than 10 >> miles) from JDSU or Trilithic will cost you nearly $10,000. Exactly how >> many of those kinds of meters do you want to have to buy? How many of your >> staff are you going to train on them (they do require training and >> knowledge to use)? >> >> >> For my proposed methods of build-out, no need for the long range lasers. >> As I said, everything should be within 8km of the MMR. >> >> As I suggested, the simpler approach is to require the complaining L2 >> provider to cooperate in the diagnostic process and provide access to the >> applicable meters if necessary. The standard offered absent assistance from >> the L2 provider is OTDR success. >> > > Medium range lasers (anything that's running on single mode fiber) versus > long range don't drive the cost. OTDR is not and cannot test for any phase > modulated system and that includes every form of PON, Active Ethernet, and > RFoG. You _might_ be able to use one to test RS-232 over fiber depending > on the vendor. This is where you're really not getting it. As the owner > of the physical medium you WILL be the blame of every problem until you > prove differently. Every end user install that goes poorly, every > time there is a connection drop, and every time some end user of $L1 > partner calls them complaining the city will get the blame. > > > You're assuming the current business model of incumbent-provider owned > fiber. In a case where you have service providers not allowed to own fiber > and a fiber provider not allowed to provide services, the incentives all > work towards cooperation and the conflicts of interest between them are > eliminated. I understand what you're saying about field technicians and > their motivations, but, again those are based largely on the current > business models and compensation schemes. In the proposed arena, there's no > reason management at the service provider and management at the fiber > provider cannot work together to address these issues. Further, the > technician that blames the fiber plant for everything rather than > cooperating to resolve said issues together will inherently have his > installations take longer than the ones that cooperate, so he is actually > already automatically incentivized in the correct direction. Admittedly, > without some education, that may not be intuitively obvious to him, but I > find that education is usually possible when attempted. > You need to understand that I've built the exact network your describing several times and in all those case this was for a muni network in a relatively small town (<25,000 residents). I also know who the installers are in that sized community (as a group, not personally) and even if you get the best ISP partners on the planet they're going to have normal installers doing much of the work. > > For providers getting L1 service, it wouldn't be too hard to make this >>> testing / providing necessary test equipment part of their contract. >>> >>> The long and short of it is lots of people have tried to L1 sharing and >>>> its not economical and nothing I've seen here or elsewhere changes that. >>>> The thing you have to remember is that muni networks have to be cost >>>> effective and that's not just the capital costs. The operational cost in >>>> the long term is much greater than the cost of initial gear and fiber >>>> install. >>>> >>>> We can agree to disagree. A muni network needs to be able to recover >>>> its costs. The costs of building out and maintaining home-run >>>> fiber are not necessarily that much greater than the costs of building >>>> out and maintaining fiber at the neighborhood. One option, for >>>> example, would be to have neighborhood B-Boxes where the fiber can >>>> either be fed into provider-specific splitters (same economy >>>> as existing PON deployments) or cross-connected to fiber on the F1 >>>> cable going back to the MMR (home-run). >>>> >>>> >>> We can agree all we want, that doesn't change history. Handing out >>> connections at layer 1 is both more expensive and less efficient. Its also >>> extremely wasteful (which is why its more expensive) since your lowest unit >>> you can sell is a fiber strand whether the end customer wants a 3 mbps >>> connection or a gig its the same to the city. I'm not saying you shouldn't >>> sell dark fiber, I'm saying that in 99% of the cities you can't build a >>> business model around doing just that unless your city doesn't want to >>> break even on the build and maintenance. >>> >>> >>> If it's $700 per home passed to build out home-run fibers (which seems >>> to be a reasonable approximation from earlier discussions), then there's no >>> reason you can't sell $40/month service over that where the L1 component is >>> a $10/month ($7 for capital recovery, $3 for operations and support) >>> pricing component. >>> >> >> Nope, no reason at all if you don't care about covering your costs. >> >> >> I just explained where the expected costs get covered, so you're going to >> have to explain that statement. >> > > No, you listed some more than optimistic numbers and passed that off as > evidence. If you seriously think that the fiber connection is only worth > $10 per month then you're off by ~100%. > > > Even if it's $20/month and you charge $50/month for L3 service and you're > still in good shape. However, the real world numbers presented so far show > costs closer to $10/month, so I'm not sure where your data is coming from. > This is about what it costs to provide physical layer connectivity with most wired technologies in rural and smaller suburban environments. (Interestingly it actually costs more for wireless networks, though that's specifically not "cellular" but rather fixed and nomadic BWA like WIMAX.) > > > > However, the point is that building the infrastructure in that manner >>> doesn't cost much more than building out traditional PON infrastructure (if >>> you're doing it from greenfield) and it can support either technology. >>> >> >> Sure it does, even in greenfield and whats more it costs more over the >> long term UNLESS you know where every home and business will be located 10 >> years from now. >> >> >> More yes, much more, I'm not so convinced. >> > > You think the fiber connectivity is only worth $10 too.... > > > $20/subscriber/month still strikes me as being within the realm of "not > much more". So, based on your statement above... > Build your economic model, that delta of $10 is a big deal when you look at thousands of connections. > > Owen > > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From drc at virtualized.org Tue Feb 5 02:09:39 2013 From: drc at virtualized.org (David Conrad) Date: Mon, 4 Feb 2013 18:09:39 -0800 Subject: 2013.02.04 NANOG57 day 1 afternoon notes In-Reply-To: References: Message-ID: <55107EB3-5DCA-4B8C-A295-4FF665A89377@virtualized.org> Matt, Thanks very much (as always) for the great notes! Extremely helpful. Regards, -drc On Feb 4, 2013, at 3:31 PM, Matthew Petach wrote: > Notes from the afternoon session, including > the community meeting, but minus most of > the BCOP presentation have been posted: > > http://kestrel3.netflight.com/2013.02.04-NANOG57-day1-afternoon-session.txt > > it looks like apache2 serves up about 100 > connections, then wedges. :( No time to > troubleshoot it, but i'll try to check back > once an hour and kick it in the head. > > Thank you Dave, our hero of the day for > making sure the WCIT talk contents did > *not* get sealed behind closed doors! > > round two begins tomorrow morning, bright > and early. ^_^ > > Matt > From mpetach at netflight.com Tue Feb 5 02:43:35 2013 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 4 Feb 2013 18:43:35 -0800 Subject: 2013.02.04 NANOG57 day 1 afternoon notes In-Reply-To: <55107EB3-5DCA-4B8C-A295-4FF665A89377@virtualized.org> References: <55107EB3-5DCA-4B8C-A295-4FF665A89377@virtualized.org> Message-ID: On Mon, Feb 4, 2013 at 6:09 PM, David Conrad wrote: > Matt, > > Thanks very much (as always) for the great notes! Extremely helpful. > > Regards, > -drc Glad they're useful--wish I could have been there, the social tomorrow night sounds like it will be absolutely stellar, in true Snowhorn fashion! :) Matt From serian.reg at gmail.com Tue Feb 5 04:06:41 2013 From: serian.reg at gmail.com (Abzal Sembay) Date: Tue, 05 Feb 2013 09:06:41 +0500 Subject: Metro Ethernet, VPLS clarifications Message-ID: <51108551.7090700@gmail.com> Hi experts, I need some clarifications on these terms. Could somebody give explanations or share some links? When and how are these technologies used? Thanks in advance. -- Regards, Abzal From jfmezei_nanog at vaxination.ca Tue Feb 5 06:08:38 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Tue, 05 Feb 2013 01:08:38 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> Message-ID: <5110A1E6.5080807@vaxination.ca> On 13-02-04 19:48, Scott Helms wrote: > same trench IF you have buried cable and there is room. If you have aerial > plant (common in rural telco deployments, less common in muni networks) you > can also string your fiber on the same poles that you either own or have > attachment rights to but the thickness of the cable doesn't change your > costs any. In Qu?bec, some poles are owned by the telco and some by the electric utility. They have a deal with each other to gain access to each other's poles. However, that deal still involves engineering studies to ensure the weight of wiring/equipment on poles is acceptable. And this is where stringning heavier 867 strand cable could possibly make a difference compared to stringing lighter 4 strands (or however how many are used for GPON systems between OLT and splitter). After the ice storm of 1998 here, they are a bit more careful about how much weight they put on poles. From sakamura at gmail.com Tue Feb 5 06:09:48 2013 From: sakamura at gmail.com (Ishmael Rufus) Date: Tue, 5 Feb 2013 00:09:48 -0600 Subject: List of Comcast speeds in Chicago, IL (North side near I-94: Addisson/Irving Park/ area) Message-ID: Could someone help verify the listed speeds for the different services for Comcast: Performance - 20mbps (Customer support is claiming it's now 15mbps) Blast - 30 mbps (Customer support is claiming it's now 20 mbps) I was getting 20+ download speed tests on Performance which is correct. When I told customer support I was getting half (because of packet loss) they brought this other information to my attention From paul4004 at gmail.com Tue Feb 5 06:19:27 2013 From: paul4004 at gmail.com (PC) Date: Mon, 4 Feb 2013 23:19:27 -0700 Subject: List of Comcast speeds in Chicago, IL (North side near I-94: Addisson/Irving Park/ area) In-Reply-To: References: Message-ID: The folks in the forums at dslreports.com are generally on top of this like a hawk and are probably a better resource than here. For what its worth, Comcast often provides temporary speed enhancements for the first so many bytes in x seconds, ("powerboost"), which can often throw off short flash-based speedtests. On Mon, Feb 4, 2013 at 11:09 PM, Ishmael Rufus wrote: > Could someone help verify the listed speeds for the different services > for Comcast: > > Performance - 20mbps (Customer support is claiming it's now 15mbps) > Blast - 30 mbps (Customer support is claiming it's now 20 mbps) > > I was getting 20+ download speed tests on Performance which is correct. > When I told customer support I was getting half (because of packet loss) > they brought this other information to my attention > From jerome at ceriz.fr Tue Feb 5 11:51:54 2013 From: jerome at ceriz.fr (=?UTF-8?B?SsOpcsO0bWUgTmljb2xsZQ==?=) Date: Tue, 05 Feb 2013 12:51:54 +0100 Subject: Muni fiber: L1 or L2? In-Reply-To: <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> References: <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> Message-ID: <5110F25A.1090500@ceriz.fr> Hi Jay, Le 29/01/2013 18:54, Jay Ashworth a ?crit : > Hmmm. I tend to be a Layer-2-available guy, cause I think it lets smaller > players play. Please let me present the french regulatory rules about that. It has been an ongoing debate for a few years and is now almost stable. French regulation has divided the territory in thow zones : dense and non-dense areas, dense beeing city centers wuth multi-tenant buildings. In both case, it is mandatory to install at least two point to point fibers between a residence and a patch-panel. In dense areas, building owners or home owner associations are to choose a "building operator" to install the fiber strands in the private areas and the patch panel made available to other service providers. This building operator then informs service provider of the location of the patch panel and provide a public offer to ISPs to either buy a strand or rent one, and get some space for their own patch chords in the panel. In non-dense areas, zone operators have to build concentration points (kind of MMRs) for at least 300 residences (when chaining MMRs) or 1000 residences (for a single MMR per zone). Theses MMRs often take the form of street cabinets or shelters and have to be equiped with power and cooling units to enable any ISP yo install active equipments (either OLT or ethernet switch). Building and zone operators can be public (muni-owned) infrastructure operators or public-owned corporations. We've also seen NFP associations applying for such roles. It is mandatory for them to provide a L1 point to point service to ISPs. Infrastructure operators can also provide a L2 service but are still required to offer L1 service to any willing ISP. In such case, collocation space in street cabinets (or the ability to install their own side by side with passive cabinets) is required. This model has been choosed because it lets both network types be deployed : either point to multipoint (GePON) or point to point is possible on any of these fiber networks, thanks to the local-loop (between residences and MMRs) beeing point to point only. Smaller ISPs usually go for L2 services, provided by the infrastructure operator or another ISP already present on site. But some tends to stick to L1 service and deply their own eqipments for many reasons. What comes to mind is the usual incompetence of infrastructure operators regarding to multicast services or maintenance-windows beeing too loose for most SLAs. Some ISPs also stick to P2P topologies because it's simplier to manage and brings less features in the network equipment. They strongly believe that a robust network is a stupid network (and I tend to agree with them, seeing many interoperability and scalability issues in P2MP network equipments). Now, about individual rights, civil liberties and constitutional vantage point, infrastructure operators can't operate a network without an L1 offer, and most also propose an L2 offer. Still, ISPs are the only enitites capable of identifying a user because the infrastructure operator don't have a contract with the end-user in any case. Therefore court orders are sent to ISPs and infrastructure operators ain't concerned. I hope it clarifies what's beeing done on actual fiber networks and how can this issue be regulated (either by common sense or law). Best regards, -- J?r?me Nicolle +33 6 19 31 27 14 From rs at seastrom.com Tue Feb 5 12:51:47 2013 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 05 Feb 2013 07:51:47 -0500 Subject: Muni network ownership and the Fourth In-Reply-To: <6174691.4734.1359902098206.JavaMail.root@benjamin.baylink.com> (Jay Ashworth's message of "Sun, 3 Feb 2013 09:34:58 -0500 (EST)") References: <6174691.4734.1359902098206.JavaMail.root@benjamin.baylink.com> Message-ID: <861ucu9b4s.fsf@seastrom.com> Jay Ashworth writes: >> Still, the power budget improvements by not going with a single strand >> active ethernet solution (which were another suggested technology and >> has actually been deployed by some muni PON folks like Clarkesville, >> TN) are huge. Imagine a 24 port switch that draws 100 watts. OK, >> that's 4w per customer. 30k customers from a served location, that's >> 120kw ($13k power bill if you had 100% efficient UPSes and 0 cost >> cooling, neither of which is true) just for the edge, not counting any >> aggregation devices or northbound switch gear. > > Hmm. the optics don't have auto power control? Auto power control would apply to launch levels for the light; assuming a launch level of -3 dBm and lasers that were only 1 percent efficient (combination of spec max launch power for LX optics and unrealistically crummy efficiency lasers) your total power budget for the laser is only 50 milliwatts out of that 4 watts - wrong place to look for power savings. The rest is taken up by stuff like the ethernet chip and supporting logic in the switch, inefficiencies in the power supply, etc. etc. >> Back at NN, we discounted this as a technology almost immediately >> based on energy efficiency alone. >> >> Anyway, in summary, for PON deployments the part that matters *is* a >> greenfield deployment and if the fiber plant is planned and scaled >> accordingly the cost differential is noise. > > I assume you mean "the cost diff between GPON plant and home-run plant"; > that's the answer I was hoping for. Close; I meant "the cost difference between a home run fiber architecture with centralized splitters for *PON and distributed splitters in the field is minimal, and one gains it back in future-proofing and avoiding forklift upgrades down the road". The question of where one puts the splitters (if any) is coupled to the PON vs. active ethernet question only insofar as AE doesn't need splitters - but assuming: * $10k/month cost differential for power in the scenario above * unity cost for head end equipment (almost certainly wrong) * a 16 way split ratio (worst case; you might get 24 or 32) * $100 apiece splitters (24 or 32 would be marginally more) * today's stupid-low cost of capital break-even point on the decision to go with a PON type of technology is still less than two years. If you have a customer who needs the whole pipe to himself (or next generation optics for 10g or 100g to the couch), with centralized splitters the solution is easy. You re-patch him with an attenuator instead of a splitter (or hook him to the new kit), re-range, and go to town. Of course you lose the power advantages of a PON architecture but those customers are the exception not the rule. -r From khelms at zcorum.com Tue Feb 5 14:58:51 2013 From: khelms at zcorum.com (Scott Helms) Date: Tue, 5 Feb 2013 09:58:51 -0500 Subject: Metro Ethernet, VPLS clarifications In-Reply-To: <51108551.7090700@gmail.com> References: <51108551.7090700@gmail.com> Message-ID: Metro-Ethernet is generally the term used to describe Ethernet used as a WAN connection or as a point to point connection. There was at one time the concept of a MAN (Metro Area Network) but "metro" ethernet is now available in more scenarios than that described. The connectivity can be over fiber or copper and the speed delivered can be as low as a few mbps but commercially available offerings normally start at 5-10 mbps. On the high end its possible to get gigabit and faster connections in certain areas. http://en.wikipedia.org/wiki/Metro_E VPLS stands for Virtual Private Lan Services. This an umbrella technology that allows for the bridging of layer 2 traffic across various layer 2 & 3 networks. This is generally used as a replacement for a point to point metro ethernet (or other) connection. http://en.wikipedia.org/wiki/VPLS On Mon, Feb 4, 2013 at 11:06 PM, Abzal Sembay wrote: > Hi experts, > > I need some clarifications on these terms. Could somebody give > explanations or share some links? > When and how are these technologies used? > > Thanks in advance. > > -- > Regards, > > Abzal > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From esseph at gmail.com Tue Feb 5 15:39:47 2013 From: esseph at gmail.com (Josh Reynolds) Date: Tue, 5 Feb 2013 09:39:47 -0600 Subject: L3 East cost maint / fiber 05FEB2012 maintenance Message-ID: I know a lot of you are out of the office right now, but does anybody have any info on what happened with L3 this morning? They went into a 5 hour maintenance window with expected downtime of about 30 minutes while they upgraded something like *40* of their "core routers" (their words), but also did this during some fiber work and completely cut off several of their east coast peers for the entirety of the 5 hour window. If anybody has any more info on this, on a NOC contact for them on the East Coast for future issues, you can hit me off off-list if you don't feel comfortable replying with that info here. Thanks, and I hope hope you guys are enjoying Orlando. -- *Josh Reynolds* esseph at gmail.com - (270) 302-3552 From viraviralh at gmail.com Tue Feb 5 15:48:16 2013 From: viraviralh at gmail.com (Viral Vira) Date: Tue, 5 Feb 2013 21:18:16 +0530 Subject: L3 East cost maint / fiber 05FEB2012 maintenance In-Reply-To: References: Message-ID: We also noticed outage due to L3 Maintenance that went into the outage. We were not even notified about the Maintenance itself. We also noticed black hauling in their network. -Thanks, Viral On 5 February 2013 21:09, Josh Reynolds wrote: > I know a lot of you are out of the office right now, but does anybody have > any info on what happened with L3 this morning? They went into a 5 hour > maintenance window with expected downtime of about 30 minutes while they > upgraded something like *40* of their "core routers" (their words), but > also did this during some fiber work and completely cut off several of > their east coast peers for the entirety of the 5 hour window. > > If anybody has any more info on this, on a NOC contact for them on the East > Coast for future issues, you can hit me off off-list if you don't feel > comfortable replying with that info here. > > Thanks, and I hope hope you guys are enjoying Orlando. > > -- > *Josh Reynolds* > esseph at gmail.com - (270) 302-3552 > From dhubbard at dino.hostasaurus.com Tue Feb 5 15:48:08 2013 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Tue, 5 Feb 2013 10:48:08 -0500 Subject: L3 East cost maint / fiber 05FEB2012 maintenance References: Message-ID: We saw the same thing out of their Tampa location; there was a brief drop around 2am EST and a more severe one around 4:05 AM which lasted about 10 minutes for us. Unfortunately whatever they did, they did it in a way that our BGP sessions stayed up so we couldn't react until bgpmon altered me about some route withdrawals but by that time things were back to normal and remained stable. > -----Original Message----- > From: Josh Reynolds [mailto:esseph at gmail.com] > Sent: Tuesday, February 05, 2013 10:40 AM > To: nanog at nanog.org > Subject: L3 East cost maint / fiber 05FEB2012 maintenance > > I know a lot of you are out of the office right now, but does > anybody have > any info on what happened with L3 this morning? They went > into a 5 hour > maintenance window with expected downtime of about 30 minutes > while they > upgraded something like *40* of their "core routers" (their > words), but > also did this during some fiber work and completely cut off several of > their east coast peers for the entirety of the 5 hour window. > > If anybody has any more info on this, on a NOC contact for > them on the East > Coast for future issues, you can hit me off off-list if you don't feel > comfortable replying with that info here. > > Thanks, and I hope hope you guys are enjoying Orlando. > > -- > *Josh Reynolds* > esseph at gmail.com - (270) 302-3552 > > From jlewis at lewis.org Tue Feb 5 15:51:22 2013 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 5 Feb 2013 10:51:22 -0500 (EST) Subject: L3 East cost maint / fiber 05FEB2012 maintenance In-Reply-To: References: Message-ID: On Tue, 5 Feb 2013, Josh Reynolds wrote: > I know a lot of you are out of the office right now, but does anybody have > any info on what happened with L3 this morning? They went into a 5 hour > maintenance window with expected downtime of about 30 minutes while they > upgraded something like *40* of their "core routers" (their words), but > also did this during some fiber work and completely cut off several of > their east coast peers for the entirety of the 5 hour window. > > If anybody has any more info on this, on a NOC contact for them on the East > Coast for future issues, you can hit me off off-list if you don't feel > comfortable replying with that info here. > > Thanks, and I hope hope you guys are enjoying Orlando. We're a Level3 customer in Orlando. Our BGP sessions stayed up, but the number of routes received from Level3 fell to only a few tens of thousands at about 4:10am, and gradually returned to normal numbers by about 4:35am. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From nick at flhsi.com Tue Feb 5 15:58:52 2013 From: nick at flhsi.com (Nick Olsen) Date: Tue, 5 Feb 2013 10:58:52 -0500 Subject: L3 East cost maint / fiber 05FEB2012 maintenance Message-ID: <5caae6f$ecb0588$4e780974$@flhsi.com> We saw the same here, However our session did tear down. I was told they were doing scheduled "emergency" maintenance about 3:30PM EST Yesterday. We're hung off the orlando market. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "David Hubbard" Sent: Tuesday, February 05, 2013 10:53 AM To: nanog at nanog.org Subject: RE: L3 East cost maint / fiber 05FEB2012 maintenance We saw the same thing out of their Tampa location; there was a brief drop around 2am EST and a more severe one around 4:05 AM which lasted about 10 minutes for us. Unfortunately whatever they did, they did it in a way that our BGP sessions stayed up so we couldn't react until bgpmon altered me about some route withdrawals but by that time things were back to normal and remained stable. > -----Original Message----- > From: Josh Reynolds [mailto:esseph at gmail.com] > Sent: Tuesday, February 05, 2013 10:40 AM > To: nanog at nanog.org > Subject: L3 East cost maint / fiber 05FEB2012 maintenance > > I know a lot of you are out of the office right now, but does > anybody have > any info on what happened with L3 this morning? They went > into a 5 hour > maintenance window with expected downtime of about 30 minutes > while they > upgraded something like *40* of their "core routers" (their > words), but > also did this during some fiber work and completely cut off several of > their east coast peers for the entirety of the 5 hour window. > > If anybody has any more info on this, on a NOC contact for > them on the East > Coast for future issues, you can hit me off off-list if you don't feel > comfortable replying with that info here. > > Thanks, and I hope hope you guys are enjoying Orlando. > > -- > *Josh Reynolds* > esseph at gmail.com - (270) 302-3552 > > From jason at lixfeld.ca Tue Feb 5 16:00:56 2013 From: jason at lixfeld.ca (Jason Lixfeld) Date: Tue, 5 Feb 2013 11:00:56 -0500 Subject: L3 East cost maint / fiber 05FEB2012 maintenance In-Reply-To: References: Message-ID: I got notification of their maintenance window, albeit with < 24 hours notice. Notice came in at 11:00GMT-5 yesterday, maintenance was scheduled for 00:00GMT-5 this morning. That said, the notice said that the maintenance was in Phoenix but I got a notice about my IPT circuit at 60 Hudson which I found confusing. Based on my logs, our BGP session with them went down at 03:06GMT-5 and back up at 03:15GMT-5. Down again at 03:37GMT-5 until 04:20GMT-5. A third time at 06:41GMT-5 and back at 06:45GMT-5. Traffic graphs tell a bit of a different story. Just before 05:00GMT-5, our outbound traffic to Level 3 dropped substantially. About that time, I started getting reports about issues to Level 3 destinations. Traces seemed to indicate a black hole condition within Level 3's network in NYC, seemingly at, or just past csw3.NewYork1.Level3.net. Stuff seemed to correct itself by about 06:45GMT-5, but due to Level 3 sending only about 180k routes. About 20 minutes later, the table was back to ~431K and all's been fine since. On 2013-02-05, at 10:39 AM, Josh Reynolds wrote: > I know a lot of you are out of the office right now, but does anybody have > any info on what happened with L3 this morning? They went into a 5 hour > maintenance window with expected downtime of about 30 minutes while they > upgraded something like *40* of their "core routers" (their words), but > also did this during some fiber work and completely cut off several of > their east coast peers for the entirety of the 5 hour window. > > If anybody has any more info on this, on a NOC contact for them on the East > Coast for future issues, you can hit me off off-list if you don't feel > comfortable replying with that info here. > > Thanks, and I hope hope you guys are enjoying Orlando. > > -- > *Josh Reynolds* > esseph at gmail.com - (270) 302-3552 From 2asx1y702 at sneakemail.com Tue Feb 5 16:06:54 2013 From: 2asx1y702 at sneakemail.com (2asx1y702 at sneakemail.com) Date: Tue, 5 Feb 2013 16:06:54 +0000 Subject: L3 East cost maint / fiber 05FEB2012 maintenance Message-ID: <28432-1360080414-224563@sneakemail.com> I acknowledge sliding past the maintenance window, and we're seeing similar bumps, 09:42 - 09:46 CST is most recent. This are with our Wisconsin and Netherlands locations. They seem to be having a bad day all around. KG Hi Andrey! From jra at baylink.com Tue Feb 5 16:08:56 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 5 Feb 2013 11:08:56 -0500 (EST) Subject: How far must muni fiber operators protect ISP competition? In-Reply-To: <9D0C2E52-042D-4AFB-8462-6A210AD66DA2@delong.com> Message-ID: <17782583.4960.1360080536557.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > Actually, as I understood what was proposed, you would bring Cable Coop > and/or other such vendors into the colo space adjacent to the MMR and > let them sell directly to the other service providers and/or > customers. I am of two minds at this point, on this topic. The goal of this project, lying just atop improving the city's position in the world, is to do so by making practical competition between service providers, to keep prices as low as possible. when I delve into the realm of things like this, some people could make a relatively defensible argument that I am disadvantaging ISPs who are smart enough to know about this sort of service on their own, by helping out those who are not. I'm not sure if that argument outweighs the opposing one, which is that I should be *trying* to advantage those smaller, less savvy operators, as they're the sort I want as providers. I think this particular point is one of opinion; I solicit such. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Tue Feb 5 16:12:06 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 5 Feb 2013 11:12:06 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: <51104465.6050606@necom830.hpcl.titech.ac.jp> Message-ID: <11063296.4962.1360080726381.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Masataka Ohta" > My point is that a conduit capable of storing additional 10 guage > copper can, instead, store 10 guage fiber. > > Or, if you assume a conduit without any extra space, upgrading to > PON is also impossible. Sure. My install will be greenfield, down to new conduit, so I may have different contstraints than other planners. I will, in fact, be over-sizing the conduit as well, and I'll offer space leasing to potential providers who want to go that far as well. But, since conduit space will be a much more limited quantity, it will cost quite a bit more to do it that way, even before you blow the fiber, than to lease my L1 or L2 services to the subs. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From uwcableguy at gmail.com Tue Feb 5 16:19:30 2013 From: uwcableguy at gmail.com (Ben Bartsch) Date: Tue, 5 Feb 2013 10:19:30 -0600 Subject: L3 East cost maint / fiber 05FEB2012 maintenance In-Reply-To: <28432-1360080414-224563@sneakemail.com> References: <28432-1360080414-224563@sneakemail.com> Message-ID: We lost our peering with them in Baton Rouge (Houston) but not in Jackson MS (Atlanta). It was less than 10 minutes. No advanced notification. On Tue, Feb 5, 2013 at 10:06 AM, <2asx1y702 at sneakemail.com> wrote: > I acknowledge sliding past the maintenance window, and we're seeing > similar bumps, 09:42 - 09:46 CST is most recent. This are with our > Wisconsin and Netherlands locations. They seem to be having a bad day all > around. > > KG > > Hi Andrey! > > From khelms at zcorum.com Tue Feb 5 16:21:11 2013 From: khelms at zcorum.com (Scott Helms) Date: Tue, 5 Feb 2013 11:21:11 -0500 Subject: How far must muni fiber operators protect ISP competition? In-Reply-To: <17782583.4960.1360080536557.JavaMail.root@benjamin.baylink.com> References: <9D0C2E52-042D-4AFB-8462-6A210AD66DA2@delong.com> <17782583.4960.1360080536557.JavaMail.root@benjamin.baylink.com> Message-ID: On the video side or the total data project? Both? On Tue, Feb 5, 2013 at 11:08 AM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Owen DeLong" > > > Actually, as I understood what was proposed, you would bring Cable Coop > > and/or other such vendors into the colo space adjacent to the MMR and > > let them sell directly to the other service providers and/or > > customers. > > I am of two minds at this point, on this topic. > > The goal of this project, lying just atop improving the city's position in > the world, is to do so by making practical competition between service > providers, to keep prices as low as possible. > > when I delve into the realm of things like this, some people could make > a relatively defensible argument that I am disadvantaging ISPs who are > smart enough to know about this sort of service on their own, by helping > out those who are not. > > I'm not sure if that argument outweighs the opposing one, which is that > I should be *trying* to advantage those smaller, less savvy operators, as > they're the sort I want as providers. > > I think this particular point is one of opinion; I solicit such. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Tue Feb 5 16:30:30 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 5 Feb 2013 11:30:30 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: Message-ID: <24791995.4964.1360081830800.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > > Yes it does... It locks you into whatever is supported on the ring. > > I don't know how I can explain this more plainly, I can (more accurately > have) taken a fiber build that was created as a ring & spoke SONET system > and with the same fiber plant overlaid that with GigE and ATM (further back > in time) to backhaul for PON, DSL, VOIP, and direct Active Ethernet. "Overlaid"? Could you clarify that? Owen's assertion (and mine) is that a loop architecture *requires* active equipment, suited to the phy layer protocol, at each node. And while those loop fibers are running SONET, they can't be running anything else at the same time. > There is nothing about a hub & spoke architecture is this harmful or even > suboptimal for doing Gig-E directly to end users today. You propose to run a ring *for each subscriber*? Or put active gear in the field to mux the subscriber AE loops into a SONET ring? Or some other approach I don't know it possible? > This wasn't always > true because we've only had 40G and 100G Ethernet for carrier networks for > a few years. In the past we were limited by how big of an etherchannel > network we could use for the ring. I'd also point out that the > ring architecture is optimal for redundancy since you have fewer fiber > bundles to get cut in the field and any cut to your ring gets routed around > the ring by ERPS (http://en.wikipedia.org/wiki/ERPS) in less than 50 > milliseconds. I infer from that continuation of your thought that you mean the second: active optical muxes out in the plant. I'm sure I've made clear why that design limits me in ways I don't want to be limited when building a fiber plant for a 50 year lifetime, but let's address your responses below. > > Lower the price per instance and you very likely find new demands. > > > > The vast majority of business don't WANT that kind of connectivity. The vast majority of businesses don't want it at the price they have to pay for it now -- or more to the point, the consultants who do their IT don't. You have no real way, I should think, to extrapolate whether that will continue as prices drop, especially if sharply. > How many MPLS connections get purchased by SMBs? That's the same kind of > connectivity at layer 3 and that's a market that is almost entirely > used by large corportations. Sure; most small businesses don't need that. But there are some that do, and there are some that it doesn't matter *where they are at*. "Fiber on your wall with no upfront engineering charge" is a pretty strong call, in some markets, and I won't have to do most of the publicity myself; it'll make the news. > > But the vendors do and it makes a huge difference to the barrier to entry > > price for competing > > vendors offering different services. (I'm talking about more than > > just IP at this point). > > What vendors? ISPs don't. And your assertion here is based on what? How many places have ISPs had a *choice* as to whether to take a L1 optical or L2 aggregated handoff? > > What I'm proposing is a hub and spoke architecture. It's just a much > > larger hub with much longer spokes. > > That's called home running, but as I've said that's ok in some > scenarios, its just that in most cases there is no benefit. Today. Neither you nor I know how that will change in 20, 30, or 50 years. But that's the horizon I'm planning not to block. > > You're assuming the current business model of incumbent-provider owned > > fiber. In a case where you have service providers not allowed to own fiber > > and a fiber provider not allowed to provide services, the incentives all > > work towards cooperation and the conflicts of interest between them are > > eliminated. I understand what you're saying about field technicians and > > their motivations, but, again those are based largely on the current > > business models and compensation schemes. In the proposed arena, there's no > > reason management at the service provider and management at the fiber > > provider cannot work together to address these issues. Further, the > > technician that blames the fiber plant for everything rather than > > cooperating to resolve said issues together will inherently have his > > installations take longer than the ones that cooperate, so he is actually > > already automatically incentivized in the correct direction. This is my goal. > > Admittedly, > > without some education, that may not be intuitively obvious to him, > > but I find that education is usually possible when attempted. > > You need to understand that I've built the exact network your describing > several times and in all those case this was for a muni network in a > relatively small town (<25,000 residents). I also know who the installers > are in that sized community (as a group, not personally) and even if > you get the best ISP partners on the planet they're going to have normal > installers doing much of the work. When you say "normal installers", do you mean "employees of the ISP", "employees of the muni", or "subcontractors of one of those two"? And why is that pertinent? Your assertion seems to be that it will be necessary to have "abnormal" installers in the field in order for them not to dump problem tickets off to the muni and fail to help meaningfully in fixing them. First, I think this unlikely since, in most cases, we'll have 3pr available at each address. If we think there's a problem with the pair, we can "cut to clear" *temporarily*, and if the second pair is ok, then the sub is back online while we test the first pair and clear the problem. (GTE's failure, for all that I give them shit about CtC is that they never *worked* the dead pairs; as long as you do, it's not a problem.) Second, since we'll be terminating all 3 pairs to a jackbox, the installation contractor will be able to perform and document whatever acceptance testing we instruct them to. Sure, that will cost some more money, but again, if your capital plant is tested good when installed, this reduces markedly the opex maintenance cost over time. Where that breakeven point will be depends on what they want to charge me to do the testing, just as it does with Cat6. [ Scott: ] > >> Sure it does, even in greenfield and whats more it costs more over the > >> long term UNLESS you know where every home and business will be located 10 > >> years from now. A luxury I do have, since my city is nearly 100.0% built; it's certainly 100% platted. [ Owen: ] > >> More yes, much more, I'm not so convinced. And Owen isn't the only one who thinks that, and I think I know Rob Seastrom well enough from the list to think he wouldn't concur unless he had some data from which to work. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Tue Feb 5 16:32:25 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 5 Feb 2013 11:32:25 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: <5110F25A.1090500@ceriz.fr> Message-ID: <24344317.4966.1360081945461.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "J?r?me Nicolle" > Le 29/01/2013 18:54, Jay Ashworth a ?crit : > > Hmmm. I tend to be a Layer-2-available guy, cause I think it lets > > smaller players play. > > Please let me present the french regulatory rules about that. It has > been an ongoing debate for a few years and is now almost stable. [ ... ] > Infrastructure operators can also provide a L2 service but are still > required to offer L1 service to any willing ISP. In such case, > collocation space in street cabinets (or the ability to install their > own side by side with passive cabinets) is required. > > This model has been choosed because it lets both network types be > deployed : either point to multipoint (GePON) or point to point is > possible on any of these fiber networks, thanks to the local-loop > (between residences and MMRs) beeing point to point only. > > Smaller ISPs usually go for L2 services, provided by the infrastructure > operator or another ISP already present on site. But some tends to stick > to L1 service and deply their own eqipments for many reasons. Hmmm. Sounds familiar, Jerome. :-) How is it working out in practice, since it's within about 10% of what I proposed to do? Are there any public numbers we can look at? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Tue Feb 5 16:39:03 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 5 Feb 2013 11:39:03 -0500 (EST) Subject: Muni network ownership and the Fourth In-Reply-To: <861ucu9b4s.fsf@seastrom.com> Message-ID: <25374024.4970.1360082343786.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Robert E. Seastrom" > > Hmm. the optics don't have auto power control? > > Auto power control would apply to launch levels for the light; > assuming a launch level of -3 dBm and lasers that were only 1 percent > efficient (combination of spec max launch power for LX optics and > unrealistically crummy efficiency lasers) your total power budget for > the laser is only 50 milliwatts out of that 4 watts - wrong place to > look for power savings. The rest is taken up by stuff like the > ethernet chip and supporting logic in the switch, inefficiencies in > the power supply, etc. etc. Ah. Didn't realize that was the split. > >> Anyway, in summary, for PON deployments the part that matters *is* a > >> greenfield deployment and if the fiber plant is planned and scaled > >> accordingly the cost differential is noise. > > > > I assume you mean "the cost diff between GPON plant and home-run > > plant"; that's the answer I was hoping for. > > Close; I meant "the cost difference between a home run fiber > architecture with centralized splitters for *PON and distributed > splitters in the field is minimal, and one gains it back in > future-proofing and avoiding forklift upgrades down the road". I believe that's the same assertion, yes. :-) > The question of where one puts the splitters (if any) is coupled to > the PON vs. active ethernet question only insofar as AE doesn't need > splitters - but assuming: > > * $10k/month cost differential for power in the scenario above > * unity cost for head end equipment (almost certainly wrong) > * a 16 way split ratio (worst case; you might get 24 or 32) > * $100 apiece splitters (24 or 32 would be marginally more) > * today's stupid-low cost of capital > > break-even point on the decision to go with a PON type of technology > is still less than two years. Well, some of it is how many access chassis you need to sink the ports; Calix, for example, can do 480 ports per 10U at AE, but ... well, they say >10k ports, but since each card is 8-GPON (x 16 subs), that's 128 * 20, which is 2560, so I have to assume they're quoting 64x GPON, which people are telling me isn't actually practical. Just the capital cost, though, of 20 chassis vs 1 or 2 is really notable, at the prices those things go for. > If you have a customer who needs the whole pipe to himself (or next > generation optics for 10g or 100g to the couch), with centralized > splitters the solution is easy. You re-patch him with an attenuator > instead of a splitter (or hook him to the new kit), re-range, and go > to town. Of course you lose the power advantages of a PON > architecture but those customers are the exception not the rule. Sure. Unless, as we've been discussing, an ISP comes to town who has all their kit pre-designed and trained, and wants to do one or the other. (My underlying assumptions are in the "rollup" posts I put out on Friday, if you missed it.) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From alh-ietf at tndh.net Tue Feb 5 16:43:09 2013 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 5 Feb 2013 08:43:09 -0800 Subject: How far must muni fiber operators protect ISP competition? In-Reply-To: <17782583.4960.1360080536557.JavaMail.root@benjamin.baylink.com> References: <9D0C2E52-042D-4AFB-8462-6A210AD66DA2@delong.com> <17782583.4960.1360080536557.JavaMail.root@benjamin.baylink.com> Message-ID: <020a01ce03bf$e1a81910$a4f84b30$@tndh.net> IMHO: level of clue is a minor point, as that can be bought. The fundamental issues for a project like this are funding, and intent. Well-funded organizations that lack intent are just problem children that like to tie up the courts to keep others from making progress. The target for a project like you describe is the organization with intent, but lacks funding. Yes some of those will have an easier time by not having to acquire the appropriate level of clue, but they may not last long if they don't. Part of your calculation has to be level of churn you are willing to impose on the city as the low-price competitors come and go. Tony > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: Tuesday, February 05, 2013 8:09 AM > To: NANOG > Subject: How far must muni fiber operators protect ISP competition? > > ----- Original Message ----- > > From: "Owen DeLong" > > > Actually, as I understood what was proposed, you would bring Cable > > Coop and/or other such vendors into the colo space adjacent to the MMR > > and let them sell directly to the other service providers and/or > > customers. > > I am of two minds at this point, on this topic. > > The goal of this project, lying just atop improving the city's position in the > world, is to do so by making practical competition between service providers, > to keep prices as low as possible. > > when I delve into the realm of things like this, some people could make a > relatively defensible argument that I am disadvantaging ISPs who are smart > enough to know about this sort of service on their own, by helping out those > who are not. > > I'm not sure if that argument outweighs the opposing one, which is that I > should be *trying* to advantage those smaller, less savvy operators, as > they're the sort I want as providers. > > I think this particular point is one of opinion; I solicit such. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Tue Feb 5 16:48:58 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 5 Feb 2013 11:48:58 -0500 (EST) Subject: How far must muni fiber operators protect ISP competition? In-Reply-To: Message-ID: <30628727.4976.1360082938016.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > On the video side or the total data project? Both? "The point of open fiber is to level the competitive marketplace as much as possible for provider. Which approach better services that goal: telling them all about all the providers who might make their services more complete, or not doing so?" Whether we provide shared space, treating such providers as other clients, and tying them all through an IX switch, is a subsidiary issue. Cheers -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Tue Feb 5 16:51:03 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 5 Feb 2013 11:51:03 -0500 (EST) Subject: How far must muni fiber operators protect ISP competition? In-Reply-To: <020a01ce03bf$e1a81910$a4f84b30$@tndh.net> Message-ID: <5160761.4978.1360083063026.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Tony Hain" > IMHO: level of clue is a minor point, as that can be bought. The > fundamental issues for a project like this are funding, and intent. > Well-funded organizations that lack intent are just problem children > that like to tie up the courts to keep others from making progress. > The target for a project like you describe is the organization with > intent, but lacks funding. Yes some of those will have an easier time > by not having to acquire the appropriate level of clue, but they may > not last long if they don't. Part of your calculation has to be level > of churn you are willing to impose on the city as the low-price > competitors come and go. So you're saying I *should* provide all comers with the research in question, and deal with shared IX access right up front, even if that means I have multiple providers offering the same good as separate retailers... in the service of avoiding provider churn? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jof at thejof.com Tue Feb 5 17:23:22 2013 From: jof at thejof.com (Jonathan Lassoff) Date: Tue, 5 Feb 2013 09:23:22 -0800 Subject: L3 East cost maint / fiber 05FEB2012 maintenance In-Reply-To: References: Message-ID: My hunch is that this is fallout and repairs from Juniper PR839412. Only fix is an upgrade. Not sure why they're not able to do a hitless upgrade though; that's unfortunate. Specially-crafted TCP packets that can get past RE/loopback filters can crash the box. --j On Tue, Feb 5, 2013 at 7:39 AM, Josh Reynolds wrote: > I know a lot of you are out of the office right now, but does anybody have > any info on what happened with L3 this morning? They went into a 5 hour > maintenance window with expected downtime of about 30 minutes while they > upgraded something like *40* of their "core routers" (their words), but > also did this during some fiber work and completely cut off several of > their east coast peers for the entirety of the 5 hour window. > > If anybody has any more info on this, on a NOC contact for them on the East > Coast for future issues, you can hit me off off-list if you don't feel > comfortable replying with that info here. > > Thanks, and I hope hope you guys are enjoying Orlando. > > -- > *Josh Reynolds* > esseph at gmail.com - (270) 302-3552 From jason at biel-tech.com Tue Feb 5 17:33:48 2013 From: jason at biel-tech.com (Jason Biel) Date: Tue, 5 Feb 2013 11:33:48 -0600 Subject: L3 East cost maint / fiber 05FEB2012 maintenance In-Reply-To: References: Message-ID: Workaround is proper filtering and other techniques on the RE/Loopback to prevent the issue from happening. Should an upgrade be performed? Yes, but certainly doesn't have to have right away or without notice to customers. On Tue, Feb 5, 2013 at 11:23 AM, Jonathan Lassoff wrote: > My hunch is that this is fallout and repairs from Juniper PR839412. > Only fix is an upgrade. Not sure why they're not able to do a hitless > upgrade though; that's unfortunate. > > Specially-crafted TCP packets that can get past RE/loopback filters > can crash the box. > > --j > > On Tue, Feb 5, 2013 at 7:39 AM, Josh Reynolds wrote: > > I know a lot of you are out of the office right now, but does anybody > have > > any info on what happened with L3 this morning? They went into a 5 hour > > maintenance window with expected downtime of about 30 minutes while they > > upgraded something like *40* of their "core routers" (their words), but > > also did this during some fiber work and completely cut off several of > > their east coast peers for the entirety of the 5 hour window. > > > > If anybody has any more info on this, on a NOC contact for them on the > East > > Coast for future issues, you can hit me off off-list if you don't feel > > comfortable replying with that info here. > > > > Thanks, and I hope hope you guys are enjoying Orlando. > > > > -- > > *Josh Reynolds* > > esseph at gmail.com - (270) 302-3552 > > -- Jason From khelms at zcorum.com Tue Feb 5 17:37:57 2013 From: khelms at zcorum.com (Scott Helms) Date: Tue, 5 Feb 2013 12:37:57 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <24791995.4964.1360081830800.JavaMail.root@benjamin.baylink.com> References: <24791995.4964.1360081830800.JavaMail.root@benjamin.baylink.com> Message-ID: On Tue, Feb 5, 2013 at 11:30 AM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Scott Helms" > > > > Yes it does... It locks you into whatever is supported on the ring. > > > > I don't know how I can explain this more plainly, I can (more accurately > > have) taken a fiber build that was created as a ring & spoke SONET system > > and with the same fiber plant overlaid that with GigE and ATM (further > back > > in time) to backhaul for PON, DSL, VOIP, and direct Active Ethernet. > > "Overlaid"? Could you clarify that? > Sure, ring, hub & spoke, home run, star these are all descriptions of the physical architecture and many layer 2 technologies will happily use them all including Ethernet. To use a specific example an existing SONET ring (OC-3 to be precise) had be in service with an ILEC for more than a decade. This physical topology was a common one with a physical ring of fiber (32 strands, yes this was built back in the day) connected to Add/Drop Multiplexers (Fujitsu IIRC) along the ring as needed to deliver 25,000 or shorter copper loops either directly from the same cabinet that ADM was in or from a subtended Digital Loop Carrier off of a spur (collapsed ring) of the ring. Now, SONET connections work off a pair of fibers, one for transmit and one for receive. To run Ethernet (initially 100mbps but now 10G) we simply lit 2 of the remaining 30 strands to overlay an Ethernet ring on top of the SONET ring. We then placed switches in the same remote cabinets we had the ADMs and DLCs and started trenching the fiber drops. > > Owen's assertion (and mine) is that a loop architecture *requires* active > equipment, suited to the phy layer protocol, at each node. And while those > loop fibers are running SONET, they can't be running anything else at the > same time. > You're confounding the physical layer topology with the layer 2 protocol. You can't run SONET and Ethernet on the same physical fiber at the same time (unless you use WDM but that's confusing the discussion) but you'd never build a ring of fiber with only two strands. > > > There is nothing about a hub & spoke architecture is this harmful or even > > suboptimal for doing Gig-E directly to end users today. > > You propose to run a ring *for each subscriber*? Or put active gear in > the field to mux the subscriber AE loops into a SONET ring? > > Or some other approach I don't know it possible? > SONET is simply the legacy (and expensive) way that telco's used to build rings. I'd neither use it nor recommend it for much of anything today. Calix, Occam(also Calix now), Adtran, and all the other guys who play in this space will happily construct a Gig/10G/40G Ethernet ring in the same shelf you're going to be buying to put your GPON or AE line cards in. > > > This wasn't > always > > true because we've only had 40G and 100G Ethernet for carrier networks > for > > a few years. In the past we were limited by how big of an etherchannel > > network we could use for the ring. I'd also point out that the > > ring architecture is optimal for redundancy since you have fewer fiber > > bundles to get cut in the field and any cut to your ring gets routed > around > > the ring by ERPS (http://en.wikipedia.org/wiki/ERPS) in less than 50 > > milliseconds. > > I infer from that continuation of your thought that you mean the second: > active optical muxes out in the plant. > > I'm sure I've made clear why that design limits me in ways I don't want > to be limited when building a fiber plant for a 50 year lifetime, but let's > address your responses below. > The only limitation you have is a limited supply of total fibers (hint, this is a big reason why its cheaper to build and run). > > > > Lower the price per instance and you very likely find new demands. > > > > > > > The vast majority of business don't WANT that kind of connectivity. > > The vast majority of businesses don't want it at the price they have to > pay for it now -- or more to the point, the consultants who do their IT > don't. > > You have no real way, I should think, to extrapolate whether that will > continue as prices drop, especially if sharply. > The vast majority of businesses don't know and don't care about HOW their connectivity is delivered and wouldn't know the difference between Layer 1 and Layer 2 if it punched them in the face. Almost all businesses want INTERNET connectivity at the highest quality & speed at the lowest cost and that's it. There are a small percentage, mainly larger businesses, that do have special requirements, but those special requirements very seldom include a L1 anything. > > > How many MPLS connections get purchased by SMBs? That's the same kind of > > connectivity at layer 3 and that's a market that is almost entirely > > used by large corportations. > > Sure; most small businesses don't need that. > Nor medium businesses, and that's where knowing your (potential) customer base matters more than anything I can tell you. If you're in an area with lots of technology jobs and/or financial companies your network will look differently than an average small town muni build. If your customer base is primarily residential with a few businesses (hospitals and schools also count here) then you'll be lucky to sell a handful of L1 connections and some of the people who will be interested will want it for very low bit rate (means low price too) uses like RS-232 over fiber for managing SCADA nodes or other telemetry pieces. > > But there are some that do, and there are some that it doesn't matter > *where they are at*. "Fiber on your wall with no upfront engineering > charge" is a pretty strong call, in some markets, and I won't have to > do most of the publicity myself; it'll make the news. > You'll get some publicity, especially if you do a little self promoting. The problem I see is that you seem to think that by building the L1 piece you're going to have ISPs that are eager to serve your customers. If your demographics are like most small towns in the US that just isn't very likely. Any ISP partner is going to have to build and maintain a lot of infrastructure before they can serve the first end user and your "no upfront engineering" is simply not true unless you're going to configure and run MetroE and/or GPON shelves for them. In any sharing scenario (L1, L2, or L3) the ISP is going to have to connect to you with enough bandwidth to serve those end users as well. How many service providers have expressed interest? Have you talked pricing for the loops and colo space yet? > > > > > But the vendors do and it makes a huge difference to the barrier to > entry > > > price for competing > > > vendors offering different services. (I'm talking about more than > > > just IP at this point). > > > > What vendors? ISPs don't. > > And your assertion here is based on what? How many places have ISPs > had a *choice* as to whether to take a L1 optical or L2 aggregated handoff? > > I've done nothing but work with ISPs, often in the situation you're describing, for the past 15 years. I also know how ISPs, especially at the size you might attract operate. > > > What I'm proposing is a hub and spoke architecture. It's just a much > > > larger hub with much longer spokes. > > > > That's called home running, but as I've said that's ok in some > > scenarios, its just that in most cases there is no benefit. > > Today. Neither you nor I know how that will change in 20, 30, or 50 > years. But that's the horizon I'm planning not to block. > You're betting money against Ethernet's (not to mention any new technology) ability to keep up as a technology. You're statement is true, but its a lot like buying insurance against meteor strikes. Today on a normal ring topology most people are installing hundreds of pairs of physical fiber so even without adding Wave Division Multiplexing in you can easily build a ring with several terabits per second capacity. Even easier(and cheaper) is to build several 10G rings on top of each other with the exact same shelves you're going to be using to push out GPON or AE. > > > > You're assuming the current business model of incumbent-provider owned > > > fiber. In a case where you have service providers not allowed to own > fiber > > > and a fiber provider not allowed to provide services, the incentives > all > > > work towards cooperation and the conflicts of interest between them are > > > eliminated. I understand what you're saying about field technicians and > > > their motivations, but, again those are based largely on the current > > > business models and compensation schemes. In the proposed arena, > there's no > > > reason management at the service provider and management at the fiber > > > provider cannot work together to address these issues. Further, the > > > technician that blames the fiber plant for everything rather than > > > cooperating to resolve said issues together will inherently have his > > > installations take longer than the ones that cooperate, so he is > actually > > > already automatically incentivized in the correct direction. > > This is my goal. > > Its an admirable goal, but you're never going to have CCIEs (probably not even CCNAs) doing installs. Installation is, has been, and will in all likelihood continue to be done by people with limited skill sets. You building your own fiber plant and making it easier for ISPs to connect isn't going to change that. > > > Admittedly, > > > without some education, that may not be intuitively obvious to him, > > > but I find that education is usually possible when attempted. > > > > You need to understand that I've built the exact network your describing > > several times and in all those case this was for a muni network in a > > relatively small town (<25,000 residents). I also know who the installers > > are in that sized community (as a group, not personally) and even if > > you get the best ISP partners on the planet they're going to have normal > > installers doing much of the work. > > When you say "normal installers", do you mean "employees of the ISP", > "employees of the muni", or "subcontractors of one of those two"? > > And why is that pertinent? > Whoever does the install at the home or office. Who they work for really doesn't matter since the skill set will be largely the same. Its pertinent because you can have the greatest plant on the planet but if your install isn't done correctly the end user (the guy paying you or your partner) won't be happy. The majority of your day to day problems will be driven by installs. The fiber was improperly terminated, the drop was in the wrong place, the ONT didn't work correctly, etc. Please, go join the LinkedIn FTTx group and read some of the things there: You probably can't follow that link until you join but its a good discussion of some of the problems. http://www.linkedin.com/groupItem?view=&gid=83578&type=member&item=208400553&qid=379425dd-6f05-4caa-b2d4-f4fbf2aeb9cc&trk=group_most_popular-0-b-ttl&goback=%2Egmp_83578 > > Your assertion seems to be that it will be necessary to have "abnormal" > installers in the field in order for them not to dump problem tickets > off to the muni and fail to help meaningfully in fixing them. > > First, I think this unlikely since, in most cases, we'll have 3pr available > at each address. If we think there's a problem with the pair, we can > "cut to clear" *temporarily*, and if the second pair is ok, then the sub > is back online while we test the first pair and clear the problem. > > (GTE's failure, for all that I give them shit about CtC is that they never > *worked* the dead pairs; as long as you do, it's not a problem.) > That's great, and I'm glad to hear you've worked out that part of the drop but most of the problems occur from the drop into the house or office. The last 20 yards are the most problematic and most changed. This is where the installer matters most and why even good plant has bad installs. > > Second, since we'll be terminating all 3 pairs to a jackbox, the > installation contractor will be able to perform and document whatever > acceptance testing we instruct them to. Sure, that will cost some > more money, but again, if your capital plant is tested good when installed, > this reduces markedly the opex maintenance cost over time. Where that > breakeven point will be depends on what they want to charge me to do the > testing, just as it does with Cat6. > > [ Scott: ] > > >> Sure it does, even in greenfield and whats more it costs more over the > > >> long term UNLESS you know where every home and business will be > located 10 > > >> years from now. > > A luxury I do have, since my city is nearly 100.0% built; it's certainly > 100% platted. > > That's good, and again my argument isn't that you shouldn't home run all your connections, but rather using the idea of L1 handoffs as a reason to do so is flawed and that hub and spoke does not limit your options. > [ Owen: ] > > >> More yes, much more, I'm not so convinced. > > And Owen isn't the only one who thinks that, and I think I know Rob > Seastrom well enough from the list to think he wouldn't concur unless he > had some data from which to work. > Again, its not (I think I've said this enough) a problem in certain scenarios. The issue I take is that hub & spoke doesn't limit your future use and that L1 connectivity as a reason to do home runs is seldom worth the expense. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jof at thejof.com Tue Feb 5 17:41:20 2013 From: jof at thejof.com (Jonathan Lassoff) Date: Tue, 5 Feb 2013 09:41:20 -0800 Subject: L3 East cost maint / fiber 05FEB2012 maintenance In-Reply-To: References: Message-ID: On Tue, Feb 5, 2013 at 9:33 AM, Jason Biel wrote: > Workaround is proper filtering and other techniques on the RE/Loopback to > prevent the issue from happening. Agreed. However, if it only takes one packet, what if an attacker sources the traffic from your management address space? Guarding against this requires either a separate VRF/table for management traffic or transit traffic, RPF checking, or TTL security. If these weren't setup ahead of time, maybe it would be easier to upgrade than lab, test, and deploy a new configuration. This is all speculation about Level3 on my part; I don't know their network from an internal perspective. --j > > Should an upgrade be performed? Yes, but certainly doesn't have to have > right away or without notice to customers. > > On Tue, Feb 5, 2013 at 11:23 AM, Jonathan Lassoff wrote: > >> My hunch is that this is fallout and repairs from Juniper PR839412. >> Only fix is an upgrade. Not sure why they're not able to do a hitless >> upgrade though; that's unfortunate. >> >> Specially-crafted TCP packets that can get past RE/loopback filters >> can crash the box. >> >> --j >> >> On Tue, Feb 5, 2013 at 7:39 AM, Josh Reynolds wrote: >> > I know a lot of you are out of the office right now, but does anybody >> have >> > any info on what happened with L3 this morning? They went into a 5 hour >> > maintenance window with expected downtime of about 30 minutes while they >> > upgraded something like *40* of their "core routers" (their words), but >> > also did this during some fiber work and completely cut off several of >> > their east coast peers for the entirety of the 5 hour window. >> > >> > If anybody has any more info on this, on a NOC contact for them on the >> East >> > Coast for future issues, you can hit me off off-list if you don't feel >> > comfortable replying with that info here. >> > >> > Thanks, and I hope hope you guys are enjoying Orlando. >> > >> > -- >> > *Josh Reynolds* >> > esseph at gmail.com - (270) 302-3552 >> >> > > > -- > Jason From khelms at zcorum.com Tue Feb 5 17:45:04 2013 From: khelms at zcorum.com (Scott Helms) Date: Tue, 5 Feb 2013 12:45:04 -0500 Subject: How far must muni fiber operators protect ISP competition? In-Reply-To: <30628727.4976.1360082938016.JavaMail.root@benjamin.baylink.com> References: <30628727.4976.1360082938016.JavaMail.root@benjamin.baylink.com> Message-ID: Jay, On the data side that's certainly possible, but the content guys won't play ball on a shared L2 network. This actually undermines my position on how to architect your system, but sharing anything from one of the big content guys isn't something I've seen them allow as of yet. Organizations like TVN(Avail now?) or NCTC also require direct agreements and I've never seen them do anything at an aggregation level. On Tue, Feb 5, 2013 at 11:48 AM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Scott Helms" > > > On the video side or the total data project? Both? > > "The point of open fiber is to level the competitive marketplace as > much as possible for provider. Which approach better services that > goal: telling them all about all the providers who might make their > services more complete, or not doing so?" > > Whether we provide shared space, treating such providers as other > clients, and tying them all through an IX switch, is a subsidiary > issue. > > Cheers > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jason at biel-tech.com Tue Feb 5 18:02:06 2013 From: jason at biel-tech.com (Jason Biel) Date: Tue, 5 Feb 2013 12:02:06 -0600 Subject: L3 East cost maint / fiber 05FEB2012 maintenance In-Reply-To: References: Message-ID: Agree as well. Bad assumption on my part that Level3 would doing the items listed in the workaround already. On Tue, Feb 5, 2013 at 11:41 AM, Jonathan Lassoff wrote: > On Tue, Feb 5, 2013 at 9:33 AM, Jason Biel wrote: > > Workaround is proper filtering and other techniques on the RE/Loopback to > > prevent the issue from happening. > > Agreed. However, if it only takes one packet, what if an attacker > sources the traffic from your management address space? > > Guarding against this requires either a separate VRF/table for > management traffic or transit traffic, RPF checking, or TTL security. > If these weren't setup ahead of time, maybe it would be easier to > upgrade than lab, test, and deploy a new configuration. > > This is all speculation about Level3 on my part; I don't know their > network from an internal perspective. > > --j > > > > Should an upgrade be performed? Yes, but certainly doesn't have to have > > right away or without notice to customers. > > > > On Tue, Feb 5, 2013 at 11:23 AM, Jonathan Lassoff > wrote: > > > >> My hunch is that this is fallout and repairs from Juniper PR839412. > >> Only fix is an upgrade. Not sure why they're not able to do a hitless > >> upgrade though; that's unfortunate. > >> > >> Specially-crafted TCP packets that can get past RE/loopback filters > >> can crash the box. > >> > >> --j > >> > >> On Tue, Feb 5, 2013 at 7:39 AM, Josh Reynolds wrote: > >> > I know a lot of you are out of the office right now, but does anybody > >> have > >> > any info on what happened with L3 this morning? They went into a 5 > hour > >> > maintenance window with expected downtime of about 30 minutes while > they > >> > upgraded something like *40* of their "core routers" (their words), > but > >> > also did this during some fiber work and completely cut off several of > >> > their east coast peers for the entirety of the 5 hour window. > >> > > >> > If anybody has any more info on this, on a NOC contact for them on the > >> East > >> > Coast for future issues, you can hit me off off-list if you don't feel > >> > comfortable replying with that info here. > >> > > >> > Thanks, and I hope hope you guys are enjoying Orlando. > >> > > >> > -- > >> > *Josh Reynolds* > >> > esseph at gmail.com - (270) 302-3552 > >> > >> > > > > > > -- > > Jason > -- Jason From jra at baylink.com Tue Feb 5 18:07:46 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 5 Feb 2013 13:07:46 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: Message-ID: <26786724.4986.1360087666776.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > > "Overlaid"? Could you clarify that? > > Sure, ring, hub & spoke, home run, star these are all descriptions of the > physical architecture and many layer 2 technologies will happily use them > all including Ethernet. To use a specific example an existing SONET ring > (OC-3 to be precise) had be in service with an ILEC for more than a decade. Yup; with you so far; I was an OC-12 tail circuit off of L3/telcove's Pinellas County ring at an earlier job. (And I had a fault on one side, because an... > This physical topology was a common one with a physical ring of fiber (32 > strands, yes this was built back in the day) connected to Add/Drop > Multiplexers (Fujitsu IIRC) ADM at a site adjacent to me was in a business that had closed down, and L3 couldn't get it out of the loop, or hadn't, or what have you, so I was unprotected the entire 2.5 years I was there. Only went out once or twice, though. Mine was a Lucent DMXplore, delivering 6 DS1s and a 10BaseT. > along the ring as needed to deliver 25,000 > or shorter copper loops either directly from the same cabinet that ADM > was in or from a subtended Digital Loop Carrier off of a spur (collapsed > ring) of the ring. Now, SONET connections work off a pair of fibers, one for > transmit and one for receive. To run Ethernet (initially 100mbps but now > 10G) we simply lit 2 of the remaining 30 strands to overlay an Ethernet > ring on top of the SONET ring. We then placed switches in the same remote > cabinets we had the ADMs and DLCs and started trenching the fiber drops. Surely. You *put active equipment out in the physical plant*. I'm sure that there are some physical plant design criteria that permit that decision, but mine isn't one of them, for reasons I believe I've made fairly clear. You disagree with some of those as well, of course, but you understand *that* I have made them, and I would expect, therefore, also why this entire subthread isn't germane to the problem I'm trying to solve, right? > > Owen's assertion (and mine) is that a loop architecture *requires* active > > equipment, suited to the phy layer protocol, at each node. And while those > > loop fibers are running SONET, they can't be running anything else at the > > same time. > > You're confounding the physical layer topology with the layer 2 protocol. > You can't run SONET and Ethernet on the same physical fiber at the same > time (unless you use WDM but that's confusing the discussion) but you'd > never build a ring of fiber with only two strands. Certainly not. But a ring a) requires *some kind* of active equipment between the MDF and the ONT, and b) does not support PtP at all. So, *for my stated purposes*, it's not an acceptable alternative. > > > There is nothing about a hub & spoke architecture is this harmful > > > or even suboptimal for doing Gig-E directly to end users today. > > > > You propose to run a ring *for each subscriber*? Or put active gear > > in the field to mux the subscriber AE loops into a SONET ring? > > > > Or some other approach I don't know is possible? > > SONET is simply the legacy (and expensive) way that telco's used to build > rings. I'd neither use it nor recommend it for much of anything today. > Calix, Occam(also Calix now), Adtran, and all the other guys who play > in this space will happily construct a Gig/10G/40G Ethernet ring in the > same shelf you're going to be buying to put your GPON or AE line cards in. I'm sure, but it's still a ring. If I ever want to upgrade it, I have to do a lot more than rack new gear in my "CO", and then move patch cords one at a time. > > I infer from that continuation of your thought that you mean the > > second: active optical muxes out in the plant. > > > > I'm sure I've made clear why that design limits me in ways I don't > > want to be limited when building a fiber plant for a 50 year lifetime, > > but let's address your responses below. > > > > The only limitation you have is a limited supply of total fibers > (hint, this is a big reason why its cheaper to build and run). Nope, that is, in fact, not the only limitation; the others have been expressed or implied, but are left as an exercise for the student. > > > > Lower the price per instance and you very likely find new > > > > demands. > > > The vast majority of business don't WANT that kind of > > > connectivity. > > The vast majority of businesses don't want it at the price they have to > > pay for it now -- or more to the point, the consultants who do their IT > > don't. > > > > You have no real way, I should think, to extrapolate whether that > > will continue as prices drop, especially if sharply. > The vast majority of businesses don't know and don't care about HOW their > connectivity is delivered and wouldn't know the difference between Layer 1 > and Layer 2 if it punched them in the face. No one in this conversation, Scott, has ever suggested that *subscribers* care how the ISP delivers the service, as long as it's fast -- though the percentage who *do* is likely still higher than you think it is. I care; don't you? :-) > Almost all businesses want > INTERNET connectivity at the highest quality & speed at the lowest > cost and that's it. There are a small percentage, mainly larger businesses, > that do have special requirements, but those special requirements very seldom > include a L1 anything. Yes, but now we're into Whorf's Hypothesis: your vocabulary limits the things you're *able* to think about; it hasn't been practical to *supply* MAN L1 fiber at reasonable prices until about now. > > Sure; most small businesses don't need MPLS. > > Nor medium businesses, and that's where knowing your (potential) customer > base matters more than anything I can tell you. If you're in an area with > lots of technology jobs and/or financial companies your network will look > differently than an average small town muni build. If your customer base > is primarily residential with a few businesses (hospitals and schools also > count here) then you'll be lucky to sell a handful of L1 connections and > some of the people who will be interested will want it for very low bit > rate (means low price too) uses like RS-232 over fiber for managing SCADA > nodes or other telemetry pieces. Sure, and I don't expect to sell a lot of it up front, unless my launch ISP wants to use their own L2 gear. *But this does not preclude my building to enable it*, which is a different thing from how much of it I expect to sell. > > But there are some that do, and there are some that it doesn't matter > > *where they are at*. "Fiber on your wall with no upfront engineering > > charge" is a pretty strong call, in some markets, and I won't have to > > do most of the publicity myself; it'll make the news. > > You'll get some publicity, especially if you do a little self > promoting. Yep, and PR is not foreign to me; it will actually be in the project budget, along with outside counsel. > The problem I see is that you seem to think that by building the L1 piece > you're going to have ISPs that are eager to serve your customers. If your > demographics are like most small towns in the US that just isn't very > likely. Any ISP partner is going to have to build and maintain a lot of > infrastructure before they can serve the first end user and your "no > upfront engineering" is simply not true unless you're going to configure > and run MetroE and/or GPON shelves for them. In any sharing scenario (L1, > L2, or L3) the ISP is going to have to connect to you with enough bandwidth > to serve those end users as well. How many service providers have > expressed interest? Have you talked pricing for the loops and colo > space yet? Oh, Jesus; Scott. I've been clear from in front that this is a 36 months to shovel project for me; no, I haven't talked to providers yet; I'm still angling for the *job*. > > > What vendors? ISPs don't. > > > > And your assertion here is based on what? How many places have ISPs > > had a *choice* as to whether to take a L1 optical or L2 aggregated > > handoff? > I've done nothing but work with ISPs, often in the situation you're > describing, for the past 15 years. I also know how ISPs, especially at > the size you might attract operate. And yet, you didn't answer the question: *how many places has the choice about which you express an opinion *actually been made* by an ISP serving subs on a fiber plant they don't own, if any*? > > > That's called home running, but as I've said that's ok in some > > > scenarios, its just that in most cases there is no benefit. > > > > Today. Neither you nor I know how that will change in 20, 30, or 50 > > years. But that's the horizon I'm planning not to block. > > You're betting money against Ethernet's (not to mention any new technology) > ability to keep up as a technology. You're statement is true, but its a > lot like buying insurance against meteor strikes. Today on a normal ring > topology most people are installing hundreds of pairs of physical fiber so > even without adding Wave Division Multiplexing in you can easily build > a ring with several terabits per second capacity. Even easier(and cheaper) > is to build several 10G rings on top of each other with the exact same > shelves you're going to be using to push out GPON or AE. I never bet against Ethernet; I'm not stupid, and this is not my first rodeo. (Well, ok, the first one with bulls this big... :-) > Its an admirable goal, but you're never going to have CCIEs (probably > not even CCNAs) doing installs. Installation is, has been, and will in all > likelihood continue to be done by people with limited skill sets. You > building your own fiber plant and making it easier for ISPs to connect > isn't going to change that. But that, Scott, is orthogonal to *whether they can work with my L1 guy(s) to find a problem*; a CC?? is not necessary for that, that I can see. And anybody big enough to want to come in and do L1 fiber *will already have guys who are fiber-trained*. > > When you say "normal installers", do you mean "employees of the ISP", > > "employees of the muni", or "subcontractors of one of those two"? > > And why is that pertinent? > > Whoever does the install at the home or office. Who they work for really > doesn't matter since the skill set will be largely the same. Its pertinent > because you can have the greatest plant on the planet but if your install > isn't done correctly the end user (the guy paying you or your partner) > won't be happy. The majority of your day to day problems will be driven by > installs. The fiber was improperly terminated, the drop was in the wrong > place, the ONT didn't work correctly, etc. Please, go join the LinkedIn > FTTx group and read some of the things there: > > You probably can't follow that link until you join but its a good > discussion of some of the problems. > > http://www.linkedin.com/groupItem?view=&gid=83578&type=member&item=208400553&qid=379425dd-6f05-4caa-b2d4-f4fbf2aeb9cc&trk=group_most_popular-0-b-ttl&goback=%2Egmp_83578 I've been avoiding LinkedIN like bubonic plague. > > Your assertion seems to be that it will be necessary to have "abnormal" > > installers in the field in order for them not to dump problem tickets > > off to the muni and fail to help meaningfully in fixing them. > > > > First, I think this unlikely since, in most cases, we'll have 3pr available > > at each address. If we think there's a problem with the pair, we can > > "cut to clear" *temporarily*, and if the second pair is ok, then the > > sub is back online while we test the first pair and clear the problem. > > > > (GTE's failure, for all that I give them shit about CtC is that they > > never *worked* the dead pairs; as long as you do, it's not a problem.) > > That's great, and I'm glad to hear you've worked out that part of the drop > but most of the problems occur from the drop into the house or office. That jack box will be on the building, either as an exterior ONT, or as an exterior or interior jackbox that an interior ONT plugs into; I'm still working out the tradeoffs on that. > The last 20 yards are the most problematic and most changed. This is where > the installer matters most and why even good plant has bad installs. Sure. But see way above about "install contractor testing to the jacks". Or, immediately below. :-} > > Second, since we'll be terminating all 3 pairs to a jackbox, the > > installation contractor will be able to perform and document whatever > > acceptance testing we instruct them to. Sure, that will cost some > > more money, but again, if your capital plant is tested good when > > installed, this reduces markedly the opex maintenance cost over time. Where > > that breakeven point will be depends on what they want to charge me to do > > the testing, just as it does with Cat6. No comment there? > > [ Scott: ] > > > >> Sure it does, even in greenfield and whats more it costs more > > > >> over the > > > >> long term UNLESS you know where every home and business will be > > located 10 > > > >> years from now. > > > > A luxury I do have, since my city is nearly 100.0% built; it's > > certainly 100% platted. > > > That's good, and again my argument isn't that you shouldn't home run all > your connections, but rather using the idea of L1 handoffs as a reason to > do so is flawed and that hub and spoke does not limit your options. I am using H&S. Just with only one hub. > > [ Owen: ] > > > >> More yes, much more, I'm not so convinced. > > > > And Owen isn't the only one who thinks that, and I think I know Rob > > Seastrom well enough from the list to think he wouldn't concur > > unless he had some data from which to work. > > Again, its not (I think I've said this enough) a problem in certain > scenarios. The issue I take is that hub & spoke doesn't limit your > future use and that L1 connectivity as a reason to do home runs is seldom > worth the expense. Perhaps. But we seem to have established that homerun vs, say, GPON with splitters in the plant, is merely delta; maybe 5-8% more CAPEX. And the other alternative you present, ring with active muxes in the field, I have already ruled out for the reasons above. Until I get to the point where I have real, current, quoted numbers on the plant install in various approaches, I suppose we ought to let this thread drop for now. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Tue Feb 5 18:11:10 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 5 Feb 2013 13:11:10 -0500 (EST) Subject: How far must muni fiber operators protect ISP competition? In-Reply-To: Message-ID: <12664567.4988.1360087870311.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > On the data side that's certainly possible, but the content guys won't play > ball on a shared L2 network. This actually undermines my position on how > to architect your system, but sharing anything from one of the big content > guys isn't something I've seen them allow as of yet. Organizations like > TVN(Avail now?) or NCTC also require direct agreements and I've never seen > them do anything at an aggregation level. I'm aware of how pissy content providers/transport aggregators are likely to be; I'm been involved in the mythTV project for about 7 years. My point was that if any of them provide on-site equipment as, say, Akamai do (and yes, I realize we're discussing real-time now, not caching), if they have multiple clients in the same place, it's in *their* best interest not to provision multiple racks just because they have contracts with multiple providers; perhaps such racks would connect directly, and mentioning my IX was a red-herring; my apologies for confusing the matter. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mpetach at netflight.com Tue Feb 5 18:33:55 2013 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 5 Feb 2013 10:33:55 -0800 Subject: 2013.02.05 NANOG57 day2 morning session notes are up Message-ID: I posted my notes from this morning's session at http://kestrel3.netflight.com/2013.02.05-NANOG57-day2-morning-session.txt Sorry about the gap in the notes about the telegeography talk; my player decided to wig out, and then die, and I lost a chunk while switching to the redundant computer. Awesome content this morning; definitely getting kudos in the survey feedback! Matt From khelms at zcorum.com Tue Feb 5 18:41:40 2013 From: khelms at zcorum.com (Scott Helms) Date: Tue, 5 Feb 2013 13:41:40 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <26786724.4986.1360087666776.JavaMail.root@benjamin.baylink.com> References: <26786724.4986.1360087666776.JavaMail.root@benjamin.baylink.com> Message-ID: > You *put active equipment out in the physical plant*. > > I'm sure that there are some physical plant design criteria that permit > that decision, but mine isn't one of them, for reasons I believe I've made > fairly clear. > > You disagree with some of those as well, of course, but you understand > *that* I have made them, and I would expect, therefore, also why this > entire subthread isn't germane to the problem I'm trying to solve, right? > I've tried to make clear that yes, in some scenarios (and your situation may well fit here) that it makes sense so I think we can drop this portion. > > > > Owen's assertion (and mine) is that a loop architecture *requires* > active > > > equipment, suited to the phy layer protocol, at each node. And while > those > > > loop fibers are running SONET, they can't be running anything else at > the > > > same time. > > > > You're confounding the physical layer topology with the layer 2 protocol. > > You can't run SONET and Ethernet on the same physical fiber at the same > > time (unless you use WDM but that's confusing the discussion) but you'd > > never build a ring of fiber with only two strands. > > Certainly not. > > But a ring a) requires *some kind* of active equipment between the MDF > and the ONT, and b) does not support PtP at all. > > So, *for my stated purposes*, it's not an acceptable alternative. > Right, I'm questioning the value of and required number of point to point connections. You certainly can do dozens of point to point connections with a hub and spoke by simply having a patch panel where your cabinets (which you'll probably have anyhow). > > > > > There is nothing about a hub & spoke architecture is this harmful > > > > or even suboptimal for doing Gig-E directly to end users today. > > > > > > You propose to run a ring *for each subscriber*? Or put active gear > > > in the field to mux the subscriber AE loops into a SONET ring? > > > > > > Or some other approach I don't know is possible? > > > > SONET is simply the legacy (and expensive) way that telco's used to build > > rings. I'd neither use it nor recommend it for much of anything today. > > Calix, Occam(also Calix now), Adtran, and all the other guys who play > > in this space will happily construct a Gig/10G/40G Ethernet ring in the > > same shelf you're going to be buying to put your GPON or AE line cards > in. > > I'm sure, but it's still a ring. > > If I ever want to upgrade it, I have to do a lot more than rack new gear > in my "CO", and then move patch cords one at a time. > Not really, all that changes (and this does matter) is where you swap cards out. > > > > I infer from that continuation of your thought that you mean the > > > second: active optical muxes out in the plant. > > > > > > I'm sure I've made clear why that design limits me in ways I don't > > > want to be limited when building a fiber plant for a 50 year lifetime, > > > but let's address your responses below. > > > > > > > The only limitation you have is a limited supply of total fibers > > (hint, this is a big reason why its cheaper to build and run). > > Nope, that is, in fact, not the only limitation; the others have been > expressed or implied, but are left as an exercise for the student. > Then I'd have continue to say none, since I've done all of the things you're saying are limitations. If your position was something like, "We did the economic study and it will cost us less to home run everything than to place remote cabinets with power." I'd have never questioned you at all. I know you've made a decision, but you _seem_ to have made it on faulty assumptions: 1) You will have demand for layer 1 connectivity sufficient to offset the higher costs of home running all the fiber both today and in 10 years. 2) Not home running creates limitations, mainly on assumption #1, that make it untenable. If #1 isn't true (and I strongly doubt it is) then #2 can't be either. That doesn't mean that home running is wrong for you, but if you did your math on those two assumptions then its certainly questionable. > > > > > Almost all businesses want > > INTERNET connectivity at the highest quality & speed at the lowest > > cost and that's it. There are a small percentage, mainly larger > businesses, > > that do have special requirements, but those special requirements very > seldom > > include a L1 anything. > > Yes, but now we're into Whorf's Hypothesis: your vocabulary limits the > things you're *able* to think about; it hasn't been practical to *supply* > MAN L1 fiber at reasonable prices until about now. > > I'm basing my views on talking to ISPs around North America and beyond and helping them plan their networks. You're basing your view on? I could certainly be wrong and it wouldn't be the first time nor will it be the last. Having said that, if you don't have some solid market research or some interested ISPs telling you what they want exactly what are you basing your opinion on? > > > Sure, and I don't expect to sell a lot of it up front, unless my launch > ISP wants to use their own L2 gear. *But this does not preclude my > building > to enable it*, which is a different thing from how much of it I expect to > sell. > > If costs were identical I'd agree, but they're not. Again, I'm not saying that your situation is wrong for home running cable. I'm simply saying you should be looking at the costs of remote cabinets versus the cost of home running and NOT a product that you don't expect to sell. > > Yep, and PR is not foreign to me; it will actually be in the project > budget, along with outside counsel. > Let me know when you guys are ready and we'll be glad to send some traffic your way. > > > Oh, Jesus; Scott. I've been clear from in front that this is a 36 months > to > shovel project for me; no, I haven't talked to providers yet; I'm still > angling for the *job*. > But you're convinced you have the right architecture? This dichotomy seems odd to me. > > And yet, you didn't answer the question: *how many places has the choice > about which you express an opinion *actually been made* by an ISP > serving subs on a fiber plant they don't own, if any*? > Very few in the US. In Europe its more common, but even where its available as the commentator from France asserted, its only the largest ISPs that take that route and its not always smooth. In most places where I've been involved open access was done on either cable or DSL networks. Doing it in DSL, which has something like 90% of the open access market, is straightforward via PPPoE at layer 2. In DOCSIS its also done at layer 2 because of how cable modems work (they look at each downstream signal). > > > > But that, Scott, is orthogonal to *whether they can work with my L1 guy(s) > to find a problem*; a CC?? is not necessary for that, that I can see. > > And anybody big enough to want to come in and do L1 fiber *will already > have guys who are fiber-trained*. > The problem here is the economics. Its not a case of can I make it work, you can. Its a problem of do I make money (or at least break even) when I make it work. I'll posit that your L1 connections will require more time from your technicians while you're taking in less revenue. Are you going to pre-qualify your L1 partners? How? > > > I've been avoiding LinkedIN like bubonic plague. > Its a good resource, since most people entering the field don't know what mailing lists are much less Usenet or IRC...../em grumbles about young whippersnappers > > The last 20 yards are the most problematic and most changed. This is > where > > the installer matters most and why even good plant has bad installs. > > Sure. But see way above about "install contractor testing to the jacks". > > Or, immediately below. :-} > > > > Second, since we'll be terminating all 3 pairs to a jackbox, the > > > installation contractor will be able to perform and document whatever > > > acceptance testing we instruct them to. Sure, that will cost some > > > more money, but again, if your capital plant is tested good when > > > installed, this reduces markedly the opex maintenance cost over time. > Where > > > that breakeven point will be depends on what they want to charge me to > do > > > the testing, just as it does with Cat6. > > No comment there? > So your L1 partners will have to have a PON tester as well....you are selective. > > > > [ Scott: ] > > > > >> Sure it does, even in greenfield and whats more it costs more > > > > >> over the > > > > >> long term UNLESS you know where every home and business will be > > > located 10 > > > > >> years from now. > > > > > > A luxury I do have, since my city is nearly 100.0% built; it's > > > certainly 100% platted. > A side note, what happens when you need more than 3 pair to each jack? How are you building to MDUs, assuming you have some in the area? What happens if a new apartment complex is built next year? > > Perhaps. But we seem to have established that homerun vs, say, GPON with > splitters in the plant, is merely delta; maybe 5-8% more CAPEX. And the > other alternative you present, ring with active muxes in the field, I > have already ruled out for the reasons above. > > Until I get to the point where I have real, current, quoted numbers on > the plant install in various approaches, I suppose we ought to let > this thread drop for now. > Probably a good idea, I had actually assumed from the thread you were past that point. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From joelja at bogus.com Tue Feb 5 19:38:35 2013 From: joelja at bogus.com (joel jaeggli) Date: Tue, 05 Feb 2013 11:38:35 -0800 Subject: L3 East cost maint / fiber 05FEB2012 maintenance In-Reply-To: References: Message-ID: <51115FBB.9090502@bogus.com> On 2/5/13 10:02 AM, Jason Biel wrote: > Agree as well. > > Bad assumption on my part that Level3 would doing the items listed in the > workaround already. > > On Tue, Feb 5, 2013 at 11:41 AM, Jonathan Lassoff wrote: > >> On Tue, Feb 5, 2013 at 9:33 AM, Jason Biel wrote: >>> Workaround is proper filtering and other techniques on the RE/Loopback to >>> prevent the issue from happening. >> Agreed. However, if it only takes one packet, what if an attacker >> sources the traffic from your management address space? >> >> Guarding against this requires either a separate VRF/table for >> management traffic or transit traffic, RPF checking, or TTL security. >> If these weren't setup ahead of time, maybe it would be easier to >> upgrade than lab, test, and deploy a new configuration. >> >> This is all speculation about Level3 on my part; I don't know their >> network from an internal perspective. Routers that show up on exchange fabrics are a particular problem... For this issue... For what it's worth we have several dzone circuits with them from 100mb/s office links to 10Gb/s paths and we have notifications for maintenances last night and tonight and touching locations in europe us east and us west coasts. I'm presuming that there is further internal work that is not directly impactful. I have evidence of various other providers as well as ourselves undertaking fixes to this issue. >> --j >>> Should an upgrade be performed? Yes, but certainly doesn't have to have >>> right away or without notice to customers. >>> >>> On Tue, Feb 5, 2013 at 11:23 AM, Jonathan Lassoff >> wrote: >>>> My hunch is that this is fallout and repairs from Juniper PR839412. >>>> Only fix is an upgrade. Not sure why they're not able to do a hitless >>>> upgrade though; that's unfortunate. >>>> >>>> Specially-crafted TCP packets that can get past RE/loopback filters >>>> can crash the box. >>>> >>>> --j >>>> >>>> On Tue, Feb 5, 2013 at 7:39 AM, Josh Reynolds wrote: >>>>> I know a lot of you are out of the office right now, but does anybody >>>> have >>>>> any info on what happened with L3 this morning? They went into a 5 >> hour >>>>> maintenance window with expected downtime of about 30 minutes while >> they >>>>> upgraded something like *40* of their "core routers" (their words), >> but >>>>> also did this during some fiber work and completely cut off several of >>>>> their east coast peers for the entirety of the 5 hour window. >>>>> >>>>> If anybody has any more info on this, on a NOC contact for them on the >>>> East >>>>> Coast for future issues, you can hit me off off-list if you don't feel >>>>> comfortable replying with that info here. >>>>> >>>>> Thanks, and I hope hope you guys are enjoying Orlando. >>>>> >>>>> -- >>>>> *Josh Reynolds* >>>>> esseph at gmail.com - (270) 302-3552 >>>> >>> >>> -- >>> Jason > > From jcurran at arin.net Tue Feb 5 20:19:31 2013 From: jcurran at arin.net (John Curran) Date: Tue, 5 Feb 2013 20:19:31 +0000 Subject: REMINDER - Register Now for ARIN Public Policy Consultation @ NANOG 57 References: <8DA1853CE466B041B104C1CAEE00B3748F5BA1E3@CHAXCH01.corp.arin.net> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748F72F2D5@CHAXCH01.corp.arin.net> REMINDER - If you are remotely participating in the NANOG 57 meeting, and intend to participate in the ARIN Public Policy Consultation, you must register to participate in the jabber session and thus ask questions and be counted in any polls conducted. For those not already registered at this point, you may still do so quickly by going to > and clicking on the "Register Now" button... FYI (and Thanks!) /John Begin forwarded message: From: John Curran > Subject: Register Now for ARIN Public Policy Consultation @ NANOG 57 Date: January 15, 2013 1:33:53 PM EST To: NANOG list > NANOGers - If you are going to be at NANOG 57 in Orlando, then please note that ARIN will be holding a Public Policy Consultation (PPC) there regarding several number resource policy proposals and you are very much encouraged to participate and make your views on these proposals known. Your NANOG 57 registration includes attending the ARIN Public Policy Consultation onsite if you so desire to do so. As ARIN's Public Policy Consultations are open to all, it is also possible to attend _just_ the PPC without charge, either in person or remotely. One needs to register separately to just participate in the public policy consultation, and this registration does not provide you entry to any other NANOG programming or social events. This is not likely to be relevant to many folks on this list (since I'll be seeing most of you onsite at NANOG 57!) but if you are going to be remotely watching NANOG 57, please take note and register for the ARIN PPC if you intend on participating in that session (and details are available in the attached announcement.) I'd like to take a moment to thank NANOG's Executive Director Betty Burke and the NANOG Planning Committee for making possible the ARIN Public Policy Consultation @ NANOG 57! Thanks! /John John Curran President and CEO ARIN Begin forwarded message: From: ARIN > Subject: [arin-ppml] Register Now for ARIN Public Policy Consultation @ NANOG 57 Date: January 15, 2013 5:17:30 AM HST To: arin-ppml at arin.net Registration is now open for ARIN's first Public Policy Consultation (PPC), which will be held during NANOG 57 in Orlando, FL on 5 February 2013 at the Renaissance Orlando at Seaworld. The PPC is part of ARIN's new Policy Development Process, and it is an open public discussion of Internet number resource policy. Registered NANOG 57 attendees do not need to register to participate in this session. ARIN welcomes members of the NANOG community who will not be in Orlando to register as remote participants. If you plan to attend and are not registered for NANOG you must register for the PPC at the URL below. There is no registration fee for this 90-minute session, and it does not provide you entry to any other NANOG programming or social events. Learn more at https://www.arin.net/ppc_nanog57/index.html. Current policy proposals up for discussion at this meeting are: * ARIN-2012-2: IPv6 Subsequent Allocations Utilization Requirement - https://www.arin.net/policy/proposals/2012_2.html * ARIN-prop-182 Update Residential Customer Definition to not exclude wireless as Residential Service - http://lists.arin.net/pipermail/arin-ppml/2012-October/026116.html * ARIN-prop-183 Section 8.4 Transfer enhancement- http://lists.arin.net/pipermail/arin-ppml/2012-October/026203.html The PPC will also include a Policy Experience Report and Open Microphone. ARIN will offer a webcast, live transcript, and Jabber chat options for remote participants. Registered remote participants can submit comments and questions to the discussions during the meeting. Register to attend in person or remotely today! Visit https://www.arin.net/app/meeting/registration/. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From thaitim43 at hotmail.com Tue Feb 5 21:01:18 2013 From: thaitim43 at hotmail.com (Tim Haak) Date: Tue, 5 Feb 2013 16:01:18 -0500 Subject: AT&T Uverse/DSL Network Engineer DNS question Message-ID: Hi, Can a AT&T Uverse/DSL Network Engineer answer a question about the DNS server IPs that are handed out to customers please? I am currently testing from a Florida IP. Can you please let me know if all Uverse and DSL customers across the United States only use these 2 IPs as their primary and secondary DNS servers? 68.94.156.1 68.94.157.1 We provide services based on IP GEO-location. Since the 2 recursive resolvers below are registered in Texas every DNS query for any of our records return results that are intended for IPs in that region. In other words, users on the east coast would actually resolve to a central part of the US or west coast IP. Thanks in advance,Tim From jof at thejof.com Tue Feb 5 21:10:33 2013 From: jof at thejof.com (Jonathan Lassoff) Date: Tue, 5 Feb 2013 13:10:33 -0800 Subject: AT&T Uverse/DSL Network Engineer DNS question In-Reply-To: References: Message-ID: These appear to be an anycasted service, as I reach different destinations based on my source address. Hopefully each deployment has unique origin IPs for their recursive queries. I would recommend against looking at RIR registration data to determine IP location. There's often little to no correlation, there. --j On Tue, Feb 5, 2013 at 1:01 PM, Tim Haak wrote: > > > > > > > > > > Hi, > > > > > Can a AT&T Uverse/DSL Network Engineer answer a question about the DNS > server IPs that are handed out to customers please? I am currently testing > from > a Florida IP. Can you please let me know if all Uverse and DSL customers > across the United States only use these 2 IPs as their primary and > secondary > DNS servers? > > > > 68.94.156.1 > > 68.94.157.1 > > > > We > provide services based on IP GEO-location. Since the 2 recursive resolvers > below are registered in Texas every DNS query for any of our records return > results that are intended for IPs in that region. In other words, users on > the > east coast would actually resolve to a central part of the US or west > coast IP. > > > > Thanks > in advance,Tim > > > > From jof at thejof.com Tue Feb 5 21:13:50 2013 From: jof at thejof.com (Jonathan Lassoff) Date: Tue, 5 Feb 2013 13:13:50 -0800 Subject: AT&T Uverse/DSL Network Engineer DNS question In-Reply-To: References: Message-ID: On Tue, Feb 5, 2013 at 1:10 PM, Jonathan Lassoff wrote: > These appear to be an anycasted service, as I reach different destinations > based on my source address. > > Hopefully each deployment has unique origin IPs for their recursive > queries. > Just confirmed this. As these resolvers traverse and query your servers, they'll have different source IPs, depending on the regional resolver. Return differentiated DNS responses, based on that. --j > > I would recommend against looking at RIR registration data to determine IP > location. There's often little to no correlation, there. > > --j > > > On Tue, Feb 5, 2013 at 1:01 PM, Tim Haak wrote: > >> >> >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> Can a AT&T Uverse/DSL Network Engineer answer a question about the DNS >> server IPs that are handed out to customers please? I am currently >> testing from >> a Florida IP. Can you please let me know if all Uverse and DSL customers >> across the United States only use these 2 IPs as their primary and >> secondary >> DNS servers? >> >> >> >> 68.94.156.1 >> >> 68.94.157.1 >> >> >> >> We >> provide services based on IP GEO-location. Since the 2 recursive resolvers >> below are registered in Texas every DNS query for any of our records >> return >> results that are intended for IPs in that region. In other words, users >> on the >> east coast would actually resolve to a central part of the US or west >> coast IP. >> >> >> >> Thanks >> in advance,Tim >> >> >> >> > > > From wbailey at satelliteintelligencegroup.com Tue Feb 5 21:15:46 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 5 Feb 2013 21:15:46 +0000 Subject: AT&T Uverse/DSL Network Engineer DNS question In-Reply-To: Message-ID: Here in Orange County, CA I've got a /28 with Uverse Residential with the same DNS servers as mentioned below. FYI On 2/5/13 1:10 PM, "Jonathan Lassoff" wrote: >These appear to be an anycasted service, as I reach different destinations >based on my source address. > >Hopefully each deployment has unique origin IPs for their recursive >queries. > >I would recommend against looking at RIR registration data to determine IP >location. There's often little to no correlation, there. > >--j > >On Tue, Feb 5, 2013 at 1:01 PM, Tim Haak wrote: > >> >> >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> Can a AT&T Uverse/DSL Network Engineer answer a question about the DNS >> server IPs that are handed out to customers please? I am currently >>testing >> from >> a Florida IP. Can you please let me know if all Uverse and DSL customers >> across the United States only use these 2 IPs as their primary and >> secondary >> DNS servers? >> >> >> >> 68.94.156.1 >> >> 68.94.157.1 >> >> >> >> We >> provide services based on IP GEO-location. Since the 2 recursive >>resolvers >> below are registered in Texas every DNS query for any of our records >>return >> results that are intended for IPs in that region. In other words, users >>on >> the >> east coast would actually resolve to a central part of the US or west >> coast IP. >> >> >> >> Thanks >> in advance,Tim >> >> >> >> > From mpetach at netflight.com Tue Feb 5 22:47:05 2013 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 5 Feb 2013 14:47:05 -0800 Subject: 2013.02.05 NANOG57 day2 afternoon session Message-ID: Notes, complete with typos are up at http://kestrel3.netflight.com/2013.02.05-NANOG57-day2-afternoon-session.txt definitely awesome content today; bummed i missed out, sounds like tonight should be an absolute blast at seaworld--have fun, and we'll see what tomorrow brings. :) Matt From owen at delong.com Tue Feb 5 23:48:01 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Feb 2013 15:48:01 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <24791995.4964.1360081830800.JavaMail.root@benjamin.baylink.com> Message-ID: On Feb 5, 2013, at 9:37 AM, Scott Helms wrote: > On Tue, Feb 5, 2013 at 11:30 AM, Jay Ashworth wrote: > >> ----- Original Message ----- >>> From: "Scott Helms" >> >>>> Yes it does... It locks you into whatever is supported on the ring. >>> >>> I don't know how I can explain this more plainly, I can (more accurately >>> have) taken a fiber build that was created as a ring & spoke SONET system >>> and with the same fiber plant overlaid that with GigE and ATM (further >> back >>> in time) to backhaul for PON, DSL, VOIP, and direct Active Ethernet. >> >> "Overlaid"? Could you clarify that? >> > > Sure, ring, hub & spoke, home run, star these are all descriptions of the > physical architecture and many layer 2 technologies will happily use them > all including Ethernet. To use a specific example an existing SONET ring > (OC-3 to be precise) had be in service with an ILEC for more than a decade. > This physical topology was a common one with a physical ring of fiber (32 > strands, yes this was built back in the day) connected to Add/Drop > Multiplexers (Fujitsu IIRC) along the ring as needed to deliver 25,000 or > shorter copper loops either directly from the same cabinet that ADM was in > or from a subtended Digital Loop Carrier off of a spur (collapsed ring) of > the ring. Now, SONET connections work off a pair of fibers, one for > transmit and one for receive. To run Ethernet (initially 100mbps but now > 10G) we simply lit 2 of the remaining 30 strands to overlay an Ethernet > ring on top of the SONET ring. We then placed switches in the same remote > cabinets we had the ADMs and DLCs and started trenching the fiber drops. However, for any given ring, you are locked into a single technology and you have to put active electronics out in the field. You can't, given a ring architecture, provide dark fiber leases. I realize it is your argument that one doesn't need to do so, there's no market for it, etc. However, I don't agree with you. >> Owen's assertion (and mine) is that a loop architecture *requires* active >> equipment, suited to the phy layer protocol, at each node. And while those >> loop fibers are running SONET, they can't be running anything else at the >> same time. >> > > You're confounding the physical layer topology with the layer 2 protocol. > You can't run SONET and Ethernet on the same physical fiber at the same > time (unless you use WDM but that's confusing the discussion) but you'd > never build a ring of fiber with only two strands. Sure, but, you're ring only works with things that do L2 aggregation in the field with active electronics in the field. This means that for any L2 technology a particular subscriber wants to use, you need to either already have that L2 technology deployed on a ring, or, you need to deploy another ring to support that technology. >>>> Lower the price per instance and you very likely find new demands. >>>> >>> >>> The vast majority of business don't WANT that kind of connectivity. >> >> The vast majority of businesses don't want it at the price they have to >> pay for it now -- or more to the point, the consultants who do their IT >> don't. >> >> You have no real way, I should think, to extrapolate whether that will >> continue as prices drop, especially if sharply. >> > > The vast majority of businesses don't know and don't care about HOW their > connectivity is delivered and wouldn't know the difference between Layer 1 > and Layer 2 if it punched them in the face. Almost all businesses want > INTERNET connectivity at the highest quality & speed at the lowest cost and > that's it. There are a small percentage, mainly larger businesses, that do > have special requirements, but those special requirements very seldom > include a L1 anything. VPNs are popular today (whether MPLS, IPSEC, or otherwise) because L1 connections are expensive and VPNS are (relatively) cheap. If dark fiber can be provided for $30/month per termination (we've already agreed that the cost is $20 or less), that changes the equation quite a bit. If, as a business, I can provide corporate connectivity and internet access to my employees for $30/month/employee without having to use a VPN, but just 802.1q trunking and providing them a router (or switch) that has different ports for Corporate and Personal LANs in their house, that changes the equation quite a bit. Admittedly, this only works for the employees that live within range, but it's an example of the kinds of services that nobody even imagines today because we can't get good L1 services cheap yet. >>>> You're assuming the current business model of incumbent-provider owned >>>> fiber. In a case where you have service providers not allowed to own >> fiber >>>> and a fiber provider not allowed to provide services, the incentives >> all >>>> work towards cooperation and the conflicts of interest between them are >>>> eliminated. I understand what you're saying about field technicians and >>>> their motivations, but, again those are based largely on the current >>>> business models and compensation schemes. In the proposed arena, >> there's no >>>> reason management at the service provider and management at the fiber >>>> provider cannot work together to address these issues. Further, the >>>> technician that blames the fiber plant for everything rather than >>>> cooperating to resolve said issues together will inherently have his >>>> installations take longer than the ones that cooperate, so he is >> actually >>>> already automatically incentivized in the correct direction. >> >> This is my goal. >> >> > Its an admirable goal, but you're never going to have CCIEs (probably not > even CCNAs) doing installs. Installation is, has been, and will in all > likelihood continue to be done by people with limited skill sets. You > building your own fiber plant and making it easier for ISPs to connect > isn't going to change that. Sure, but elsewhere you've pointed out that the last 20 yards are where most of the problems occur? Guess what? The last 20 yards should be the service provider, not the L1 in this case. If you're worried that the tech will blame problems in the last 20 yards on the prem. loop, that's a matter of teaching them where to plug in the box for testing the L1 loop. MMR-------[B-Box]------[Customer Patch]------[IW Termination] 1. Plug into IW Termination If it works, great, you're done. If not: 2. Plug into Customer Patch. If it works, problem is isolated to the IW side of things, not the muni's responsibility. If it doesn't, contact the muni and schedule a joint visit to troubleshoot. Muni will provide an OTDR. Any modulation-specific diagnostic gear to be provided by the service provider. I'm willing to bet that I could teach this to the average installer in a matter of minutes. The important factors at play here are: 1. The muni needs to be responsive and cooperative with the installers in addressing such issues. 2. The installers need to be willing to work cooperatively with the muni's technicians. Throwing tickets over the wall in a fire and forget scenario cannot be allowed (on either side). 3. The muni should have a contractual provision which allows them to charge back the ISP if they make a joint site visit and the problem is shown to be on the IW side of the equation. In such a climate, the installers have an easy way to determine whether the problem is actually on the muni side of the equation or not and an incentive to get that call right. The muni needs to have a high standard of customer service and responsiveness to the service providers (their customers), but they also have a strong incentive to do so since that is what will attract providers to using their system. The service providers are incentivized to properly train their installers and require them to work well with the muni because that will provide a better customer experience for their customers and reduce their chargebacks from the muni. IOW, the important thing is to align the economic incentives with the desired outcomes. >> Your assertion seems to be that it will be necessary to have "abnormal" >> installers in the field in order for them not to dump problem tickets >> off to the muni and fail to help meaningfully in fixing them. >> >> First, I think this unlikely since, in most cases, we'll have 3pr available >> at each address. If we think there's a problem with the pair, we can >> "cut to clear" *temporarily*, and if the second pair is ok, then the sub >> is back online while we test the first pair and clear the problem. >> >> (GTE's failure, for all that I give them shit about CtC is that they never >> *worked* the dead pairs; as long as you do, it's not a problem.) >> > > That's great, and I'm glad to hear you've worked out that part of the drop > but most of the problems occur from the drop into the house or office. The > last 20 yards are the most problematic and most changed. This is where the > installer matters most and why even good plant has bad installs. Which is a really great argument for making that last 20 yards the responsibility of the higher level provider. Owen From mohta at necom830.hpcl.titech.ac.jp Wed Feb 6 00:17:19 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 06 Feb 2013 09:17:19 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> Message-ID: <5111A10F.3060300@necom830.hpcl.titech.ac.jp> Scott Helms wrote: >> They are not soo different, as long as you try to recover initial >> cost not so quickly, which is why copper costs about $10/M or so. > I know several dozen companies that do this kind of construction and they > don't agree. That is, they are trying to recover initial cost quickly. >> And, you can see the slide contain "POP Active Equipment Cost", >> which you thought "most of the cost is in lighting the fiber", >> is already included. > Google is making their own access gear. Their economy is very very > different from all of us here. If you think google access gear is much less expensive than others, let google be the dominant supplier of the access gear for all of us. >> If you throw away optical MDF, there is no point to discuss >> L1 unbundling. >> > > OK, historically the main distribution frame was where all of the copper > pairs came into a central office which means they have enough space to accommodate optical MDF. > note that a phone company often had > several central offices to cover their territory in the time before there > were remotes (Digital Loop Carriers). Each CO has its own MDF, where competing ISPs must have their routers. No different from competing ISPs using DSL or PON. > Today even when you home run all of > your fiber connections you bring it to a central patch panel(s) which > really doesn't look like a main distribution frame. If so, it is merely because they want to make L1 unbundling difficult. >>>> Surely, transition from copper to fiber is not trivial, but it >>>> helps a lot that fiber cables are thinner than copper cables. >> >>> Really, so you think that the thickness of the cable has an impact on how >>> much it should cost? So, tell you what I'll exchange some nice thick >>> 10 gauge copper wire for 4 gauge platinum, since its much thinner that >>> ought to be a good trade for you, right? ;) >> >> My point is that a conduit capable of storing additional 10 guage >> copper can, instead, store 10 guage fiber. >> >> Or, if you assume a conduit without any extra space, upgrading to >> PON is also impossible. > OK, twisted pair cabling isn't run in conduit. Each fiber in an access cable, neither. > You cannot remove the twisted pair in whole or > part and then run fiber through that cabling. Are you saying you can remove a fiber from an access cable? No, you can't. Well....., it is not impossible if you use quite fatty cable in which each fiber is stored in its own conduit. But, it costs a lot. Worse, if a cable is cut, you must repair all the conduit to be air tight again, which means it is practically impossible. > You can of course use the > same trench IF you have buried cable and there is room. There is room for another cable mostly always, because, without the room, you can not replace copper cables without much service interruption. To replace a damaged copper cable without much service interruption, you have to lay a new cable before removing the damaged cable. Masataka Ohta From EWieling at nyigc.com Wed Feb 6 00:27:03 2013 From: EWieling at nyigc.com (Eric Wieling) Date: Tue, 5 Feb 2013 19:27:03 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <5111A10F.3060300@necom830.hpcl.titech.ac.jp> References: <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> Message-ID: <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> In the past the ISP simply needed a nice big ATM pipe to the ILEC for DSL service. The ILEC provided a PVC from the customer endpoint to the ISP. As understand it this is no longer the case, but only because of non-technical issues. We currently use XO, Covad, etc to connect to the customer We get a fiber connection to them and the provide use L2 connectivity to the custom endpoint using an Ethernet VLAN, Frame Relay PVC, etc complete with QoS. I assume XO, etc use UNE access to the local loop. There is no reason a Muni can't do something similar. -----Original Message----- From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] Sent: Tuesday, February 05, 2013 7:17 PM To: Scott Helms Cc: NANOG Subject: Re: Muni fiber: L1 or L2? > note that a phone company often had > several central offices to cover their territory in the time before > there were remotes (Digital Loop Carriers). Each CO has its own MDF, where competing ISPs must have their routers. No different from competing ISPs using DSL or PON. From mohta at necom830.hpcl.titech.ac.jp Wed Feb 6 00:41:42 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 06 Feb 2013 09:41:42 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> References: <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> Message-ID: <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> Eric Wieling wrote: > In the past the ISP simply needed a nice big ATM pipe to the > ILEC for DSL service. The ILEC provided a PVC from the > customer endpoint to the ISP. As understand it this is no > longer the case, but only because of non-technical issues. The non-technical issue is *COST*!!!!! No one considered to use so expensive ATM as L2 for DSL unbundling, at least in Japan, which made DSL in Japan quite inexpensive. > We currently use XO, Covad, etc to connect to the customer > We get a fiber connection to them and the provide use L2 > connectivity to the custom endpoint using an Ethernet VLAN, > Frame Relay PVC, etc complete with QoS. I assume XO, > etc use UNE access to the local loop. There is no reason > a Muni can't do something similar. Muni can. However, there is no reason Muni can't offer L1 unbundling. Masataka Ohta From EWieling at nyigc.com Wed Feb 6 02:40:18 2013 From: EWieling at nyigc.com (Eric Wieling) Date: Tue, 5 Feb 2013 21:40:18 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> References: <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> Message-ID: <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> The ILECs basically got large portions of the 1996 telecom reform rules gutted via lawsuits. DSL unbundling was part of this. See http://quello.msu.edu/sites/default/files/pdf/wp-05-02.pdf The ILECs already need a DSLAM in each CO and already use ATM PVCs to provide L2 connectivity from the DSLAM to their IP network, I don't think it is that much more expensive to allow other ISPs an ATM PVC into their network. ATM may not be the best technology to do this, but the basic concept is not bad. Ethernet VLANs would be another option, as would Frame Relay, as would simply DAXing multiple 64k channels from the customer endpoint to the ISP if you want more L1 style connectivity. What *I* want as an ISP is to connect to customers, I don't care what the local loop is. It could be fiber, twisted pair, coax, or even licensed wireless and hand it off to me over a nice fat fiber link with a PVC or VLAN or whatever to the customer endpoint. What I don't want is to have to install equipment at each and every CO I want to provide service out of. This would be astoundingly expensive for us. -----Original Message----- From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] Sent: Tuesday, February 05, 2013 7:42 PM To: nanog at nanog.org Subject: Re: Muni fiber: L1 or L2? Eric Wieling wrote: > In the past the ISP simply needed a nice big ATM pipe to the > ILEC for DSL service. The ILEC provided a PVC from the > customer endpoint to the ISP. As understand it this is no longer the > case, but only because of non-technical issues. The non-technical issue is *COST*!!!!! No one considered to use so expensive ATM as L2 for DSL unbundling, at least in Japan, which made DSL in Japan quite inexpensive. > We currently use XO, Covad, etc to connect to the customer We get a > fiber connection to them and the provide use L2 connectivity to the > custom endpoint using an Ethernet VLAN, > Frame Relay PVC, etc complete with QoS. I assume XO, > etc use UNE access to the local loop. There is no reason > a Muni can't do something similar. Muni can. However, there is no reason Muni can't offer L1 unbundling. Masataka Ohta From serian.reg at gmail.com Wed Feb 6 03:54:09 2013 From: serian.reg at gmail.com (Abzal Sembay) Date: Wed, 06 Feb 2013 08:54:09 +0500 Subject: Metro Ethernet, VPLS clarifications In-Reply-To: References: <51108551.7090700@gmail.com> Message-ID: <5111D3E1.3000904@gmail.com> 05.02.2013 19:58, Scott Helms ?????: > Metro-Ethernet is generally the term used to describe Ethernet used as > a WAN connection or as a point to point connection. There was at one > time the concept of a MAN (Metro Area Network) but "metro" ethernet is > now available in more scenarios than that described. The connectivity > can be over fiber or copper and the speed delivered can be as low as a > few mbps but commercially available offerings normally start at 5-10 > mbps. On the high end its possible to get gigabit and faster > connections in certain areas. > http://en.wikipedia.org/wiki/Metro_E > > > VPLS stands for Virtual Private Lan Services. This an umbrella > technology that allows for the bridging of layer 2 traffic across > various layer 2 & 3 networks. This is generally used as a replacement > for a point to point metro ethernet (or other) connection. > > http://en.wikipedia.org/wiki/VPLS > > > On Mon, Feb 4, 2013 at 11:06 PM, Abzal Sembay > wrote: > > Hi experts, > > I need some clarifications on these terms. Could somebody give > explanations or share some links? > When and how are these technologies used? > > Thanks in advance. > > -- > Regards, > > Abzal > > > > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- Thank you, Scott and all of you for your answers and time. From my understanding M-Ethernet is a some kind of service. Standartized technology that allows to connect multiple different networks. And it is independent from physical and datalink layers. And nowadays which tecnology is the most used(VPLS or Metro)? What about MPLS? Sorry I'm a little confused. I really want to understand. -- Regards, Abzal From davidpeahi at gmail.com Wed Feb 6 06:44:29 2013 From: davidpeahi at gmail.com (david peahi) Date: Tue, 5 Feb 2013 22:44:29 -0800 Subject: Metro Ethernet, VPLS clarifications In-Reply-To: <5111D3E1.3000904@gmail.com> References: <51108551.7090700@gmail.com> <5111D3E1.3000904@gmail.com> Message-ID: The Metro Ethernet Forum (MEF) develops standards for Metro Ethernet, which are generally implemented by telcos/cablecos. See the following link: http://metroethernetforum.org/ The 2 biggest problems I have found with telco/cableco MEF services are: 1. In network configurations where all sites are relatively close together (< 500 miles), the telco/cableco SLAs are meaningless, bordering on being fraudulent. For instance SLAs of 50 ms round trip for bronze service, and 20 ms for gold service are enough network transit time to send packets 5000 miles and 2000 miles respectively. This is like buying homeowners' insurance on a $500K house with a $10 million deductible (50 ms SLA), and a more expensive policy has a $5 million deductible (20 ms SLA). 2. The MEF spec does not address directed multicast, as opposed to a native Ethernet switched network which updates the mac tables with each next hop for the multicast requestor (video for instance) tracking the Layer 3 multicast routing protocol shortest path. So in MEF implementations where users view a constant 10 Mbps (for example) multicast video stream between a requestor and a multicast source, this 10 Mbps gets broadcast out all switch ports in a users' MEF VLAN, rendering low speed MEF connections at all other users' locations useless. David On Tue, Feb 5, 2013 at 7:54 PM, Abzal Sembay wrote: > 05.02.2013 19:58, Scott Helms ?????: > >> Metro-Ethernet is generally the term used to describe Ethernet used as a >> WAN connection or as a point to point connection. There was at one time >> the concept of a MAN (Metro Area Network) but "metro" ethernet is now >> available in more scenarios than that described. The connectivity can be >> over fiber or copper and the speed delivered can be as low as a few mbps >> but commercially available offerings normally start at 5-10 mbps. On the >> high end its possible to get gigabit and faster connections in certain >> areas. >> http://en.wikipedia.org/wiki/**Metro_E >> >> >> VPLS stands for Virtual Private Lan Services. This an umbrella >> technology that allows for the bridging of layer 2 traffic across various >> layer 2 & 3 networks. This is generally used as a replacement for a point >> to point metro ethernet (or other) connection. >> >> http://en.wikipedia.org/wiki/**VPLS >> >> >> On Mon, Feb 4, 2013 at 11:06 PM, Abzal Sembay > serian.reg at gmail.com>> wrote: >> >> Hi experts, >> >> I need some clarifications on these terms. Could somebody give >> explanations or share some links? >> When and how are these technologies used? >> >> Thanks in advance. >> >> -- Regards, >> >> Abzal >> >> >> >> >> >> -- >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> ------------------------------**-- >> http://twitter.com/kscotthelms >> ------------------------------**-- >> > Thank you, Scott and all of you for your answers and time. > > From my understanding M-Ethernet is a some kind of service. Standartized > technology that allows to connect multiple different networks. And it is > independent from physical and datalink layers. And nowadays which tecnology > is the most used(VPLS or Metro)? What about MPLS? Sorry I'm a little > confused. I really want to understand. > > > -- > Regards, > > Abzal > > From mohta at necom830.hpcl.titech.ac.jp Wed Feb 6 07:50:33 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 06 Feb 2013 16:50:33 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> References: <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> Message-ID: <51120B49.80606@necom830.hpcl.titech.ac.jp> Eric Wieling wrote: > I don't think it is that much more expensive to allow other > ISPs an ATM PVC into their network. Wrong, which is why ATM has disappeared. > ATM may not be the best technology to do this, It is not. > but the basic concept is not bad. It is not enough, even if you use inexpensive Ethernet. See the subject. > What *I* want as an ISP is to connect to customers, You may. However, the customers care cost for you to do so, a lot. L1 unbundling allows the customers to choose an ISP with best (w.r.t. cost, performance, etc.) L2 and L3 technology, whereas L2 unbundling allows ILECs choose stupid L2 technologies such as ATM or PON, which is locally best for their short term revenue, which, in the long run, delays global deployment of broadband environment, because of high cost to the customers. Masataka Ohta From rayw at rayw.net Wed Feb 6 09:58:42 2013 From: rayw at rayw.net (Ray Wong) Date: Wed, 6 Feb 2013 01:58:42 -0800 Subject: Level3 worldwide emergency upgrade? Message-ID: Does anyone have details on tonight's apparent worldwide emergency router upgrade? All I managed to get out of the portal was 30 minutes, "Service Affecting" (no kidding?) and the NOC line gave me the recording about it and disconnected me. -R> From froztbyte at froztbyte.net Wed Feb 6 11:04:40 2013 From: froztbyte at froztbyte.net (JP Viljoen) Date: Wed, 6 Feb 2013 13:04:40 +0200 Subject: Level3 worldwide emergency upgrade? In-Reply-To: References: Message-ID: On 06 Feb 2013, at 11:58 AM, Ray Wong wrote: > Does anyone have details on tonight's apparent worldwide emergency > router upgrade? All I managed to get out of the portal was 30 minutes, > "Service Affecting" (no kidding?) and the NOC line gave me the > recording about it and disconnected me. Nothing confirmed from my side, but the general guess I saw was that it was Juniper-related. -J From bortzmeyer at nic.fr Wed Feb 6 11:11:27 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 6 Feb 2013 12:11:27 +0100 Subject: Level3 worldwide emergency upgrade? In-Reply-To: References: Message-ID: <20130206111127.GA7590@nic.fr> On Wed, Feb 06, 2013 at 01:04:40PM +0200, JP Viljoen wrote a message of 10 lines which said: > the general guess I saw was that it was Juniper-related. Juniper Technical Bulletin PSN-2013-01-823, probably? From james at freedomnet.co.nz Wed Feb 6 11:13:39 2013 From: james at freedomnet.co.nz (james jones) Date: Wed, 6 Feb 2013 06:13:39 -0500 Subject: Level3 worldwide emergency upgrade? In-Reply-To: References: Message-ID: ugh! On Wed, Feb 6, 2013 at 6:04 AM, JP Viljoen wrote: > On 06 Feb 2013, at 11:58 AM, Ray Wong wrote: > > Does anyone have details on tonight's apparent worldwide emergency > > router upgrade? All I managed to get out of the portal was 30 minutes, > > "Service Affecting" (no kidding?) and the NOC line gave me the > > recording about it and disconnected me. > > Nothing confirmed from my side, but the general guess I saw was that it > was Juniper-related. > > -J > From jason at biel-tech.com Wed Feb 6 11:21:11 2013 From: jason at biel-tech.com (Jason Biel) Date: Wed, 6 Feb 2013 05:21:11 -0600 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <20130206111127.GA7590@nic.fr> References: <20130206111127.GA7590@nic.fr> Message-ID: That is general guess. On Wed, Feb 6, 2013 at 5:11 AM, Stephane Bortzmeyer wrote: > On Wed, Feb 06, 2013 at 01:04:40PM +0200, > JP Viljoen wrote > a message of 10 lines which said: > > > the general guess I saw was that it was Juniper-related. > > Juniper Technical Bulletin PSN-2013-01-823, probably? > > -- Jason From bret at getjive.com Wed Feb 6 11:29:56 2013 From: bret at getjive.com (Bret Palsson) Date: Wed, 6 Feb 2013 04:29:56 -0700 Subject: Level3 worldwide emergency upgrade? In-Reply-To: References: <20130206111127.GA7590@nic.fr> Message-ID: <6F1D92EB-DE2D-4846-BA6A-8E0A0CB17D4D@getjive.com> I just received this email from level3 ---- Summary Level 3 Communications will perform a mandatory network upgrade that will be service impacting and will impact devices in multiple locations. We are upgrading the code on portions of the global network to increase stability for the overall network. During this maintenance activity customers may be impacted for approximately 30 minutes. Updates This window of this maintenance has completed successfully. ---- On Feb 6, 2013, at 4:21 AM, Jason Biel wrote: > That is general guess. > > On Wed, Feb 6, 2013 at 5:11 AM, Stephane Bortzmeyer wrote: > >> On Wed, Feb 06, 2013 at 01:04:40PM +0200, >> JP Viljoen wrote >> a message of 10 lines which said: >> >>> the general guess I saw was that it was Juniper-related. >> >> Juniper Technical Bulletin PSN-2013-01-823, probably? >> >> > > > -- > Jason From peterehiwe at gmail.com Wed Feb 6 11:38:54 2013 From: peterehiwe at gmail.com (Peter Ehiwe) Date: Wed, 6 Feb 2013 12:38:54 +0100 Subject: Level3 worldwide emergency upgrade? In-Reply-To: References: Message-ID: Also received same ... On Wed, Feb 6, 2013 at 10:58 AM, Ray Wong wrote: > Does anyone have details on tonight's apparent worldwide emergency > router upgrade? All I managed to get out of the portal was 30 minutes, > "Service Affecting" (no kidding?) and the NOC line gave me the > recording about it and disconnected me. > > -R> > > -- Warm Regards Peter(CCIE 23782). From jared at puck.nether.net Wed Feb 6 12:39:14 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 6 Feb 2013 07:39:14 -0500 Subject: Level3 worldwide emergency upgrade? In-Reply-To: References: Message-ID: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> On Feb 6, 2013, at 6:38 AM, Peter Ehiwe wrote: > Also received same ... > > On Wed, Feb 6, 2013 at 10:58 AM, Ray Wong wrote: > >> Does anyone have details on tonight's apparent worldwide emergency >> router upgrade? All I managed to get out of the portal was 30 minutes, >> "Service Affecting" (no kidding?) and the NOC line gave me the >> recording about it and disconnected me. So, I'm wondering what is shocking that someone may have to push out some sort of upgrade either urgently or periodically that is so impacting and causes these emails on the list. There seems to be some sort of psychological event happening in addition to the technological one. In the past I've had to push out software fixes "urgently" due to various reasons, either being a software thing like the PSN or some weird hardware+software interaction that causes bad things to happen. Would you rather your ISP not maintain their devices? Are the consequences "so bad" of a 30 minute outage that your business is severely impacted? - Jared From alex at corp.nac.net Wed Feb 6 12:57:06 2013 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 6 Feb 2013 07:57:06 -0500 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB81E65E5D82C@EXCHMBX.hq.nac.net> > Would you rather your ISP not maintain their devices? Are the > consequences "so bad" of a 30 minute outage that your business > is severely impacted? > > - Jared You had me up until that line. That should be expanded a little ... First, I'd say, yes - many businesses would be severely impacted and may even have consequential issues if they had to sustain a 30 minute outage. Suppose for a moment they couldn't process money machines transactions for 30 minutes; or Netflix couldn't serve content for 30 minutes; or youporn was offline for 30 minutes. The question should be more along the lines of, "why aren't you multihomed in a way that would make a 30 minute outage (which is inevitable) irrelevant to you? From jtowne at slic.com Wed Feb 6 13:10:15 2013 From: jtowne at slic.com (Jonathan Towne) Date: Wed, 6 Feb 2013 08:10:15 -0500 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB81E65E5D82C@EXCHMBX.hq.nac.net> References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <2D0AF14BA6FB334988BC1F5D4FC38CB81E65E5D82C@EXCHMBX.hq.nac.net> Message-ID: <20130206131015.GE20536@hijacked.us> On Wed, Feb 06, 2013 at 07:57:06AM -0500, Alex Rubenstein scribbled: # The question should be more along the lines of, "why aren't you multihomed in a way that would make a 30 minute outage (which is inevitable) irrelevant to you? The fun part of this emergency maintenance in the northeast USA was that even folks who are multihomed felt it: Level3 managed to do this in a way that kept BGP sessions up but killed the ability to actually pass traffic. I'm not sure what they did that caused this, or whether anyone but northeast folks were affected by it, but it sure was neat to be effectively blackholed in and out of one of your provided circuits for a while. Also, in the northeast, they managed to make it quite a bit more than a 30min outage for many people; they even slid hours outside of their advertised emergency window. I do applaud them for what I can only assume was a *massive* undertaking: emergency upgrading that many routers in such a short period of time. -- Jonathan Towne From joly at punkcast.com Wed Feb 6 13:10:46 2013 From: joly at punkcast.com (Joly MacFie) Date: Wed, 6 Feb 2013 08:10:46 -0500 Subject: WEBCAST TODAY - FCC Network Resiliency Workshop Message-ID: I know this is a topic dear to the members of the list. We are webcasting an FCC hearing today in Brooklyn on the topic of network resiliency. http://isoc-ny.org/p2/4783 It will be archived, and transcribed. -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From jared at puck.nether.net Wed Feb 6 13:28:19 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 6 Feb 2013 08:28:19 -0500 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB81E65E5D82C@EXCHMBX.hq.nac.net> References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <2D0AF14BA6FB334988BC1F5D4FC38CB81E65E5D82C@EXCHMBX.hq.nac.net> Message-ID: On Feb 6, 2013, at 7:57 AM, Alex Rubenstein wrote: >> Would you rather your ISP not maintain their devices? Are the >> consequences "so bad" of a 30 minute outage that your business >> is severely impacted? >> >> - Jared > > You had me up until that line. > > That should be expanded a little ... > > First, I'd say, yes - many businesses would be severely impacted and may even have consequential issues if they had to sustain a 30 minute outage. Suppose for a moment they couldn't process money machines transactions for 30 minutes; or Netflix couldn't serve content for 30 minutes; or youporn was offline for 30 minutes. > > The question should be more along the lines of, "why aren't you multihomed in a way that would make a 30 minute outage (which is inevitable) irrelevant to you? Yeah, perhaps not as elegantly worded as I would have hoped, but there are many reasons things "go down". Just one of those elements is the internet part, there's also transport, power, and other elements that combine to make this complex system called the internet. If you N+N or N+1 your power, perhaps something similar for your connectivity is important. Or you just plan to be down/broken periodically for 30 minutes and have a plan to cover that. The building where our NOC is located sometimes gets evacuated. Having a plan for that is important. During one visit, there was a small fire in the building (or so we were told). Certainly an unexpected event that disrupted us for ~30 minutes. The handling and response of these events certainly is important. I do want to understand why and how it's so bad so if there are things as a SP in the community we can improve upon we can do that. That's my real goal, not poking at people who are single homed and down. - Jared From alex at corp.nac.net Wed Feb 6 13:50:03 2013 From: alex at corp.nac.net (Alex Rubenstein) Date: Wed, 6 Feb 2013 08:50:03 -0500 Subject: Level3 worldwide emergency upgrade? In-Reply-To: References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <2D0AF14BA6FB334988BC1F5D4FC38CB81E65E5D82C@EXCHMBX.hq.nac.net> Message-ID: <2D0AF14BA6FB334988BC1F5D4FC38CB81E65E5D84F@EXCHMBX.hq.nac.net> > Yeah, perhaps not as elegantly worded as I would have hoped, but there are > many reasons things "go down". Just one of those elements is the internet > part, there's also transport, power, and other elements that combine to > make this complex system called the internet. If you N+N or N+1 your > power, perhaps something similar for your connectivity is important. Or you > just plan to be down/broken periodically for 30 minutes and have a plan to > cover that. Agreed. > The building where our NOC is located sometimes gets evacuated. Having a > plan for that is important. During one visit, there was a small fire in the > building (or so we were told). Certainly an unexpected event that disrupted > us for ~30 minutes. And, if it is important to you, you will have N+N NOC's - ie, more than one, and different buildings, cities, or countries, depending on your requirement. > The handling and response of these events certainly is important. I do want > to understand why and how it's so bad so if there are things as a SP in the > community we can improve upon we can do that. I suspect, as I touched previously, the most noise will come from the people who are the least realistic, and least prepared. Personally, I live with the expectation that whatever it is (power, fiber, transport, ISP, highways, fuel delivery, etc.) will at some point be broken, degraded, or otherwise unavailable, and you have to plan accordingly. Personally (and I speak for NAC) I/we don't care, really, if any upstream IP provider breaks; we have made appropriate plans to work around that in an automated fashion. Hope that answers your more general question. From thaitim43 at hotmail.com Wed Feb 6 14:39:00 2013 From: thaitim43 at hotmail.com (Tim Haak) Date: Wed, 6 Feb 2013 09:39:00 -0500 Subject: AT&T Uverse/DSL Network Engineer DNS question In-Reply-To: References: , Message-ID: Thanks for checking guys. I checked RIR registration and they have those 2 IPs registered in Texas. I have read that AT&T uses anycast for name resolution for Uverse/DSL customers. I can only check from my account in Florida and the DNS query responses so far resolve as if I were in the Central United States because the recursive resolvers are registered in Texas, I as far as I can tell. I just need to know if these are the only DNS server IPs they hand out to their Uverse/DSL customers. Thanks, Tim Haak > From: wbailey at satelliteintelligencegroup.com > To: jof at thejof.com; tim.haak at hotmail.com > Subject: Re: AT&T Uverse/DSL Network Engineer DNS question > Date: Tue, 5 Feb 2013 21:15:46 +0000 > CC: nanog at nanog.org > > Here in Orange County, CA I've got a /28 with Uverse Residential with the > same DNS servers as mentioned below. > > FYI > > On 2/5/13 1:10 PM, "Jonathan Lassoff" wrote: > > >These appear to be an anycasted service, as I reach different destinations > >based on my source address. > > > >Hopefully each deployment has unique origin IPs for their recursive > >queries. > > > >I would recommend against looking at RIR registration data to determine IP > >location. There's often little to no correlation, there. > > > >--j > > > >On Tue, Feb 5, 2013 at 1:01 PM, Tim Haak wrote: > > > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Hi, > >> > >> > >> > >> > >> Can a AT&T Uverse/DSL Network Engineer answer a question about the DNS > >> server IPs that are handed out to customers please? I am currently > >>testing > >> from > >> a Florida IP. Can you please let me know if all Uverse and DSL customers > >> across the United States only use these 2 IPs as their primary and > >> secondary > >> DNS servers? > >> > >> > >> > >> 68.94.156.1 > >> > >> 68.94.157.1 > >> > >> > >> > >> We > >> provide services based on IP GEO-location. Since the 2 recursive > >>resolvers > >> below are registered in Texas every DNS query for any of our records > >>return > >> results that are intended for IPs in that region. In other words, users > >>on > >> the > >> east coast would actually resolve to a central part of the US or west > >> coast IP. > >> > >> > >> > >> Thanks > >> in advance,Tim > >> > >> > >> > >> > > > > > From khelms at zcorum.com Wed Feb 6 14:41:13 2013 From: khelms at zcorum.com (Scott Helms) Date: Wed, 6 Feb 2013 09:41:13 -0500 Subject: Metro Ethernet, VPLS clarifications In-Reply-To: <5111D3E1.3000904@gmail.com> References: <51108551.7090700@gmail.com> <5111D3E1.3000904@gmail.com> Message-ID: > > From my understanding M-Ethernet is a some kind of service. Standartized > technology that allows to connect multiple different networks. And it is > independent from physical and datalink layers. > Metro Ethernet is a datalink (layer 2) protocol. It also has physical (layer 1) specifications though there are several kinds of physical medium that can be used. Most commonly its delivered over fiber (single or multi-mode depending on distance from the last active element) or cat 5E/6 twisted pair. > And nowadays which tecnology is the most used(VPLS or Metro)? What about > MPLS? Sorry I'm a little confused. I really want to understand. > VPLS can be run across several different kinds of layer 1 & 2 technologies and is independent of the underlying technology because it builds it pseudo wires at layers 3 & 4. VPLS leverages technologies like Metro Ethernet and MPLS to extend a business' Ethernet LAN (technically the broadcast domain) to remote sites. At the end of the day you can use several kinds of tunneling technologies to provide VPLS, including GRE, MPLS, and L2TPv3. Here are the main two RFCs: http://tools.ietf.org/html/rfc4761 http://tools.ietf.org/html/rfc4762 > > > -- > Regards, > > Abzal > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From rs at seastrom.com Wed Feb 6 14:46:44 2013 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 06 Feb 2013 09:46:44 -0500 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: (Scott Helms's message of "Wed, 30 Jan 2013 13:54:06 -0500") References: <3812321.200.1359569919347.JavaMail.art@DQT6ZQ1> Message-ID: <86txppqz3f.fsf@seastrom.com> Scott Helms writes: > In that case its even harder. Before you even consider doing open > access talk to your FTTx vendor and find out how many they have done > using the same architecture you're planning on deploying. Open access > in an active Ethernet install is actually fairly straight forward but > on a PON system its harder than a DOCSIS network. Categorically untrue. It is all a matter of where the splitters are placed. A home run fiber plant architecture with an enormous patch frame and splitters provided by the open access provider if PON is their technoogy of choice is indistinguishable from an active ethernet install from an open access perspective. -r From khelms at zcorum.com Wed Feb 6 15:06:19 2013 From: khelms at zcorum.com (Scott Helms) Date: Wed, 6 Feb 2013 10:06:19 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <24791995.4964.1360081830800.JavaMail.root@benjamin.baylink.com> Message-ID: > However, for any given ring, you are locked into a single technology and > you have to put active electronics out in the field. > Correct, but you can have many layer 2 rings riding your physical ring. In a normal install you're going to have over a hundred fibers in your physical ring, I'd personally build it with over two hundred, but that's just me. Here's the Graybar catalog with a good breakdown of the kinds of fiber you can choose from, though you have to have a rep to get pricing: http://www.graybar.com/documents/graybar-sps-osp.pdf > > You can't, given a ring architecture, provide dark fiber leases. > That's incorrect, you simply don't have as many available but in a current "normal" build you could easily provide 100+ dark fiber leases that extend from your MDF (still don't like using this term here) all the way down to the home or business. > I realize it is your argument that one doesn't need to do so, there's no > market > for it, etc. However, I don't agree with you. > No, my argument is that the demand for dark fiber is very low and so building your network so you can provide every single connection as dark fiber is wasteful. > > Sure, but, you're ring only works with things that do L2 aggregation in the > field with active electronics in the field. This means that for any L2 > technology > a particular subscriber wants to use, you need to either already have that > L2 > technology deployed on a ring, or, you need to deploy another ring to > support > that technology. > First, exactly how many and what Layer 2 technologies BESIDES Ethernet do you think you have a market for? > > > > VPNs are popular today (whether MPLS, IPSEC, or otherwise) because > L1 connections are expensive and VPNS are (relatively) cheap. > > If dark fiber can be provided for $30/month per termination (we've already > agreed that the cost is $20 or less), that changes the equation quite a > bit. > If, as a business, I can provide corporate connectivity and internet access > to my employees for $30/month/employee without having to use a VPN, > but just 802.1q trunking and providing them a router (or switch) that has > different ports for Corporate and Personal LANs in their house, that > changes the equation quite a bit. > First, there are very few businesses in the size town we've been discussing that even have this scenario as a wish list item. Second, how many businesses that need/want remote connectivity for their workers at home AREN'T running Ethernet on their corporate LAN and at the employees' home? Another thing to remember is that many businesses run VPNs because of the encryption and controls it provides, not because they can't get or afford direct connectivity. You have a vanishingly small set of potential customers IMO. > > Admittedly, this only works for the employees that live within range, but > it's an example of the kinds of services that nobody even imagines today > because we can't get good L1 services cheap yet. > This is the key point. IF someone was able to put together a nationwide or even regional offering to allow inexpensive Layer 1 connectivity things would be different. However, that's not going to happen AND we already have good cheap solutions to deal with that. Most commonly VPLS over GRE or VPN whose only real cost beyond the basic home Internet connection, is a ~$350 CPE that supports the protocol. So, if you're running a company with regional or nationwide offices and home workers would you be attracted to a more limited method of connection that is only available in certain areas as opposed to the solution that works everywhere? Which is easier for your IT staff to support? > Sure, but elsewhere you've pointed out that the last 20 yards are where > most > of the problems occur? Guess what? The last 20 yards should be the service > provider, not the L1 in this case. If you're worried that the tech will > blame problems > in the last 20 yards on the prem. loop, that's a matter of teaching them > where > to plug in the box for testing the L1 loop. > > MMR-------[B-Box]------[Customer Patch]------[IW Termination] > > 1. Plug into IW Termination > If it works, great, you're done. If not: > > 2. Plug into Customer Patch. > If it works, problem is isolated to the IW side of things, > not the > muni's responsibility. > > If it doesn't, contact the muni and schedule a joint visit > to > troubleshoot. Muni will provide an OTDR. Any > modulation-specific > diagnostic gear to be provided by the service provider. > > I'm willing to bet that I could teach this to the average installer in a > matter > of minutes. > I'm not gonna argue the troubleshooting point anymore, far be it for me to deny you the opportunity to hit your own thumb and learn the lesson that way. -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From fdelmotte1 at mac.com Wed Feb 6 15:07:28 2013 From: fdelmotte1 at mac.com (Fabien Delmotte) Date: Wed, 06 Feb 2013 16:07:28 +0100 Subject: Metro Ethernet, VPLS clarifications In-Reply-To: References: <51108551.7090700@gmail.com> <5111D3E1.3000904@gmail.com> Message-ID: Hi, My 2 cents > VPLS can be run across several different kinds of layer 1 & 2 technologies > and is independent of the underlying technology because it builds it pseudo > wires at layers 3 & 4. VPLS leverages technologies like Metro Ethernet and > MPLS to extend a business' Ethernet LAN (technically the broadcast domain) > to remote sites. At the end of the day you can use several kinds of > tunneling technologies to provide VPLS, including GRE, MPLS, and L2TPv3. For fun you can also do : LDP VPLS over a GRE tunnel LDP over a GRE tunnel within an encrypted network I can be wrong but VPLS is running over MPLS (rfc 4762) because it is using LDP Regards Fabien Le 6 f?vr. 2013 ? 15:41, Scott Helms a ?crit : >> >> From my understanding M-Ethernet is a some kind of service. Standartized >> technology that allows to connect multiple different networks. And it is >> independent from physical and datalink layers. >> > > Metro Ethernet is a datalink (layer 2) protocol. It also has physical > (layer 1) specifications though there are several kinds of physical medium > that can be used. Most commonly its delivered over fiber (single or > multi-mode depending on distance from the last active element) or cat 5E/6 > twisted pair. > > > >> And nowadays which tecnology is the most used(VPLS or Metro)? What about >> MPLS? Sorry I'm a little confused. I really want to understand. >> > > VPLS can be run across several different kinds of layer 1 & 2 technologies > and is independent of the underlying technology because it builds it pseudo > wires at layers 3 & 4. VPLS leverages technologies like Metro Ethernet and > MPLS to extend a business' Ethernet LAN (technically the broadcast domain) > to remote sites. At the end of the day you can use several kinds of > tunneling technologies to provide VPLS, including GRE, MPLS, and L2TPv3. > > Here are the main two RFCs: > > http://tools.ietf.org/html/rfc4761 > http://tools.ietf.org/html/rfc4762 > > >> >> >> -- >> Regards, >> >> Abzal >> >> > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- From asullivan at dyn.com Wed Feb 6 15:10:37 2013 From: asullivan at dyn.com (Andrew Sullivan) Date: Wed, 6 Feb 2013 10:10:37 -0500 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> Message-ID: <20130206151037.GJ27306@dyn.com> On Wed, Feb 06, 2013 at 07:39:14AM -0500, Jared Mauch wrote: > > So, I'm wondering what is shocking that someone may have to push out some sort of upgrade either urgently or periodically that is so impacting and causes these emails on the list. > My impression is mostly that people are left feeling uncomfortable by a massive upgrade of this sort with so little communication about why and so on. "Emergency work for five hours and 30 minutes disconnection" that turns out to take longer than 30 minutes of disconnection probably ought to come with some explanation (at least after the fact). Regards, A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From khelms at zcorum.com Wed Feb 6 15:10:41 2013 From: khelms at zcorum.com (Scott Helms) Date: Wed, 6 Feb 2013 10:10:41 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> References: <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> Message-ID: On Tue, Feb 5, 2013 at 9:40 PM, Eric Wieling wrote: > The ILECs basically got large portions of the 1996 telecom reform rules > gutted via lawsuits. DSL unbundling was part of this. See > http://quello.msu.edu/sites/default/files/pdf/wp-05-02.pdf The ILECs > already need a DSLAM in each CO and already use ATM PVCs to provide L2 > connectivity from the DSLAM to their IP network, I don't think it is that > much more expensive to allow other ISPs an ATM PVC into their network. > ATM may not be the best technology to do this, but the basic concept is not > bad. Ethernet VLANs would be another option, as would Frame Relay, as > would simply DAXing multiple 64k channels from the customer endpoint to the > ISP if you want more L1 style connectivity. > Generally the way this was done by all of the RBOCs (except Qwest) was via a L2TP tunnel to hand off the PPPoE/oA tunnel prior to it being authenticated. The connections from BellSouth and some of the other operators was ATM but that was because they didn't want to have to do SAR on all those frames/cells on their existing gear. > > What *I* want as an ISP is to connect to customers, I don't care what the > local loop is. It could be fiber, twisted pair, coax, or even licensed > wireless and hand it off to me over a nice fat fiber link with a PVC or > VLAN or whatever to the customer endpoint. What I don't want is to have > to install equipment at each and every CO I want to provide service out of. > This would be astoundingly expensive for us. > This is what I see most commonly. > > -----Original Message----- > From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] > Sent: Tuesday, February 05, 2013 7:42 PM > To: nanog at nanog.org > Subject: Re: Muni fiber: L1 or L2? > > Eric Wieling wrote: > > > In the past the ISP simply needed a nice big ATM pipe to the > > ILEC for DSL service. The ILEC provided a PVC from the > > customer endpoint to the ISP. As understand it this is no longer the > > case, but only because of non-technical issues. > > The non-technical issue is *COST*!!!!! > > No one considered to use so expensive ATM as L2 for DSL unbundling, at > least in Japan, which made DSL in Japan quite inexpensive. > AFAIK all ADSL is ATM at layer 2, including Japan. Did they deploy a different DSL technology there? > > > We currently use XO, Covad, etc to connect to the customer We get a > > fiber connection to them and the provide use L2 connectivity to the > > custom endpoint using an Ethernet VLAN, > > Frame Relay PVC, etc complete with QoS. I assume XO, > > etc use UNE access to the local loop. There is no reason > > a Muni can't do something similar. > > Muni can. However, there is no reason Muni can't offer L1 unbundling. > > Masataka Ohta > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Wed Feb 6 15:12:46 2013 From: khelms at zcorum.com (Scott Helms) Date: Wed, 6 Feb 2013 10:12:46 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <51120B49.80606@necom830.hpcl.titech.ac.jp> References: <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> Message-ID: On Wed, Feb 6, 2013 at 2:50 AM, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > Eric Wieling wrote: > > > I don't think it is that much more expensive to allow other > > ISPs an ATM PVC into their network. > > Wrong, which is why ATM has disappeared. > > > ATM may not be the best technology to do this, > > It is not. > Actually, at the level that Eric's discussing there isn't any real drawback to using ATM. There's no particular upside either, but it certainly works and depending on the gear you're getting your L2TP feed on it may be the best choice. > > > but the basic concept is not bad. > > It is not enough, even if you use inexpensive Ethernet. See > the subject. > Why? > > > What *I* want as an ISP is to connect to customers, > > You may. However, the customers care cost for you to do so, a lot. > > L1 unbundling allows the customers to choose an ISP with best > (w.r.t. cost, performance, etc.) L2 and L3 technology, whereas > L2 unbundling allows ILECs choose stupid L2 technologies such > as ATM or PON, which is locally best for their short term > revenue, which, in the long run, delays global deployment of > broadband environment, because of high cost to the customers. > > Masataka Ohta > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Wed Feb 6 15:15:46 2013 From: khelms at zcorum.com (Scott Helms) Date: Wed, 6 Feb 2013 10:15:46 -0500 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: <86txppqz3f.fsf@seastrom.com> References: <3812321.200.1359569919347.JavaMail.art@DQT6ZQ1> <86txppqz3f.fsf@seastrom.com> Message-ID: On Wed, Feb 6, 2013 at 9:46 AM, Robert E. Seastrom wrote: > > Scott Helms writes: > > > In that case its even harder. Before you even consider doing open > > access talk to your FTTx vendor and find out how many they have done > > using the same architecture you're planning on deploying. Open access > > in an active Ethernet install is actually fairly straight forward but > > on a PON system its harder than a DOCSIS network. > > Categorically untrue. It is all a matter of where the splitters are > placed. > You're confounding the layers of the network or perhaps I was being unclear that I was talking about Layer 2 handoffs. > A home run fiber plant architecture with an enormous patch frame and > splitters provided by the open access provider if PON is their > technoogy of choice is indistinguishable from an active ethernet > install from an open access perspective. > Again, I was speaking about Layer 2 open access. > -r > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From EWieling at nyigc.com Wed Feb 6 15:16:19 2013 From: EWieling at nyigc.com (Eric Wieling) Date: Wed, 6 Feb 2013 10:16:19 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <51120B49.80606@necom830.hpcl.titech.ac.jp> References: <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> Message-ID: <616B4ECE1290D441AD56124FEBB03D0810FE54251A@mailserver2007.nyigc.globe> Can anyone out there in NANOGland confirm how ILECs currently backhaul their DSL customers from the DSLAM to the ILECs IP network? -----Original Message----- From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] Sent: Wednesday, February 06, 2013 2:51 AM To: nanog at nanog.org Subject: Re: Muni fiber: L1 or L2? Eric Wieling wrote: > I don't think it is that much more expensive to allow other ISPs an > ATM PVC into their network. Wrong, which is why ATM has disappeared. > ATM may not be the best technology to do this, It is not. > but the basic concept is not bad. It is not enough, even if you use inexpensive Ethernet. See the subject. > What *I* want as an ISP is to connect to customers, You may. However, the customers care cost for you to do so, a lot. L1 unbundling allows the customers to choose an ISP with best (w.r.t. cost, performance, etc.) L2 and L3 technology, whereas L2 unbundling allows ILECs choose stupid L2 technologies such as ATM or PON, which is locally best for their short term revenue, which, in the long run, delays global deployment of broadband environment, because of high cost to the customers. Masataka Ohta From adam.vitkovsky at swan.sk Wed Feb 6 15:19:07 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Wed, 6 Feb 2013 16:19:07 +0100 Subject: Metro Ethernet, VPLS clarifications In-Reply-To: References: <51108551.7090700@gmail.com> <5111D3E1.3000904@gmail.com> Message-ID: <00e501ce047d$4eccc9b0$ec665d10$@swan.sk> And for fun you can also do: Ethernet over PBB to VPLS Ethernet over PBB over VPLS -that's actually called EVPN adam -----Original Message----- From: Fabien Delmotte [mailto:fdelmotte1 at mac.com] Sent: Wednesday, February 06, 2013 4:07 PM To: Scott Helms Cc: NANOG; Abzal Sembay Subject: Re: Metro Ethernet, VPLS clarifications Hi, My 2 cents > VPLS can be run across several different kinds of layer 1 & 2 > technologies and is independent of the underlying technology because > it builds it pseudo wires at layers 3 & 4. VPLS leverages technologies > like Metro Ethernet and MPLS to extend a business' Ethernet LAN > (technically the broadcast domain) to remote sites. At the end of the > day you can use several kinds of tunneling technologies to provide VPLS, including GRE, MPLS, and L2TPv3. For fun you can also do : LDP VPLS over a GRE tunnel LDP over a GRE tunnel within an encrypted network I can be wrong but VPLS is running over MPLS (rfc 4762) because it is using LDP Regards Fabien Le 6 f?vr. 2013 ? 15:41, Scott Helms a ?crit : >> >> From my understanding M-Ethernet is a some kind of service. >> Standartized technology that allows to connect multiple different >> networks. And it is independent from physical and datalink layers. >> > > Metro Ethernet is a datalink (layer 2) protocol. It also has physical > (layer 1) specifications though there are several kinds of physical > medium that can be used. Most commonly its delivered over fiber > (single or multi-mode depending on distance from the last active > element) or cat 5E/6 twisted pair. > > > >> And nowadays which tecnology is the most used(VPLS or Metro)? What >> about MPLS? Sorry I'm a little confused. I really want to understand. >> > > VPLS can be run across several different kinds of layer 1 & 2 > technologies and is independent of the underlying technology because > it builds it pseudo wires at layers 3 & 4. VPLS leverages technologies > like Metro Ethernet and MPLS to extend a business' Ethernet LAN > (technically the broadcast domain) to remote sites. At the end of the > day you can use several kinds of tunneling technologies to provide VPLS, including GRE, MPLS, and L2TPv3. > > Here are the main two RFCs: > > http://tools.ietf.org/html/rfc4761 > http://tools.ietf.org/html/rfc4762 > > >> >> >> -- >> Regards, >> >> Abzal >> >> > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- From jra at baylink.com Wed Feb 6 15:28:10 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 6 Feb 2013 10:28:10 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: Message-ID: <24552227.5119.1360164490523.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > > However, for any given ring, you are locked into a single technology > > and you have to put active electronics out in the field. > > Correct, but you can have many layer 2 rings riding your physical ring. In > a normal install you're going to have over a hundred fibers in your > physical ring, I'd personally build it with over two hundred, but > that's just me. And I would personally not design something where the physical layout locks you into a specific *category* of technology (active equipment in the field), but that's just me. :-) > Here's the Graybar catalog with a good breakdown of the kinds of fiber > you can choose from, though you have to have a rep to get pricing: > > http://www.graybar.com/documents/graybar-sps-osp.pdf Nice reference, added to my list; thanks. > > You can't, given a ring architecture, provide dark fiber leases. > > That's incorrect, you simply don't have as many available but in a current > "normal" build you could easily provide 100+ dark fiber leases that extend > from your MDF (still don't like using this term here) all the way down > to the home or business. And, conversely, I could, actually, *build a ring atop home run*; it would just be a folded ring, where the active gear is at the end of each run. > > I realize it is your argument that one doesn't need to do so, > > there's no market for it, etc. However, I don't agree with you. > > No, my argument is that the demand for dark fiber is very low and so > building your network so you can provide every single connection as > dark fiber is wasteful. Doing things which are not quite cost effective *yet* is pretty much the *hallmark* of government, is it not? Hybrid car tax breaks, Solar PV install tax breaks... these things are all subsidies to the consumer cost of a technology, so as to increase its uptake and push it onto the consumer-cost S-curve; this is a government practice with at least a century long history. It's pretty much what I'm trying to accomplish here. And thanks for teasing that thought out of my head, so I can make sure it's in my internal sales pitch. :-) > First, exactly how many and what Layer 2 technologies BESIDES Ethernet > do you think you have a market for? GPON/DOCSIS/RFoG? That's one people are deploying today. Over the 50 year proposed lifetime of the plant? WTF knows. That's exactly the point. To paraphrase Tom Peters, you don't look like a trailbreaker by *emulating what other trailbreakers have done*. I'm not *trying* to do the last thing. I'm trying to do the next thing. Or maybe the one after that. > First, there are very few businesses in the size town we've been discussing > that even have this scenario as a wish list item. "...now." > Second, how many > businesses that need/want remote connectivity for their workers at home > AREN'T running Ethernet on their corporate LAN and at the employees' home? Course they are. > Another thing to remember is that many businesses run VPNs because of the > encryption and controls it provides, not because they can't get or afford > direct connectivity. You have a vanishingly small set of potential > customers IMO. Perhaps. But the *current* potential customer base does not merit locking in a limited design in a 50-year plant build. > > Admittedly, this only works for the employees that live within range, but > > it's an example of the kinds of services that nobody even imagines today > > because we can't get good L1 services cheap yet. > > This is the key point. IF someone was able to put together a nationwide or > even regional offering to allow inexpensive Layer 1 connectivity things > would be different. How, Scott, would you expect that sort of thing might happen? By people taking the first step? Yeah; thought so. My county doesn't have the same first-trencher advantage my city does... but it does have the advantage that *it is nearly 100% built out as well*; we are, I believe, the densest county *in the United States*; maybe Manhattan beats us. Maybe DC; maybe Suffolk County in Mass. So it's not at all impossible that we might be the first domino to fall; there are a lot of barrier island communities near me that would be similarly easy to fiber, since they're so one-dimensional. (Geographically; I'm sure their residents are quite nice. :-) > However, that's not going to happen AND we already > have good cheap solutions to deal with that. Most commonly VPLS over GRE > or VPN whose only real cost beyond the basic home Internet connection, > is a ~$350 CPE that supports the protocol. You're paying $350 for VPN routers? Could I be one of your vendors? > So, if you're running a company > with regional or nationwide offices and home workers would you be attracted > to a more limited method of connection that is only available in certain > areas as opposed to the solution that works everywhere? Which is easier for > your IT staff to support? Accurate, but not germane. They're not my target market. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From rs at seastrom.com Wed Feb 6 15:30:53 2013 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 06 Feb 2013 10:30:53 -0500 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: (Scott Helms's message of "Wed, 6 Feb 2013 10:15:46 -0500") References: <3812321.200.1359569919347.JavaMail.art@DQT6ZQ1> <86txppqz3f.fsf@seastrom.com> Message-ID: <86txpppihe.fsf@seastrom.com> If you were talking about layer 2 handoffs, your statement is perhaps even more untrue - active ethernet and PON layer 2 handoffs are approximately as easy as each other. -r PS: The word is _conflating_, not _confounding_. Scott Helms writes: > On Wed, Feb 6, 2013 at 9:46 AM, Robert E. Seastrom <[[rs at seastrom.com]]> > wrote: > > Scott Helms <[[khelms at zcorum.com]]> writes: > > > In that case its even harder. ?Before you even consider doing open > > access talk to your FTTx vendor and find out how many they have > done > > using the same architecture you're planning on deploying. ?Open > access > > in an active Ethernet install is actually fairly straight forward > but > > on a PON system its harder than a DOCSIS network. > > Categorically untrue. ?It is all a matter of where the splitters are > placed. > > > > > > You're confounding the layers of the network or perhaps I was being unclear > that I was talking about Layer 2 handoffs. > > > > A home run fiber plant architecture with an enormous patch > frame and > splitters provided by the open access provider if PON is their > technoogy of choice is indistinguishable from an active ethernet > install from an open access perspective. > > > > > > Again, I was speaking about Layer 2 open access. > > > > -r > > > > > > > > > > -- > > > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > [[http://twitter.com/kscotthelms]] > --------------------------------? From khelms at zcorum.com Wed Feb 6 15:32:15 2013 From: khelms at zcorum.com (Scott Helms) Date: Wed, 6 Feb 2013 10:32:15 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <616B4ECE1290D441AD56124FEBB03D0810FE54251A@mailserver2007.nyigc.globe> References: <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE54251A@mailserver2007.nyigc.globe> Message-ID: On Wed, Feb 6, 2013 at 10:16 AM, Eric Wieling wrote: > Can anyone out there in NANOGland confirm how ILECs currently backhaul > their DSL customers from the DSLAM to the ILECs IP network? > In the independent space this has been Ethernet for a very long time. In the RBOC space its taken longer, but my understanding is that they have also switched most of their connections. The only exceptions to this I am aware of are those AT&T and Verizon territories that are still limited to g.lite (1.5 mbps) ADSL. > > -----Original Message----- > From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] > Sent: Wednesday, February 06, 2013 2:51 AM > To: nanog at nanog.org > Subject: Re: Muni fiber: L1 or L2? > > Eric Wieling wrote: > > > I don't think it is that much more expensive to allow other ISPs an > > ATM PVC into their network. > > Wrong, which is why ATM has disappeared. > > > ATM may not be the best technology to do this, > > It is not. > > > but the basic concept is not bad. > > It is not enough, even if you use inexpensive Ethernet. See the subject. > > > What *I* want as an ISP is to connect to customers, > > You may. However, the customers care cost for you to do so, a lot. > > L1 unbundling allows the customers to choose an ISP with best (w.r.t. > cost, performance, etc.) L2 and L3 technology, whereas > L2 unbundling allows ILECs choose stupid L2 technologies such as ATM or > PON, which is locally best for their short term revenue, which, in the long > run, delays global deployment of broadband environment, because of high > cost to the customers. > > Masataka Ohta > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Wed Feb 6 15:36:08 2013 From: khelms at zcorum.com (Scott Helms) Date: Wed, 6 Feb 2013 10:36:08 -0500 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: <86txpppihe.fsf@seastrom.com> References: <3812321.200.1359569919347.JavaMail.art@DQT6ZQ1> <86txppqz3f.fsf@seastrom.com> <86txpppihe.fsf@seastrom.com> Message-ID: On Wed, Feb 6, 2013 at 10:30 AM, Robert E. Seastrom wrote: > > If you were talking about layer 2 handoffs, your statement is perhaps > even more untrue - active ethernet and PON layer 2 handoffs are > approximately as easy as each other. > Perhaps you'd share some specifics? I certainly haven't worked on all of the PON systems that are out there, but the ones I have worked one didn't have (or I didn't find) a good way to separate traffic at layer 2 so that several operators could handle their own Layer 3 provisioning for customers on the same OLT. > > -r > > PS: The word is _conflating_, not _confounding_. > > Scott Helms writes: > > > On Wed, Feb 6, 2013 at 9:46 AM, Robert E. Seastrom <[[rs at seastrom.com]]> > > wrote: > > > > Scott Helms <[[khelms at zcorum.com]]> writes: > > > > > In that case its even harder. Before you even consider doing open > > > access talk to your FTTx vendor and find out how many they have > > done > > > using the same architecture you're planning on deploying. Open > > access > > > in an active Ethernet install is actually fairly straight forward > > but > > > on a PON system its harder than a DOCSIS network. > > > > Categorically untrue. It is all a matter of where the splitters are > > placed. > > > > > > > > > > > > You're confounding the layers of the network or perhaps I was being > unclear > > that I was talking about Layer 2 handoffs. > > > > > > > > A home run fiber plant architecture with an enormous patch > > frame and > > splitters provided by the open access provider if PON is their > > technoogy of choice is indistinguishable from an active ethernet > > install from an open access perspective. > > > > > > > > > > > > Again, I was speaking about Layer 2 open access. > > > > > > > > -r > > > > > > > > > > > > > > > > > > > > -- > > > > > > Scott Helms > > Vice President of Technology > > ZCorum > > (678) 507-5000 > > -------------------------------- > > [[http://twitter.com/kscotthelms]] > > -------------------------------- > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From rayw at rayw.net Wed Feb 6 15:43:27 2013 From: rayw at rayw.net (Ray Wong) Date: Wed, 6 Feb 2013 07:43:27 -0800 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <20130206151037.GJ27306@dyn.com> References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <20130206151037.GJ27306@dyn.com> Message-ID: On Wed, Feb 6, 2013 at 7:10 AM, Andrew Sullivan wrote: > On Wed, Feb 06, 2013 at 07:39:14AM -0500, Jared Mauch wrote: >> >> So, I'm wondering what is shocking that someone may have to push out some sort of upgrade either urgently or periodically that is so impacting and causes these emails on the list. >> > > My impression is mostly that people are left feeling uncomfortable by > a massive upgrade of this sort with so little communication about why > and so on. "Emergency work for five hours and 30 minutes > disconnection" that turns out to take longer than 30 minutes of > disconnection probably ought to come with some explanation (at least > after the fact). > Especially in the wake they already recently did one. It's unsettling to receive little communication, and even multihomed, there's always the question of being pushed into overages around other providers. Yes, short notice maintenance does happen. Better communication happens much less often. I was more looking for details, i.e. the sort of problem this is, as it probably also means all my *other* providers are going to be scrambling in the next few days/weeks/months, depending on what gear they're all using. I'm out of the global infrastructure game myself for a few years currently, but I still have to think ahead to the network I do maintain. -R> From khelms at zcorum.com Wed Feb 6 15:54:59 2013 From: khelms at zcorum.com (Scott Helms) Date: Wed, 6 Feb 2013 10:54:59 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <24552227.5119.1360164490523.JavaMail.root@benjamin.baylink.com> References: <24552227.5119.1360164490523.JavaMail.root@benjamin.baylink.com> Message-ID: > > > > That's incorrect, you simply don't have as many available but in a > current > > "normal" build you could easily provide 100+ dark fiber leases that > extend > > from your MDF (still don't like using this term here) all the way down > > to the home or business. > > And, conversely, I could, actually, *build a ring atop home run*; it would > just be a folded ring, where the active gear is at the end of each run. > Yep, that's likely what will happen over the long term anyhow. That's why I asked about a new apartment building in your territory. You decision would be either run additional fiber to support each apartment as an end point, simply provide backhaul to some other provider, or put your own actives somewhere nearby. > > > > I realize it is your argument that one doesn't need to do so, > > > there's no market for it, etc. However, I don't agree with you. > > > > No, my argument is that the demand for dark fiber is very low and so > > building your network so you can provide every single connection as > > dark fiber is wasteful. > > Doing things which are not quite cost effective *yet* is pretty much > the *hallmark* of government, is it not? Hybrid car tax breaks, Solar > PV install tax breaks... these things are all subsidies to the consumer > cost of a technology, so as to increase its uptake and push it onto the > consumer-cost S-curve; this is a government practice with at least a > century long history. > > It's pretty much what I'm trying to accomplish here. And thanks for > teasing that thought out of my head, so I can make sure it's in my > internal sales pitch. :-) > All of those items have some chance of mass deployment. Mass deployment of Layer 1 connectivity in the US is much *much *less likely. > > > First, exactly how many and what Layer 2 technologies BESIDES Ethernet > > do you think you have a market for? > > GPON/DOCSIS/RFoG? That's one people are deploying today. > That question was in reference to commercial accounts not service providers. > > Over the 50 year proposed lifetime of the plant? WTF knows. That's > exactly the point. > > To paraphrase Tom Peters, you don't look like a trailbreaker by > *emulating what other trailbreakers have done*. > > I'm not *trying* to do the last thing. > > I'm trying to do the next thing. Or maybe the one after that. > > > First, there are very few businesses in the size town we've been > discussing > > that even have this scenario as a wish list item. > > "...now." > > > Second, how many > > businesses that need/want remote connectivity for their workers at home > > AREN'T running Ethernet on their corporate LAN and at the employees' > home? > > Course they are. > > > Another thing to remember is that many businesses run VPNs because of the > > encryption and controls it provides, not because they can't get or afford > > direct connectivity. You have a vanishingly small set of potential > > customers IMO. > > Perhaps. But the *current* potential customer base does not merit > locking in a limited design in a 50-year plant build. > > That's a business call, but like a lot of decisions you're making a ton of assumptions as well. You're assuming for example that the costs of running additional fibers won't go down significantly during that 50 year time span. You're assuming that the cost of DWDM gear won't go down sufficiently that running new fiber is simply not needed to support the new architecture. You're also assuming that Layer 1 will at some point have a reason for customer adoption when the entire world is working on Layer 3 methods of doing this. > > > Admittedly, this only works for the employees that live within range, > but > > > it's an example of the kinds of services that nobody even imagines > today > > > because we can't get good L1 services cheap yet. > > > > This is the key point. IF someone was able to put together a nationwide > or > > even regional offering to allow inexpensive Layer 1 connectivity things > > would be different. > > How, Scott, would you expect that sort of thing might happen? > > By people taking the first step? > > Yeah; thought so. > There are more "first steps" that are never followed up than people actually starting a trend. There is a guy in my neighborhood that swears we can all drive around in cars powered by recycled frying oil and he built one to prove it works. I should point out that your idea is not new nor are you the first to try to build something like this. > > My county doesn't have the same first-trencher advantage my city does... > but it does have the advantage that *it is nearly 100% built out as well*; > we are, I believe, the densest county *in the United States*; maybe > Manhattan beats us. Maybe DC; maybe Suffolk County in Mass. > > So it's not at all impossible that we might be the first domino to fall; > there are a lot of barrier island communities near me that would be > similarly > easy to fiber, since they're so one-dimensional. > > (Geographically; I'm sure their residents are quite nice. :-) > Today there are networks based on this premise in every state I've cared to check. Here in Georgia the independent phone companies formed a seperate organization called US Carrier (which was recently sold for much less than they put into it). The muni's formed a partnering (initially) network called MEAG that was later renamed to GA Public Web ( http://www.gapublicweb.net/). When the two were first constructed in the early 2000's they actually had a interconnects and could sell off each other's network, but that fell apart over time. > > > However, that's not going to happen AND we already > > have good cheap solutions to deal with that. Most commonly VPLS over GRE > > or VPN whose only real cost beyond the basic home Internet connection, > > is a ~$350 CPE that supports the protocol. > > You're paying $350 for VPN routers? > > Could I be one of your vendors? > VPLS and good remote management is well worth $350. > > > So, if you're running a company > > with regional or nationwide offices and home workers would you be > attracted > > to a more limited method of connection that is only available in certain > > areas as opposed to the solution that works everywhere? Which is easier > for > > your IT staff to support? > > Accurate, but not germane. They're not my target market. > Owen brought up that example. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Wed Feb 6 15:56:00 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 6 Feb 2013 10:56:00 -0500 (EST) Subject: Can OLTs separate port management by admin user? In-Reply-To: Message-ID: <32130872.5133.1360166160123.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > On Wed, Feb 6, 2013 at 10:30 AM, Robert E. Seastrom > wrote: > > If you were talking about layer 2 handoffs, your statement is perhaps > > even more untrue - active ethernet and PON layer 2 handoffs are > > approximately as easy as each other. > > Perhaps you'd share some specifics? I certainly haven't worked on all of > the PON systems that are out there, but the ones I have worked one didn't > have (or I didn't find) a good way to separate traffic at layer 2 so that > several operators could handle their own Layer 3 provisioning for customers > on the same OLT. I am speculating here, Scott, and perhaps Frank, who runs the boxes, will chime in, but my understanding of the Calix E series is that you can separate the *traffic* on a per port basis, even on the GPON cards, as to where that traffic is routed to, presumably by VLAN. I don't think, on rereading your post, that that's what you actually mean, though; I think you're asking about something which I myself got to yesterday afternoon: Can you separate the *control plan* on an ISP by ISP basis: is it possible to give ISPs whose clients are on specific ports of an access mux like an OLT *control over only those ports*, leaving card- and chassis- global functions for the L2 operator? (Possibly with the optimization of allowing card-global functions if all the ports on the card are owned by that operator, or unassigned.) It's a very good question, and the next nail I was going to hammer. I'm betting the answer is presently "no; you'll have to put a smart OAM&P layer in front of it", myself. Can anyone who's used such Access multiplexers comment on this? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From benny+usenet at amorsen.dk Wed Feb 6 15:54:40 2013 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Wed, 06 Feb 2013 16:54:40 +0100 Subject: Muni fiber: L1 or L2? In-Reply-To: <24552227.5119.1360164490523.JavaMail.root@benjamin.baylink.com> (Jay Ashworth's message of "Wed, 6 Feb 2013 10:28:10 -0500 (EST)") References: <24552227.5119.1360164490523.JavaMail.root@benjamin.baylink.com> Message-ID: Jay Ashworth writes: > GPON/DOCSIS/RFoG? That's one people are deploying today. > > Over the 50 year proposed lifetime of the plant? WTF knows. That's > exactly the point. > > To paraphrase Tom Peters, you don't look like a trailbreaker by > *emulating what other trailbreakers have done*. > > I'm not *trying* to do the last thing. > > I'm trying to do the next thing. Or maybe the one after that. The existing copper network was in many cases built like a star with some very long runs. This worked fine for telephony, but not so well with ADSL. The result is that providers move their active equipment closer to the subscriber. Is there a risk that up-and-coming technologies will depend on shorter fiber runs? Will the fiber be built in such a way that it joins up in places where it is possible to later add active equipment if that becomes desirable? /Benny From jra at baylink.com Wed Feb 6 16:01:27 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 6 Feb 2013 11:01:27 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: Message-ID: <3893202.5135.1360166487158.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Benny Amorsen" > > I'm not *trying* to do the last thing. > > > > I'm trying to do the next thing. Or maybe the one after that. > > The existing copper network was in many cases built like a star with > some very long runs. This worked fine for telephony, but not so well > with ADSL. The result is that providers move their active equipment > closer to the subscriber. Well, it worked poorly with ADSL *because* it actually worked poorly with voice, and they had to put load coils in to fix it. > Is there a risk that up-and-coming technologies will depend on shorter > fiber runs? Will the fiber be built in such a way that it joins up in > places where it is possible to later add active equipment if that > becomes desirable? I think that risk low enough to take it, especially since my entire city fits in about a 3mi radius. :-) No, I expect ranges to get *longer* per constant dollar spent, actually. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From joelja at bogus.com Wed Feb 6 16:04:23 2013 From: joelja at bogus.com (joel jaeggli) Date: Wed, 06 Feb 2013 08:04:23 -0800 Subject: Level3 worldwide emergency upgrade? In-Reply-To: References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <20130206151037.GJ27306@dyn.com> Message-ID: <51127F07.3090107@bogus.com> On 2/6/13 7:43 AM, Ray Wong wrote: > On Wed, Feb 6, 2013 at 7:10 AM, Andrew Sullivan wrote: >> On Wed, Feb 06, 2013 at 07:39:14AM -0500, Jared Mauch wrote: >>> So, I'm wondering what is shocking that someone may have to push out some sort of upgrade either urgently or periodically that is so impacting and causes these emails on the list. >>> >> My impression is mostly that people are left feeling uncomfortable by >> a massive upgrade of this sort with so little communication about why >> and so on. "Emergency work for five hours and 30 minutes >> disconnection" that turns out to take longer than 30 minutes of >> disconnection probably ought to come with some explanation (at least >> after the fact). >> > Especially in the wake they already recently did one. It's unsettling > to receive little communication, and even multihomed, there's always > the question of being pushed into overages around other providers. > > Yes, short notice maintenance does happen. Better communication > happens much less often. I recieved advance (24 hours) notification of maintenances over the last two days to circuits ranging in size from 100MB/s to 10Gb/s in about a dozen locations. I assumed there would be further disruption as devices I'm not directly connected to were touched. > > I was more looking for details, i.e. the sort of problem this is, as > it probably also means all my *other* providers are going to be > scrambling in the next few days/weeks/months, depending on what gear > they're all using. All your other providers using that vendor have been scrambling for about a week as well. Junos devices should be upgraded. > I'm out of the global infrastructure game myself > for a few years currently, but I still have to think ahead to the > network I do maintain. > > > -R> > From khelms at zcorum.com Wed Feb 6 16:14:41 2013 From: khelms at zcorum.com (Scott Helms) Date: Wed, 6 Feb 2013 11:14:41 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <3893202.5135.1360166487158.JavaMail.root@benjamin.baylink.com> References: <3893202.5135.1360166487158.JavaMail.root@benjamin.baylink.com> Message-ID: > > I think that risk low enough to take it, especially since my entire > city fits in about a 3mi radius. :-) > This is data I'd like to have had earlier, if your total diameter is 6 miles then the math will almost certainly work to home run everything, though I'd still run the numbers. > > No, I expect ranges to get *longer* per constant dollar spent, actually. > Are you legally or otherwise restricted from extending beyond the city limits in your state? > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Wed Feb 6 16:15:15 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 6 Feb 2013 11:15:15 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: Message-ID: <2820110.5141.1360167315419.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > Yep, that's likely what will happen over the long term anyhow. That's why > I asked about a new apartment building in your territory. You decision > would be either run additional fiber to support each apartment as an > end point, simply provide backhaul to some other provider, or put your own > actives somewhere nearby. In fact, there is *one* large multiunit in my city, and I don't believe that there is space for anymore; my CO location is *right across the street from that*. :-) If someone *does* want to put another in, they will have to pay for me to pull the new fiber to their lot; that's how we do it with other utilities. > > Doing things which are not quite cost effective *yet* is pretty much > > the *hallmark* of government, is it not? Hybrid car tax breaks, Solar > > PV install tax breaks... these things are all subsidies to the consumer > > cost of a technology, so as to increase its uptake and push it onto > > the consumer-cost S-curve; this is a government practice with at least a > > century long history. > > > > It's pretty much what I'm trying to accomplish here. And thanks for > > teasing that thought out of my head, so I can make sure it's in my > > internal sales pitch. :-) > > All of those items have some chance of mass deployment. Mass deployment of > Layer 1 connectivity in the US is much *much *less likely. For the about 19th time: *that isn't my goal*. My goal is "not limiting future technology developments of deployment". Homerun fiber merely happens to have "L1 access to providers" as a side benefit. > > > First, exactly how many and what Layer 2 technologies BESIDES > > > Ethernet > > > do you think you have a market for? > > > > GPON/DOCSIS/RFoG? That's one people are deploying today. > > That question was in reference to commercial accounts not service > providers. I'm glad you want to limit the question, but I don't. > > Perhaps. But the *current* potential customer base does not merit > > locking in a limited design in a 50-year plant build. > That's a business call, but like a lot of decisions you're making a ton of > assumptions as well. You're assuming for example that the costs of running > additional fibers won't go down significantly during that 50 year time > span. Sure I am. Do you really expect that we'll find an appreciably cheaper method than directional-bore-and-blow? More to the point, the "-blow" part of that, since I'll be over-provisioning the conduit. > You're assuming that the cost of DWDM gear won't go down > sufficiently that running new fiber is simply not needed to support the > new architecture. Which seems the opposite argument. > You're also assuming that Layer 1 will at some point > have a reason for customer adoption when the entire world is working > on Layer 3 methods of doing this. Perhaps. But Juan Moore-Thyme: The extra cost of the plant build is somewhere between delta and epsilon; it *barely* even merits the amount of time we've burned up talking about it. I *can* fake loop with a home-run build, the converse is -- so far as I can see -- not true; loop builds *require* powered active equipment in the field, and I have half a dozen reasons to *really not want that a lot*. > > > This is the key point. IF someone was able to put together a nationwide > > > or even regional offering to allow inexpensive Layer 1 connectivity > > > things would be different. > > > > How, Scott, would you expect that sort of thing might happen? > > > > By people taking the first step? > > > > Yeah; thought so. > > There are more "first steps" that are never followed up than people > actually starting a trend. There is a guy in my neighborhood that swears > we can all drive around in cars powered by recycled frying oil and he > built one to prove it works. I should point out that your idea is not new > nor are you the first to try to build something like this. Good, then there should be lots of examples, successful *by their terms* or not, at which I can look. > > My county doesn't have the same first-trencher advantage my city > > does... > > but it does have the advantage that *it is nearly 100% built out as > > well*; > > we are, I believe, the densest county *in the United States*; maybe > > Manhattan beats us. Maybe DC; maybe Suffolk County in Mass. > > > > So it's not at all impossible that we might be the first domino to fall; > > there are a lot of barrier island communities near me that would be > > similarly easy to fiber, since they're so one-dimensional. > > > > (Geographically; I'm sure their residents are quite nice. :-) > > Today there are networks based on this premise in every state I've cared to > check. There are a lot of premises in this conversation; exactly which part did you mean? > Here in Georgia the independent phone companies formed a seperate > organization called US Carrier (which was recently sold for much less than > they put into it). The muni's formed a partnering (initially) network > called MEAG that was later renamed to GA Public Web ( > http://www.gapublicweb.net/). When the two were first constructed in the > early 2000's they actually had a interconnects and could sell off each > other's network, but that fell apart over time. Another good reference; thanks. > > > However, that's not going to happen AND we already > > > have good cheap solutions to deal with that. Most commonly VPLS over GRE > > > or VPN whose only real cost beyond the basic home Internet connection, > > > is a ~$350 CPE that supports the protocol. > > > > You're paying $350 for VPN routers? > > > > Could I be one of your vendors? > > VPLS and good remote management is well worth $350. I was quite happy with SnapGear before they got bought, out (still am, actually), and they were about half that. > > > your IT staff to support? > > > > Accurate, but not germane. They're not my target market. > > Owen brought up that example. Sure, there are lots of target markets. But no specific target market (except perhaps L1 ISPs) is driving my decision. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From rayw at rayw.net Wed Feb 6 16:16:28 2013 From: rayw at rayw.net (Ray Wong) Date: Wed, 6 Feb 2013 08:16:28 -0800 Subject: Level3 worldwide emergency upgrade? In-Reply-To: References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <20130206151037.GJ27306@dyn.com> Message-ID: > OK, having had that first cup of coffee, I can say perhaps the main reason I was wondering is I've gotten used to Level3 always being on top of things (and admittedly, rarely communicating). They've reached the top by often being a black box of reliability, so it's (perhaps unrealistically) surprising to see them caught by surprise. Anything that pushes them into scramble mode causes me to lose a little sleep anyway. The alternative to what they did seems likely for at least a few providers who'll NOT manage to fix things in time, so I may well be looking at longer outages from other providers, and need to issue guidance to others on what to do if/when other links go down for periods long enough that all the cost-bounding monitoring alarms start to scream even louder. I was also grumpy at myself for having not noticed advance communication, which I still don't seem to have, though since I outsourced my email to bigG, I've noticed I'm more likely to miss things. Perhaps giving up maintaining that massive set of procmail rules has cost me a bit more edge. Related, of course, just because you design/run your network to tolerate some issues doesn't mean you can also budget to be in support contract as well. :) Knowing more about the exploit/fix might mean trying to find a way to get free upgrades to some kit to prevent more localized attacks to other types of gear, as well, though in this case it's all about Juniper PR839412 then, so vendor specific, it seems? There are probably more reasons to wish for more info, too. There's still more of them (exploiters/attackers) than there are those of us trying to keep things running smoothly and transparently, so anything that smells of "OMG new exploit found!" also triggers my desire to share information. The network bad guys share information far more quickly and effectively than we do, it often seems. -R> From fdelmotte1 at mac.com Wed Feb 6 16:21:40 2013 From: fdelmotte1 at mac.com (Fabien Delmotte) Date: Wed, 06 Feb 2013 17:21:40 +0100 Subject: Metro Ethernet, VPLS clarifications In-Reply-To: <00e501ce047d$4eccc9b0$ec665d10$@swan.sk> References: <51108551.7090700@gmail.com> <5111D3E1.3000904@gmail.com> <00e501ce047d$4eccc9b0$ec665d10$@swan.sk> Message-ID: I thought that PBB was dead :) if not forget VPLS and play with PBB and PBT :) Welcome in the "twilight zone" Fabien Le 6 f?vr. 2013 ? 16:19, Adam Vitkovsky a ?crit : > And for fun you can also do: > Ethernet over PBB to VPLS > Ethernet over PBB over VPLS -that's actually called EVPN > > adam > -----Original Message----- > From: Fabien Delmotte [mailto:fdelmotte1 at mac.com] > Sent: Wednesday, February 06, 2013 4:07 PM > To: Scott Helms > Cc: NANOG; Abzal Sembay > Subject: Re: Metro Ethernet, VPLS clarifications > > Hi, > > My 2 cents > >> VPLS can be run across several different kinds of layer 1 & 2 >> technologies and is independent of the underlying technology because >> it builds it pseudo wires at layers 3 & 4. VPLS leverages technologies >> like Metro Ethernet and MPLS to extend a business' Ethernet LAN >> (technically the broadcast domain) to remote sites. At the end of the >> day you can use several kinds of tunneling technologies to provide VPLS, > including GRE, MPLS, and L2TPv3. > > For fun you can also do : > LDP VPLS over a GRE tunnel > LDP over a GRE tunnel within an encrypted network > > I can be wrong but VPLS is running over MPLS (rfc 4762) because it is using > LDP > > Regards > > Fabien > > > > Le 6 f?vr. 2013 ? 15:41, Scott Helms a ?crit : > >>> >>> From my understanding M-Ethernet is a some kind of service. >>> Standartized technology that allows to connect multiple different >>> networks. And it is independent from physical and datalink layers. >>> >> >> Metro Ethernet is a datalink (layer 2) protocol. It also has physical >> (layer 1) specifications though there are several kinds of physical >> medium that can be used. Most commonly its delivered over fiber >> (single or multi-mode depending on distance from the last active >> element) or cat 5E/6 twisted pair. >> >> >> >>> And nowadays which tecnology is the most used(VPLS or Metro)? What >>> about MPLS? Sorry I'm a little confused. I really want to understand. >>> >> >> VPLS can be run across several different kinds of layer 1 & 2 >> technologies and is independent of the underlying technology because >> it builds it pseudo wires at layers 3 & 4. VPLS leverages technologies >> like Metro Ethernet and MPLS to extend a business' Ethernet LAN >> (technically the broadcast domain) to remote sites. At the end of the >> day you can use several kinds of tunneling technologies to provide VPLS, > including GRE, MPLS, and L2TPv3. >> >> Here are the main two RFCs: >> >> http://tools.ietf.org/html/rfc4761 >> http://tools.ietf.org/html/rfc4762 >> >> >>> >>> >>> -- >>> Regards, >>> >>> Abzal >>> >>> >> >> >> -- >> Scott Helms >> Vice President of Technology >> ZCorum >> (678) 507-5000 >> -------------------------------- >> http://twitter.com/kscotthelms >> -------------------------------- > > > From paul4004 at gmail.com Wed Feb 6 16:24:52 2013 From: paul4004 at gmail.com (PC) Date: Wed, 6 Feb 2013 09:24:52 -0700 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <51127F07.3090107@bogus.com> References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <20130206151037.GJ27306@dyn.com> <51127F07.3090107@bogus.com> Message-ID: Given the issue was announced a week ago, I'm surprised they didn't provide some sort of emergency notification prior to the upgrade. However, I certainly understand their immediate desire to deploy this update. I don't think it's bad as the BGP one from not too long ago in that exploit code is not yet publicly available to my knowledge, but it certainly won't take long. On Wed, Feb 6, 2013 at 9:04 AM, joel jaeggli wrote: > On 2/6/13 7:43 AM, Ray Wong wrote: > >> On Wed, Feb 6, 2013 at 7:10 AM, Andrew Sullivan >> wrote: >> >>> On Wed, Feb 06, 2013 at 07:39:14AM -0500, Jared Mauch wrote: >>> >>>> So, I'm wondering what is shocking that someone may have to push out >>>> some sort of upgrade either urgently or periodically that is so impacting >>>> and causes these emails on the list. >>>> >>>> My impression is mostly that people are left feeling uncomfortable by >>> a massive upgrade of this sort with so little communication about why >>> and so on. "Emergency work for five hours and 30 minutes >>> disconnection" that turns out to take longer than 30 minutes of >>> disconnection probably ought to come with some explanation (at least >>> after the fact). >>> >>> Especially in the wake they already recently did one. It's unsettling >> to receive little communication, and even multihomed, there's always >> the question of being pushed into overages around other providers. >> >> Yes, short notice maintenance does happen. Better communication >> happens much less often. >> > I recieved advance (24 hours) notification of maintenances over the last > two days to circuits ranging in size from 100MB/s to 10Gb/s in about a > dozen locations. I assumed there would be further disruption as devices I'm > not directly connected to were touched. > > >> I was more looking for details, i.e. the sort of problem this is, as >> it probably also means all my *other* providers are going to be >> scrambling in the next few days/weeks/months, depending on what gear >> they're all using. >> > All your other providers using that vendor have been scrambling for about > a week as well. Junos devices should be upgraded. > > I'm out of the global infrastructure game myself >> for a few years currently, but I still have to think ahead to the >> network I do maintain. >> >> >> -R> >> >> > > From rs at seastrom.com Wed Feb 6 16:28:19 2013 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 06 Feb 2013 11:28:19 -0500 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: (Scott Helms's message of "Wed, 6 Feb 2013 10:36:08 -0500") References: <3812321.200.1359569919347.JavaMail.art@DQT6ZQ1> <86txppqz3f.fsf@seastrom.com> <86txpppihe.fsf@seastrom.com> Message-ID: <86vca5fluk.fsf@seastrom.com> Scott Helms writes: > On Wed, Feb 6, 2013 at 10:30 AM, Robert E. Seastrom <[[rs at seastrom.com]]> > wrote: > > If you were talking about layer 2 handoffs, your statement > is perhaps > even more untrue - active ethernet and PON layer 2 handoffs are > approximately as easy as each other. > > Perhaps you'd share some specifics? ?I certainly haven't worked on all of the > PON systems that are out there, but the ones I have worked one didn't have (or > I didn't find) a good way to separate traffic at layer 2 so that several > operators could handle their own Layer 3 provisioning for customers on the > same OLT. ? Every PON OLT that I have touched has supported both vlan-per-customer (has scaling issues) and vlan-per-service configuration abstractions. There are other ways to do it too (double and triple tagging) but to keep it simple if one creates profiles along the lines of: SP1-VOIP SP1-VIDEO SP1-INTARWEBZ and repeats for sp2, sp3, etc... trunk out the top, split off vlans and backhaul as appropriate (choose wisely!) with appropriate QoS if you like, to equal access provider. Provisioning the ONT/ONU and the inter-provider interface to do so (REST XML? JSON? something else?) is left as an exercise to the implementer. Reading this: https://sites.google.com/site/amitsciscozone/home/gpon/gpon-vlans-and-gem-ports may prove informative for the GPON case. -r From streiner at cluebyfour.org Wed Feb 6 16:34:20 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 6 Feb 2013 11:34:20 -0500 (EST) Subject: Level3 worldwide emergency upgrade? In-Reply-To: References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <20130206151037.GJ27306@dyn.com> Message-ID: On Wed, 6 Feb 2013, Ray Wong wrote: >> My impression is mostly that people are left feeling uncomfortable by >> a massive upgrade of this sort with so little communication about why >> and so on. "Emergency work for five hours and 30 minutes >> disconnection" that turns out to take longer than 30 minutes of >> disconnection probably ought to come with some explanation (at least >> after the fact). > > I was more looking for details, i.e. the sort of problem this is, as > it probably also means all my *other* providers are going to be > scrambling in the next few days/weeks/months, depending on what gear > they're all using. I'm out of the global infrastructure game myself > for a few years currently, but I still have to think ahead to the > network I do maintain. If Level3 is pushing this upgrade because of a security vulnerability, like the recent Juniper PSN, any public notification will likely be tersely worded out of necessity. You might be able to get more details by contacting your account team, but it's highly unlikely that you'll see the level of detail you're looking for in a public communication. That's not a knock against Level3, and most other carriers will likely be equally tight-lipped on the details. jms From khelms at zcorum.com Wed Feb 6 16:35:35 2013 From: khelms at zcorum.com (Scott Helms) Date: Wed, 6 Feb 2013 11:35:35 -0500 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: <86vca5fluk.fsf@seastrom.com> References: <3812321.200.1359569919347.JavaMail.art@DQT6ZQ1> <86txppqz3f.fsf@seastrom.com> <86txpppihe.fsf@seastrom.com> <86vca5fluk.fsf@seastrom.com> Message-ID: Robert, Thanks for the information, I either missed VLAN per sub set up which does make PON L2 sharing virtually the same as AE or the version of hardware/firmware I last worked on didn't support it. On Wed, Feb 6, 2013 at 11:28 AM, Robert E. Seastrom wrote: > > Scott Helms writes: > > > On Wed, Feb 6, 2013 at 10:30 AM, Robert E. Seastrom <[[rs at seastrom.com > ]]> > > wrote: > > > > If you were talking about layer 2 handoffs, your statement > > is perhaps > > even more untrue - active ethernet and PON layer 2 handoffs are > > approximately as easy as each other. > > > > Perhaps you'd share some specifics? I certainly haven't worked on all > of the > > PON systems that are out there, but the ones I have worked one didn't > have (or > > I didn't find) a good way to separate traffic at layer 2 so that several > > operators could handle their own Layer 3 provisioning for customers on > the > > same OLT. > > Every PON OLT that I have touched has supported both vlan-per-customer > (has scaling issues) and vlan-per-service configuration abstractions. > There are other ways to do it too (double and triple tagging) but to > keep it simple if one creates profiles along the lines of: > > SP1-VOIP > SP1-VIDEO > SP1-INTARWEBZ > > and repeats for sp2, sp3, etc... trunk out the top, split off vlans > and backhaul as appropriate (choose wisely!) with appropriate QoS if > you like, to equal access provider. > > Provisioning the ONT/ONU and the inter-provider interface to do so > (REST XML? JSON? something else?) is left as an exercise to the > implementer. > > Reading this: > > https://sites.google.com/site/amitsciscozone/home/gpon/gpon-vlans-and-gem-ports > may prove informative for the GPON case. > > -r > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From tom.taylor.stds at gmail.com Wed Feb 6 16:39:44 2013 From: tom.taylor.stds at gmail.com (Tom Taylor) Date: Wed, 06 Feb 2013 11:39:44 -0500 Subject: Can OLTs separate port management by admin user? In-Reply-To: <32130872.5133.1360166160123.JavaMail.root@benjamin.baylink.com> References: <32130872.5133.1360166160123.JavaMail.root@benjamin.baylink.com> Message-ID: <51128750.2030603@gmail.com> At the standards level, ANCP was designed to allow partitioning like that. however, work on applying ANCP (Access Network Control Protocol) to PON is just going through the IESG now, so the probability that it's implemented in the Calix devices is remote. Tom T On 06/02/2013 10:56 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Scott Helms" > >> On Wed, Feb 6, 2013 at 10:30 AM, Robert E. Seastrom >> wrote: > ... > > Can you separate the *control plan* on an ISP by ISP basis: is it > possible to give ISPs whose clients are on specific ports of an access > mux like an OLT *control over only those ports*, leaving card- and chassis- > global functions for the L2 operator? (Possibly with the optimization > of allowing card-global functions if all the ports on the card are owned > by that operator, or unassigned.) > > It's a very good question, and the next nail I was going to hammer. > > I'm betting the answer is presently "no; you'll have to put a smart > OAM&P layer in front of it", myself. > > Can anyone who's used such Access multiplexers comment on this? > > Cheers, > -- jra > From jra at baylink.com Wed Feb 6 16:49:56 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 6 Feb 2013 11:49:56 -0500 (EST) Subject: Can OLTs separate port management by admin user? In-Reply-To: <51128750.2030603@gmail.com> Message-ID: <62061.5175.1360169396434.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Tom Taylor" > At the standards level, ANCP was designed to allow partitioning like > that. however, work on applying ANCP (Access Network Control Protocol) > to PON is just going through the IESG now, so the probability that > it's implemented in the Calix devices is remote. So, that's pushing the control stuff into an API and adding AAA? Cause I'd be happy with multi-user auth on the CLI, and assigning an 'owner' to each port... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From David.Siegel at Level3.com Wed Feb 6 17:01:22 2013 From: David.Siegel at Level3.com (Siegel, David) Date: Wed, 6 Feb 2013 17:01:22 +0000 Subject: Level3 worldwide emergency upgrade? In-Reply-To: References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <20130206151037.GJ27306@dyn.com> Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC0AF7DD2@USIDCWVEMBX10.corp.global.level3.com> Hi Ray, This topic reminds me of yesterday's discussion in the conference around getting some BCOP's drafted. it would be useful to confirm my own view of the BCOP around communicating security issues. My understanding for the best practice is to limit knowledge distribution of security related problems both before and after the patches are deployed. You limit knowledge before the patch is deployed to prevent yourself from being exploited, but you also limit knowledge afterwards in order to limit potential damage to others (customers, competitors...the Internet at large). You also do not want to announce that you will be deploying a security patch until you have a fix in hand and know when you will deploy it (typically, next available maintenance window unless the cat is out of the bag and danger is real and imminent). As a service provider, you should stay on top of security alerts from your vendors so that you can make your own decision about what action is required. I would not recommend relying on service provider maintenance bulletins or public operations mailing lists for obtaining this type of information. There is some information that can cause more harm than good if it is distributed in the wrong way and information relating to security vulnerabilities definitely falls into that category. Dave -----Original Message----- From: Ray Wong [mailto:rayw at rayw.net] Sent: Wednesday, February 06, 2013 9:16 AM To: nanog at nanog.org Subject: Re: Level3 worldwide emergency upgrade? > OK, having had that first cup of coffee, I can say perhaps the main reason I was wondering is I've gotten used to Level3 always being on top of things (and admittedly, rarely communicating). They've reached the top by often being a black box of reliability, so it's (perhaps unrealistically) surprising to see them caught by surprise. Anything that pushes them into scramble mode causes me to lose a little sleep anyway. The alternative to what they did seems likely for at least a few providers who'll NOT manage to fix things in time, so I may well be looking at longer outages from other providers, and need to issue guidance to others on what to do if/when other links go down for periods long enough that all the cost-bounding monitoring alarms start to scream even louder. I was also grumpy at myself for having not noticed advance communication, which I still don't seem to have, though since I outsourced my email to bigG, I've noticed I'm more likely to miss things. Perhaps giving up maintaining that massive set of procmail rules has cost me a bit more edge. Related, of course, just because you design/run your network to tolerate some issues doesn't mean you can also budget to be in support contract as well. :) Knowing more about the exploit/fix might mean trying to find a way to get free upgrades to some kit to prevent more localized attacks to other types of gear, as well, though in this case it's all about Juniper PR839412 then, so vendor specific, it seems? There are probably more reasons to wish for more info, too. There's still more of them (exploiters/attackers) than there are those of us trying to keep things running smoothly and transparently, so anything that smells of "OMG new exploit found!" also triggers my desire to share information. The network bad guys share information far more quickly and effectively than we do, it often seems. -R> From joelja at bogus.com Wed Feb 6 17:31:21 2013 From: joelja at bogus.com (joel jaeggli) Date: Wed, 06 Feb 2013 09:31:21 -0800 Subject: Level3 worldwide emergency upgrade? In-Reply-To: References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <20130206151037.GJ27306@dyn.com> Message-ID: <51129369.3080002@bogus.com> On 2/6/13 8:34 AM, Justin M. Streiner wrote: > On Wed, 6 Feb 2013, Ray Wong wrote: > >>> My impression is mostly that people are left feeling uncomfortable by >>> a massive upgrade of this sort with so little communication about why >>> and so on. "Emergency work for five hours and 30 minutes >>> disconnection" that turns out to take longer than 30 minutes of >>> disconnection probably ought to come with some explanation (at least >>> after the fact). >> >> I was more looking for details, i.e. the sort of problem this is, as >> it probably also means all my *other* providers are going to be >> scrambling in the next few days/weeks/months, depending on what gear >> they're all using. I'm out of the global infrastructure game myself >> for a few years currently, but I still have to think ahead to the >> network I do maintain. > > If Level3 is pushing this upgrade because of a security vulnerability, > like the recent Juniper PSN, any public notification will likely be > tersely worded out of necessity. > The one that motivated us to upgrade is: PR839412 I assume that applies to most people with interest in running current junos. My imagination is pretty good so that got my attention. > You might be able to get more details by contacting your account team, > but it's highly unlikely that you'll see the level of detail you're > looking for in a public communication. That's not a knock against > Level3, and most other carriers will likely be equally tight-lipped on > the details. > > jms > From jra at baylink.com Wed Feb 6 18:03:53 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 6 Feb 2013 13:03:53 -0500 (EST) Subject: Alcatel-Lucent and France Tel deploy 400G for testing Message-ID: <2515853.5185.1360173833619.JavaMail.root@benjamin.baylink.com> http://www.telecomramblings.com/2013/02/alcatel-lucent-and-france-telecom-surpass-100g-implement-400g/ -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mpetach at netflight.com Wed Feb 6 18:06:01 2013 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 6 Feb 2013 10:06:01 -0800 Subject: 2013.02.06 NANOG57 day3 morning session notes posted Message-ID: Huge thanks to the program committee for pulling another great set of talks together; this really has been a top-notch bunch of content! Notes are up at http://kestrel3.netflight.com/2013.02.06-NANOG57-day3-morning-session.txt As always, if my apache process wedges, let me know and I'll kick it; or, if people want to copy the notes to pastebin, twiki, or other more stable sites, that's totally cool; I don't have any particular ownership over these notes, they're just out there in case folks missed a talk and want to catch up before the streams are put up on the nanog site. thanks again for another awesome conference! Matt From mpetach at netflight.com Wed Feb 6 18:22:52 2013 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 6 Feb 2013 10:22:52 -0800 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <20130206131015.GE20536@hijacked.us> References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <2D0AF14BA6FB334988BC1F5D4FC38CB81E65E5D82C@EXCHMBX.hq.nac.net> <20130206131015.GE20536@hijacked.us> Message-ID: On Wed, Feb 6, 2013 at 5:10 AM, Jonathan Towne wrote: > On Wed, Feb 06, 2013 at 07:57:06AM -0500, Alex Rubenstein scribbled: > # The question should be more along the lines of, "why aren't you multihomed in a way that would make a 30 minute outage (which is inevitable) irrelevant to you? > > The fun part of this emergency maintenance in the northeast USA was that even > folks who are multihomed felt it: Level3 managed to do this in a way that > kept BGP sessions up but killed the ability to actually pass traffic. I'm not > sure what they did that caused this, or whether anyone but northeast folks > were affected by it, but it sure was neat to be effectively blackholed in and > out of one of your provided circuits for a while. I recommend you grab http://kestrel3.netflight.com/2013.02.05-NANOG57-day2-afternoon-session.txt and search for PR8361907 Richard did a very good lightning talk about why Juniper boxes will bring up BGP but blackhole traffic for 30 minutes to over an hour, depending on number of BGP sessions it is handling. His recommendation--if you don't like it, go tell Juniper to fix that bug. Matt From outsider at scarynet.org Wed Feb 6 18:37:54 2013 From: outsider at scarynet.org (Alexander Maassen) Date: Wed, 06 Feb 2013 19:37:54 +0100 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <2D0AF14BA6FB334988BC1F5D4FC38CB81E65E5D82C@EXCHMBX.hq.nac.net> References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <2D0AF14BA6FB334988BC1F5D4FC38CB81E65E5D82C@EXCHMBX.hq.nac.net> Message-ID: <1360175874.17086.0.camel@outsider.laptop> On Wed, 2013-02-06 at 07:57 -0500, Alex Rubenstein wrote: > > Would you rather your ISP not maintain their devices? Are the > > consequences "so bad" of a 30 minute outage that your business > > is severely impacted? > > > > - Jared > > You had me up until that line. > > That should be expanded a little ... > > First, I'd say, yes - many businesses would be severely impacted and may even have consequential issues if they had to sustain a 30 minute outage. Suppose for a moment they couldn't process money machines transactions for 30 minutes; or Netflix couldn't serve content for 30 minutes; or youporn was offline for 30 minutes. > > The question should be more along the lines of, "why aren't you multihomed in a way that would make a 30 minute outage (which is inevitable) irrelevant to you? > > > multihomed or simply redundantly equipped to switch over faster ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From jra at baylink.com Wed Feb 6 19:03:07 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 6 Feb 2013 14:03:07 -0500 (EST) Subject: NANOG 57 Notes from Matthew Message-ID: <32506753.5199.1360177387061.JavaMail.root@benjamin.baylink.com> I've created a skeleton page at Cluepon for this meeting; Matthew will be uploading his notes there shortly: http://nanog.cluepon.net/index.php/NANOG57 Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From marcus at linx.net Wed Feb 6 19:53:54 2013 From: marcus at linx.net (Marcus Taylor) Date: Wed, 06 Feb 2013 19:53:54 +0000 Subject: NANOG 57 Notes from Matthew In-Reply-To: <32506753.5199.1360177387061.JavaMail.root@benjamin.baylink.com> References: <32506753.5199.1360177387061.JavaMail.root@benjamin.baylink.com> Message-ID: <3f017846-c35f-4dde-ab16-2852ca366dbe@email.android.com> Nice work guys - it is appreciated :) Jay Ashworth wrote: >I've created a skeleton page at Cluepon for this meeting; Matthew will >be >uploading his notes there shortly: > >http://nanog.cluepon.net/index.php/NANOG57 > >Cheers, >-- jra >-- >Jay R. Ashworth Baylink >jra at baylink.com >Designer The Things I Think >RFC 2100 >Ashworth & Associates http://baylink.pitas.com 2000 Land >Rover DII >St Petersburg FL USA #natog +1 727 >647 1274 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. And my top posting...... From djahandarie at gmail.com Wed Feb 6 20:26:28 2013 From: djahandarie at gmail.com (Darius Jahandarie) Date: Wed, 6 Feb 2013 15:26:28 -0500 Subject: NANOG 57 Notes from Matthew In-Reply-To: <32506753.5199.1360177387061.JavaMail.root@benjamin.baylink.com> References: <32506753.5199.1360177387061.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Feb 6, 2013 at 2:03 PM, Jay Ashworth wrote: > I've created a skeleton page at Cluepon for this meeting; Matthew will be > uploading his notes there shortly: > > http://nanog.cluepon.net/index.php/NANOG57 I wonder how long it'll be before the spam bots take over that page. -- Darius Jahandarie From kris at kriskinc.com Wed Feb 6 20:33:42 2013 From: kris at kriskinc.com (Kristian Kielhofner) Date: Wed, 6 Feb 2013 15:33:42 -0500 Subject: Interesting debugging: Specific packets cause some Intel gigabit ethernet controllers to reset Message-ID: Over the year I've read some interesting (horrifying?) tales of debugging on NANOG. It seems I finally have my own to contribute: http://blog.krisk.org/2013/02/packets-of-death.html The strangest issue I've experienced, that's for sure. -- Kristian Kielhofner From fw at deneb.enyo.de Wed Feb 6 20:37:08 2013 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 06 Feb 2013 21:37:08 +0100 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <20130206151037.GJ27306@dyn.com> (Andrew Sullivan's message of "Wed, 6 Feb 2013 10:10:37 -0500") References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <20130206151037.GJ27306@dyn.com> Message-ID: <87pq0dgowb.fsf@mid.deneb.enyo.de> * Andrew Sullivan: > My impression is mostly that people are left feeling uncomfortable > by a massive upgrade of this sort with so little communication about > why and so on. That's a side effect of Juniper's notification policy. Perhaps someone should them take them by their word ("Security patches and advisories are freely available from our web site.") and post this stuff publicly, so that everybody feels rightly scared and complains less about these disruptions. From ikiris at gmail.com Wed Feb 6 20:40:07 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Wed, 6 Feb 2013 14:40:07 -0600 Subject: Interesting debugging: Specific packets cause some Intel gigabit ethernet controllers to reset In-Reply-To: References: Message-ID: Wow, you just solved my issue with my firewall. On Wed, Feb 6, 2013 at 2:33 PM, Kristian Kielhofner wrote: > Over the year I've read some interesting (horrifying?) tales of > debugging on NANOG. It seems I finally have my own to contribute: > > http://blog.krisk.org/2013/02/packets-of-death.html > > The strangest issue I've experienced, that's for sure. > > -- > Kristian Kielhofner > > From jra at baylink.com Wed Feb 6 20:47:50 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 6 Feb 2013 15:47:50 -0500 (EST) Subject: Interesting debugging: Specific packets cause some Intel gigabit ethernet controllers to reset In-Reply-To: Message-ID: <11656280.5209.1360183670284.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Kristian Kielhofner" > Over the year I've read some interesting (horrifying?) tales of > debugging on NANOG. It seems I finally have my own to contribute: > > http://blog.krisk.org/2013/02/packets-of-death.html > > The strangest issue I've experienced, that's for sure. FWIW, I had a similar situation crop up a couple of years ago with *five different* Seagate SATA drives: they grew some specific type of bad spot on the drive which, if you even tried to read it, would *knock the drive adapter off line until powercycle*; even a reboot didn't clear it. Nice writeup. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Wed Feb 6 20:57:07 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 6 Feb 2013 15:57:07 -0500 (EST) Subject: NANOG 57 Notes from Matthew In-Reply-To: Message-ID: <24839306.5215.1360184227017.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "david raistrick" > sure would be nice if the nanog meetings were a bit better > announced....why do I aways find out about the orlando ones during or > after? I hadn't realized there was another one in Orlando, David; last Florida ones I knew about were Miami, and 10 in Tampa. FWIW, I have been banging on them to include the city name in *everything they post* about the meetings on the list, and they've been a lot better lately... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From hhoffman at ip-solutions.net Wed Feb 6 21:04:23 2013 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Wed, 06 Feb 2013 16:04:23 -0500 Subject: Interesting debugging: Specific packets cause some Intel gigabit ethernet controllers to reset In-Reply-To: References: Message-ID: <5112C557.9080507@ip-solutions.net> On a similar vein here's some fun reading: http://travisgoodspeed.blogspot.com/2011/09/remotely-exploiting-phy-layer.html On 02/06/2013 03:33 PM, Kristian Kielhofner wrote: > Over the year I've read some interesting (horrifying?) tales of > debugging on NANOG. It seems I finally have my own to contribute: > > http://blog.krisk.org/2013/02/packets-of-death.html > > The strangest issue I've experienced, that's for sure. > From jfmezei_nanog at vaxination.ca Wed Feb 6 21:06:16 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 06 Feb 2013 16:06:16 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <616B4ECE1290D441AD56124FEBB03D0810FE54251A@mailserver2007.nyigc.globe> References: <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE54251A@mailserver2007.nyigc.globe> Message-ID: <5112C5C8.3000309@vaxination.ca> On 13-02-06 10:16, Eric Wieling wrote: > Can anyone out there in NANOGland confirm how ILECs currently backhaul their DSL customers from the DSLAM to the ILECs IP network? In Bell Canada Territory, wholesale traffic between DSLAM and BAS/BRAS travels normally. The BAS establishes the PPPoE session with end user. When the PAP/CHAp authentication requests arrive, the BAS sees that it has a realm that belongs to ISP-X and declares that all packets in that PPPoE session should be forwarded to ISP-x from now on. The BAS establises an L2TP tunnel to and IP address that belongs to ISP-X. This tunnel travels through Bell Canada's aggregation network to a router near the ISP's own facilities. There, the L2TP continues on a GigE link to the ISP's incumbent facing router. ISP gets PPPoE packets encapsulated in L2TP. It is responsible for responding to the authentication request, and if positive, providing IP address/dns/router/etc via IPCP. Note that incumbents have been telling the CRTC for years that gigE was the latest and greatest and couldn't do better. Some ISPs require a large number of gigE links to handle the load. The CRTC last year mandated incumbenst learn about the less old 10gigE technology and provide it to ISPs who need it. Bell Canada has yet to comply. But some cable incumbents have complied. In this scenario, there is an ISP of record for the DSL last mile. That ISP gets billed for the monthly fees for the DSL last mile. (roughly $20). However, the end user can establish a PPPoE session with another ISP if he has valid credentials with that other ISP. When a user formally switches ISP, Bell Canada only needs to change the ISP of record attached to the phone line so the old ISP is no longer billed for it and the new ISP is. The user can start using the new ISP as soon as his credentials with the new ISP are setup. Bell canada also offers a non PPPoE service (it calls HSA). However, it is priced to dissuade use. This trafic is in a PVC between the modem and the ISP and not switched by a BAS. I believe Bell uses VLANs to funnel traffic into the link leading to the ISP. (not sure if L2TP is involved). From mpetach at netflight.com Wed Feb 6 21:18:57 2013 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 6 Feb 2013 13:18:57 -0800 Subject: 2013.02.06 NANOG57 day3 afternoon session notes posted Message-ID: I put the notes from the afternoon session up on my website--but thanks to a great suggestion by Jay, I'm also putting them up on the nanog.cluepon.net site on the wiki, so that as folks spot my typos, they can fix them themselves, rather than wonder why goodle.com doesn't resolve for them, etc. ^_^; http://kestrel3.netflight.com/2013.02.06-NANOG57-day3-afternoon-session.txt for now--not sure if the final URL for the notes on nanog.cluepon.net is set or not, so I'll wait to send it out until I'm sure I'm not just pointing at a temporary staging spot. :) Great conference, some really good material; looking forward to the next one; with any luck, I won't be a manager anymore by then, and won't be smack-dab in the middle of reviews. :) Thanks again, everyone--see you in 4 months! Matt From mpetach at netflight.com Wed Feb 6 21:21:42 2013 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 6 Feb 2013 13:21:42 -0800 Subject: NANOG 57 Notes from Matthew In-Reply-To: <32506753.5199.1360177387061.JavaMail.root@benjamin.baylink.com> References: <32506753.5199.1360177387061.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Feb 6, 2013 at 11:03 AM, Jay Ashworth wrote: > I've created a skeleton page at Cluepon for this meeting; Matthew will be > uploading his notes there shortly: > > http://nanog.cluepon.net/index.php/NANOG57 Oh. that'll teach me to read my inbox first before mailing out. ^_^; Yes, notes are being loaded into twiki right now; today's notes are in, previous notes will be there by the time this makes it through SMTP processing systems along the path. Thanks for setting that up, Jay! Matt > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > From jra at baylink.com Wed Feb 6 21:35:48 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 6 Feb 2013 16:35:48 -0500 (EST) Subject: Interesting debugging: Specific packets cause some Intel gigabit ethernet controllers to reset In-Reply-To: <5112C557.9080507@ip-solutions.net> Message-ID: <7889376.5223.1360186548109.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Harry Hoffman" > On a similar vein here's some fun reading: > > http://travisgoodspeed.blogspot.com/2011/09/remotely-exploiting-phy-layer.html Really? That environment does not have out-of-band framing, which can't be duplicated by the data inside a framed packet? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mohta at necom830.hpcl.titech.ac.jp Wed Feb 6 21:48:25 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 07 Feb 2013 06:48:25 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> Message-ID: <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> Scott Helms wrote: > Actually, at the level that Eric's discussing there isn't any real drawback > to using ATM. High cost is the real drawback. >>> but the basic concept is not bad. >> >> It is not enough, even if you use inexpensive Ethernet. See >> the subject. > Why? Because, for competing ISPs with considerable share, L1 unbundling costs less. They can just have routers, switches and DSL modems in collocation spaces of COs, without L2TP or PPPoE, which means they can eliminate cost for L2TP or PPPoE. Masataka Ohta From khelms at zcorum.com Wed Feb 6 21:53:22 2013 From: khelms at zcorum.com (Scott Helms) Date: Wed, 6 Feb 2013 16:53:22 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> References: <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> Message-ID: On Wed, Feb 6, 2013 at 4:48 PM, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > Scott Helms wrote: > > > Actually, at the level that Eric's discussing there isn't any real > drawback > > to using ATM. > > High cost is the real drawback. > The cost difference in a single interface card to carry an OC-3/12 isn't significantly more than a Gig-E card. Now, as I said there is no advantage to doing ATM, but the real cost savings in a single interface are not significant. > > >>> but the basic concept is not bad. > >> > >> It is not enough, even if you use inexpensive Ethernet. See > >> the subject. > > > Why? > > Because, for competing ISPs with considerable share, L1 > unbundling costs less. > > They can just have routers, switches and DSL modems in > collocation spaces of COs, without L2TP or PPPoE, which > means they can eliminate cost for L2TP or PPPoE. > You realize that most commonly the L2TP LAC and LNS are just routers right? You're not getting rid of boxes, you're just getting rid of the only open access technology that's had significant success in the US or Europe. > > Masataka Ohta > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jfmezei_nanog at vaxination.ca Wed Feb 6 22:04:04 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 06 Feb 2013 17:04:04 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> Message-ID: <5112D354.1010905@vaxination.ca> On 13-02-06 16:53, Scott Helms wrote: > You realize that most commonly the L2TP LAC and LNS are just routers right? > You're not getting rid of boxes, you're just getting rid of the only open > access technology that's had significant success in the US or Europe. Actually, there is a cost. In lower end Juniper routers, when you combine both L2TP and PPPoE, the total performance of the LNS router drops significantly because the interface cards can't do both at same time so the traffic must travel the backpane to the CPU/auxiliary processor for the second step. (at the LAC level, there is less overhead because PPPoE packets are just passed to the L2TP side, but at LNS, PPPoE packets have to be processed). Apparently, Juniper has worked to reduce this performance penalty in newer routers. But routers such as the ERX310 suffered from this quite a bit. (throughput of about 1.5mbps from what I have been told). From EWieling at nyigc.com Wed Feb 6 22:06:39 2013 From: EWieling at nyigc.com (Eric Wieling) Date: Wed, 6 Feb 2013 17:06:39 -0500 Subject: Interesting debugging: Specific packets cause some Intel gigabit ethernet controllers to reset In-Reply-To: References: Message-ID: <616B4ECE1290D441AD56124FEBB03D0810FE54260F@mailserver2007.nyigc.globe> I have come to believe the Intel 82574L is the worst Ethernet chip in the universe. We had horrible issues with it (random bursts of dropped packets showing in ifconfig). We ended up simply putting a card based on a different chip into our systems and all our issues went away. -----Original Message----- From: Blake Dunlap [mailto:ikiris at gmail.com] Sent: Wednesday, February 06, 2013 3:40 PM To: Kristian Kielhofner Cc: nanog at nanog.org Subject: Re: Interesting debugging: Specific packets cause some Intel gigabit ethernet controllers to reset Wow, you just solved my issue with my firewall. On Wed, Feb 6, 2013 at 2:33 PM, Kristian Kielhofner wrote: > Over the year I've read some interesting (horrifying?) tales of > debugging on NANOG. It seems I finally have my own to contribute: > > http://blog.krisk.org/2013/02/packets-of-death.html > > The strangest issue I've experienced, that's for sure. > > -- > Kristian Kielhofner > > From khelms at zcorum.com Wed Feb 6 22:12:08 2013 From: khelms at zcorum.com (Scott Helms) Date: Wed, 6 Feb 2013 17:12:08 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <5112D354.1010905@vaxination.ca> References: <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> <5112D354.1010905@vaxination.ca> Message-ID: Jean, Correct, there are few things that cost nothing, but the point is here that PPPoE has been successful for open access to a far greater degree than any other technology I'm aware of (anyone else have ideas?) in North America and Europe. I'd also say that the ERX is an EOL box, but that doesn't invalidate your point, that's not a good platform for the LNS side. On Wed, Feb 6, 2013 at 5:04 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > On 13-02-06 16:53, Scott Helms wrote: > > > You realize that most commonly the L2TP LAC and LNS are just routers > right? > > You're not getting rid of boxes, you're just getting rid of the only > open > > access technology that's had significant success in the US or Europe. > > Actually, there is a cost. In lower end Juniper routers, when you > combine both L2TP and PPPoE, the total performance of the LNS router > drops significantly because the interface cards can't do both at same > time so the traffic must travel the backpane to the CPU/auxiliary > processor for the second step. > > (at the LAC level, there is less overhead because PPPoE packets are just > passed to the L2TP side, but at LNS, PPPoE packets have to be processed). > > > Apparently, Juniper has worked to reduce this performance penalty in > newer routers. But routers such as the ERX310 suffered from this quite a > bit. (throughput of about 1.5mbps from what I have been told). > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From mohta at necom830.hpcl.titech.ac.jp Wed Feb 6 22:31:35 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 07 Feb 2013 07:31:35 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> Message-ID: <5112D9C7.4010802@necom830.hpcl.titech.ac.jp> Scott Helms wrote: > The cost difference in a single interface card to carry an OC-3/12 isn't > significantly more than a Gig-E card. Now, as I said there is no advantage > to doing ATM, but the real cost savings in a single interface are not > significant. You miss ATM switches to connect the card to multiple modems. >> Because, for competing ISPs with considerable share, L1 >> unbundling costs less. >> >> They can just have routers, switches and DSL modems in >> collocation spaces of COs, without L2TP or PPPoE, which >> means they can eliminate cost for L2TP or PPPoE. > You realize that most commonly the L2TP LAC and LNS are just routers right? Who, do you think, operate the network between LAC and LNS? The largest DSL operator in Japan directly connect their routers in COs with dark fibers to form there IP backbone. There is no LAC nor LNS. > You're not getting rid of boxes, you're just getting rid of the only open > access technology that's had significant success in the US or Europe. At least in France, fiber is regulated to be open access at L1 much better than poor alternative of L2 unbundlinga as Jerome Nicolle wrote: > Smaller ISPs usually go for L2 services, provided by the > infrastructure operator or another ISP already present on > site. But some tends to stick to L1 service and deply > their own eqipments for many reasons. Masataka Ohta From khelms at zcorum.com Wed Feb 6 22:42:39 2013 From: khelms at zcorum.com (Scott Helms) Date: Wed, 6 Feb 2013 17:42:39 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <5112D9C7.4010802@necom830.hpcl.titech.ac.jp> References: <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> <5112D9C7.4010802@necom830.hpcl.titech.ac.jp> Message-ID: On Wed, Feb 6, 2013 at 5:31 PM, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > Scott Helms wrote: > > > The cost difference in a single interface card to carry an OC-3/12 isn't > > significantly more than a Gig-E card. Now, as I said there is no > advantage > > to doing ATM, but the real cost savings in a single interface are not > > significant. > > You miss ATM switches to connect the card to multiple modems. > No, because that's not required with PPPoE. Remember, you can easily encapsulate PPPoE frames inside ATM but encapsulating PPPoA frames inside Ethernet is problematic (though I have to admit not remembering why its problematic). Most PPPoE L2TP setups have no ATM besides the default PVC between the modem and the DSLAM. My point was if you need to have an ATM circuit from the LEC to carry the L2TP traffic (usually because they haven't upgraded their LAC) its not that big of a deal. > > >> Because, for competing ISPs with considerable share, L1 > >> unbundling costs less. > >> > >> They can just have routers, switches and DSL modems in > >> collocation spaces of COs, without L2TP or PPPoE, which > >> means they can eliminate cost for L2TP or PPPoE. > > > You realize that most commonly the L2TP LAC and LNS are just routers > right? > > Who, do you think, operate the network between LAC and LNS? > Most often the the LAC and the LNS are directly connected (from an IP standpoint) for purposes of PPPoE termination. > > The largest DSL operator in Japan directly connect their routers > in COs with dark fibers to form there IP backbone. There is no > LAC nor LNS. > OK, that's great but that neither makes it right nor wrong. The largest DSL provider in the US (ATT) does it how I've described and that again doesn't make it right or wrong. > > > You're not getting rid of boxes, you're just getting rid of the only open > > access technology that's had significant success in the US or Europe. > > At least in France, fiber is regulated to be open access at L1 > much better than poor alternative of L2 unbundlinga as > Jerome Nicolle wrote: > > > Smaller ISPs usually go for L2 services, provided by the > > infrastructure operator or another ISP already present on > > site. But some tends to stick to L1 service and deply > > their own eqipments for many reasons. > Again, that's neither right nor wrong. We do lots of things because of regulations. I don't believe (could be wrong) that most of the people in this conversation have the same problems or solutions as the tier 1 operators. Its simply a different world and despite your belief L2 unbundling is not a poor alternative. > > > Masataka Ohta > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From mohta at necom830.hpcl.titech.ac.jp Wed Feb 6 22:43:25 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 07 Feb 2013 07:43:25 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: <5110F25A.1090500@ceriz.fr> References: <11009764.4197.1359482066080.JavaMail.root@benjamin.baylink.com> <5110F25A.1090500@ceriz.fr> Message-ID: <5112DC8D.2010403@necom830.hpcl.titech.ac.jp> Jerome Nicolle wrote: > In non-dense areas, zone operators have to build concentration points > (kind of MMRs) for at least 300 residences (when chaining MMRs) or 1000 > residences (for a single MMR per zone). Theses MMRs often take the form > of street cabinets or shelters and have to be equiped with power and > cooling units to enable any ISP yo install active equipments (either OLT > or ethernet switch). How is the wiring between the concentration points and residences? Masataka Ohta From jfmezei_nanog at vaxination.ca Wed Feb 6 23:02:40 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 06 Feb 2013 18:02:40 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> <5112D354.1010905@vaxination.ca> Message-ID: <5112E110.2090400@vaxination.ca> On 13-02-06 17:12, Scott Helms wrote: > Correct, there are few things that cost nothing, but the point is here that > PPPoE has been successful for open access to a far greater degree than any > other technology I'm aware of By default, Telus in western Canada has deployed ethernet based DSL for wholesale, although PPPoE is available. Its own customers are ethernet based wth DHCP service. Some of the ISPs have chosen PPPoE since it makes it easier to do usage accounting at the router (since packets are already asscoated with the PPPoE session account). The difference is that Telus had purchased/developed software that made it easy to change the PVC to point a user to one ISP or the other, so changing ISPs is relatively painless. Bell Canada decided to abandon etyernet based DSL and go PPPoE because it didn't want to develop that software. Bell is deploying PPPoE for its FTTH (which is not *yet) available to wholesalers, something I am hoping to help change in the coming months) However, the australian NBN model is far superior because it enables far more flexibility such as multicasting etc. PPPoE is useless overhead if you have the right management tools to point a customer to his ISP. (and it also means that the wholesale infrastructure can be switch based intead of router based). From khelms at zcorum.com Wed Feb 6 23:11:02 2013 From: khelms at zcorum.com (Scott Helms) Date: Wed, 6 Feb 2013 18:11:02 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <5112E110.2090400@vaxination.ca> References: <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> <5112D354.1010905@vaxination.ca> <5112E110.2090400@vaxination.ca> Message-ID: > However, the australian NBN model is far superior because it enables far > more flexibility such as multicasting etc. PPPoE is useless overhead if > you have the right management tools to point a customer to his ISP. (and > it also means that the wholesale infrastructure can be switch based > intead of router based). > I'd agree. Its a better way of doing L2 unbundling than PPPoE. Its just PPPoE had the sharing concept baked into it so it was easy for most operators to use historically. -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jfmezei_nanog at vaxination.ca Wed Feb 6 23:18:05 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 06 Feb 2013 18:18:05 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> <5112D354.1010905@vaxination.ca> <5112E110.2090400@vaxination.ca> Message-ID: <5112E4AD.4080202@vaxination.ca> On 13-02-06 18:11, Scott Helms wrote: > I'd agree. Its a better way of doing L2 unbundling than PPPoE. Its just > PPPoE had the sharing concept baked into it so it was easy for most > operators to use historically. PPPoE has its roots in the dialup days. So Incumbents were more than happy to be able to use existing radius servers to autenticate DSL customers. And PPPoE dates from a time when ethernet "routing" didn't really exist. With current ethernet technologies such as VLANs and ethernet encapsulation, if someone is looking at building something from scratch (such as a minicipal network), there shouldn't be incentive to adopt older technologies that provide less flexibility. If you provide L2 ethernet service, it doesn't prevent an ISP from providing PPPoE over it. From EWieling at nyigc.com Wed Feb 6 23:51:48 2013 From: EWieling at nyigc.com (Eric Wieling) Date: Wed, 6 Feb 2013 18:51:48 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> References: <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> Message-ID: <616B4ECE1290D441AD56124FEBB03D0810FE542625@mailserver2007.nyigc.globe> Putting routers and DLAMs each CO is simply not affordable for any but the largest providers like XO. I expect Japan with its compact population centers may be different, but in the USA there are not enough people connected to any but the largest COs to make it affordable. I'm not stuck on using ATM (I used it only as an example), any L2 technology will work. One of our providers uses an Ethernet VLAN per customer endpoint and hands off bunches of VLANs to us over fiber. -----Original Message----- From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp] Sent: Wednesday, February 06, 2013 4:48 PM To: Scott Helms Cc: NANOG Subject: Re: Muni fiber: L1 or L2? Scott Helms wrote: > Actually, at the level that Eric's discussing there isn't any real > drawback to using ATM. High cost is the real drawback. >>> but the basic concept is not bad. >> >> It is not enough, even if you use inexpensive Ethernet. See the >> subject. > Why? Because, for competing ISPs with considerable share, L1 unbundling costs less. They can just have routers, switches and DSL modems in collocation spaces of COs, without L2TP or PPPoE, which means they can eliminate cost for L2TP or PPPoE. Masataka Ohta From ralph.brandt at pateam.com Thu Feb 7 00:41:18 2013 From: ralph.brandt at pateam.com (Brandt, Ralph) Date: Wed, 6 Feb 2013 19:41:18 -0500 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <970945E55BFD8C4EA4CAD74B647A9DC0AF7DD2@USIDCWVEMBX10.corp.global.level3.com> References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <20130206151037.GJ27306@dyn.com> <970945E55BFD8C4EA4CAD74B647A9DC0AF7DD2@USIDCWVEMBX10.corp.global.level3.com> Message-ID: <51C66083768C2949A7EB14910C78B01701D94198@embgsr24.pateam.com> David. I am on an evening shift and am just now reading this thread. I was almost tempted to write an explanation that would have had identical content with yours based simply on Level3 doing something and keeping the information close. Responsible Vendors do not try to hide what is being done unless it is an Op Sec issue and I have never seen Level3 act with less than responsibility so it had to be Op Sec. When it is that, it is best if the remainder of us sit quietly on the sidelines. Ralph Brandt -----Original Message----- From: Siegel, David [mailto:David.Siegel at Level3.com] Sent: Wednesday, February 06, 2013 12:01 PM To: 'Ray Wong'; nanog at nanog.org Subject: RE: Level3 worldwide emergency upgrade? Hi Ray, This topic reminds me of yesterday's discussion in the conference around getting some BCOP's drafted. it would be useful to confirm my own view of the BCOP around communicating security issues. My understanding for the best practice is to limit knowledge distribution of security related problems both before and after the patches are deployed. You limit knowledge before the patch is deployed to prevent yourself from being exploited, but you also limit knowledge afterwards in order to limit potential damage to others (customers, competitors...the Internet at large). You also do not want to announce that you will be deploying a security patch until you have a fix in hand and know when you will deploy it (typically, next available maintenance window unless the cat is out of the bag and danger is real and imminent). As a service provider, you should stay on top of security alerts from your vendors so that you can make your own decision about what action is required. I would not recommend relying on service provider maintenance bulletins or public operations mailing lists for obtaining this type of information. There is some information that can cause more harm than good if it is distributed in the wrong way and information relating to security vulnerabilities definitely falls into that category. Dave -----Original Message----- From: Ray Wong [mailto:rayw at rayw.net] Sent: Wednesday, February 06, 2013 9:16 AM To: nanog at nanog.org Subject: Re: Level3 worldwide emergency upgrade? > OK, having had that first cup of coffee, I can say perhaps the main reason I was wondering is I've gotten used to Level3 always being on top of things (and admittedly, rarely communicating). They've reached the top by often being a black box of reliability, so it's (perhaps unrealistically) surprising to see them caught by surprise. Anything that pushes them into scramble mode causes me to lose a little sleep anyway. The alternative to what they did seems likely for at least a few providers who'll NOT manage to fix things in time, so I may well be looking at longer outages from other providers, and need to issue guidance to others on what to do if/when other links go down for periods long enough that all the cost-bounding monitoring alarms start to scream even louder. I was also grumpy at myself for having not noticed advance communication, which I still don't seem to have, though since I outsourced my email to bigG, I've noticed I'm more likely to miss things. Perhaps giving up maintaining that massive set of procmail rules has cost me a bit more edge. Related, of course, just because you design/run your network to tolerate some issues doesn't mean you can also budget to be in support contract as well. :) Knowing more about the exploit/fix might mean trying to find a way to get free upgrades to some kit to prevent more localized attacks to other types of gear, as well, though in this case it's all about Juniper PR839412 then, so vendor specific, it seems? There are probably more reasons to wish for more info, too. There's still more of them (exploiters/attackers) than there are those of us trying to keep things running smoothly and transparently, so anything that smells of "OMG new exploit found!" also triggers my desire to share information. The network bad guys share information far more quickly and effectively than we do, it often seems. -R> From joelja at bogus.com Thu Feb 7 01:01:38 2013 From: joelja at bogus.com (joel jaeggli) Date: Wed, 06 Feb 2013 17:01:38 -0800 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <51C66083768C2949A7EB14910C78B01701D94198@embgsr24.pateam.com> References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <20130206151037.GJ27306@dyn.com> <970945E55BFD8C4EA4CAD74B647A9DC0AF7DD2@USIDCWVEMBX10.corp.global.level3.com> <51C66083768C2949A7EB14910C78B01701D94198@embgsr24.pateam.com> Message-ID: <5112FCF2.6040405@bogus.com> On 2/6/13 4:41 PM, Brandt, Ralph wrote: > David. I am on an evening shift and am just now reading this thread. > > I was almost tempted to write an explanation that would have had > identical content with yours based simply on Level3 doing something and > keeping the information close. > > Responsible Vendors do not try to hide what is being done unless it is > an Op Sec issue and I have never seen Level3 act with less than > responsibility so it had to be Op Sec. > > When it is that, it is best if the remainder of us sit quietly on the > sidelines. To be clear. the existence of the PR has been know publicly and the software releases that address it have been available for a week now. Everyone who has potential exposure should be addressing the issue, and soon. > Ralph Brandt > > > -----Original Message----- > From: Siegel, David [mailto:David.Siegel at Level3.com] > Sent: Wednesday, February 06, 2013 12:01 PM > To: 'Ray Wong'; nanog at nanog.org > Subject: RE: Level3 worldwide emergency upgrade? > > Hi Ray, > > This topic reminds me of yesterday's discussion in the conference around > getting some BCOP's drafted. it would be useful to confirm my own view > of the BCOP around communicating security issues. My understanding for > the best practice is to limit knowledge distribution of security related > problems both before and after the patches are deployed. You limit > knowledge before the patch is deployed to prevent yourself from being > exploited, but you also limit knowledge afterwards in order to limit > potential damage to others (customers, competitors...the Internet at > large). You also do not want to announce that you will be deploying a > security patch until you have a fix in hand and know when you will > deploy it (typically, next available maintenance window unless the cat > is out of the bag and danger is real and imminent). > > As a service provider, you should stay on top of security alerts from > your vendors so that you can make your own decision about what action is > required. I would not recommend relying on service provider maintenance > bulletins or public operations mailing lists for obtaining this type of > information. There is some information that can cause more harm than > good if it is distributed in the wrong way and information relating to > security vulnerabilities definitely falls into that category. > > Dave > > -----Original Message----- > From: Ray Wong [mailto:rayw at rayw.net] > Sent: Wednesday, February 06, 2013 9:16 AM > To: nanog at nanog.org > Subject: Re: Level3 worldwide emergency upgrade? > > OK, having had that first cup of coffee, I can say perhaps the main > reason I was wondering is I've gotten used to Level3 always being on top > of things (and admittedly, rarely communicating). They've reached the > top by often being a black box of reliability, so it's (perhaps > unrealistically) surprising to see them caught by surprise. Anything > that pushes them into scramble mode causes me to lose a little sleep > anyway. The alternative to what they did seems likely for at least a few > providers who'll NOT manage to fix things in time, so I may well be > looking at longer outages from other providers, and need to issue > guidance to others on what to do if/when other links go down for periods > long enough that all the cost-bounding monitoring alarms start to scream > even louder. > > I was also grumpy at myself for having not noticed advance > communication, which I still don't seem to have, though since I > outsourced my email to bigG, I've noticed I'm more likely to miss > things. Perhaps giving up maintaining that massive set of procmail rules > has cost me a bit more edge. > > Related, of course, just because you design/run your network to tolerate > some issues doesn't mean you can also budget to be in support contract > as well. :) Knowing more about the exploit/fix might mean trying to find > a way to get free upgrades to some kit to prevent more localized attacks > to other types of gear, as well, though in this case it's all about > Juniper PR839412 then, so vendor specific, it seems? > > There are probably more reasons to wish for more info, too. There's > still more of them (exploiters/attackers) than there are those of us > trying to keep things running smoothly and transparently, so anything > that smells of "OMG new exploit found!" also triggers my desire to share > information. The network bad guys share information far more quickly and > effectively than we do, it often seems. > > -R> > > > > From mohta at necom830.hpcl.titech.ac.jp Thu Feb 7 01:03:54 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 07 Feb 2013 10:03:54 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> <5112D9C7.4010802@necom830.hpcl.titech.ac.jp> Message-ID: <5112FD7A.40100@necom830.hpcl.titech.ac.jp> Scott Helms wrote: >> You miss ATM switches to connect the card to multiple modems. > Most PPPoE L2TP setups have no ATM besides the default PVC > between the modem and the DSLAM. You still miss ATM switches to connect the card to multiple DSLAMs. >>> You realize that most commonly the L2TP LAC and LNS are just routers >> right? >> >> Who, do you think, operate the network between LAC and LNS? > Most often the the LAC and the LNS are directly connected (from an IP > standpoint) for purposes of PPPoE termination. Most often? No, it merely means there aren't real competitors. Assuming LACs are operated by a dominant carrier, there are 3 cases how LACs and LNSs are located. 1) Each CO has an LAC and an LNS of a CLEC, in which case the CLEC should have its own DSLAMs (with Ethernet interface, of course) connected to its customer twisted pairs and the LAC and the LNSs can be eliminated to eliminate unnecessary cost. Or, if there are other CLECs doing otherwise, the LAC may still be necessary. But, the CLEC does not have to pay the cost for it. CLECs operate their own network between COs. The most competitive case. 2) Each CO has an LAC and a CLEC has one or more LNSs somewhere, in which case, the LNSs must be attached to a network operated by the dominant carrier. CLECs may operate their own network between some COs. Moderately competitive case. 3) An LAC is centralized that network between COs and the LAC is operated by the dominant carrier, in which case LNSs of CLECs will likely be located near the LAC, which should be the case you silently assumed. The dominant carrier operate all the network between COs. The least competitive case. >> The largest DSL operator in Japan directly connect their routers >> in COs with dark fibers to form there IP backbone. There is no >> LAC nor LNS. > OK, that's great but that neither makes it right nor wrong. The question to be asked is not "right or wrong?" but "how much competitive?". Worse, the following statement of you is wrong: : You're not getting rid of boxes, you're just getting rid of : the only open access technology that's had significant success : in the US or Europe. > The largest > DSL provider in the US (ATT) does it how I've described and that again > doesn't make it right or wrong. The largest DSL operator in Japan is not NTT or its family companies. Lack of competitor at L1 tends to make DSL more expensive, unless strong regulation is applied to the dominant carrier. So, it is better, right, to let inter CO networks operated by CLECs. >>> Smaller ISPs usually go for L2 services, provided by the >>> infrastructure operator or another ISP already present on >>> site. But some tends to stick to L1 service and deply >>> their own eqipments for many reasons. > Again, that's neither right nor wrong. We do lots of things because of > regulations. I don't believe (could be wrong) that most of the people in > this conversation have the same problems or solutions as the tier 1 > operators. FYI, the largest DSL operator in Japan is not tier 1. > Its simply a different world and despite your belief L2 > unbundling is not a poor alternative. It's poor because it's less unbundled and needs extra equipments unnecessary for real competitors. Masataka Ohta From brett at the-watsons.org Thu Feb 7 01:06:39 2013 From: brett at the-watsons.org (Brett Watson) Date: Wed, 6 Feb 2013 18:06:39 -0700 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <51C66083768C2949A7EB14910C78B01701D94198@embgsr24.pateam.com> References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <20130206151037.GJ27306@dyn.com> <970945E55BFD8C4EA4CAD74B647A9DC0AF7DD2@USIDCWVEMBX10.corp.global.level3.com> <51C66083768C2949A7EB14910C78B01701D94198@embgsr24.pateam.com> Message-ID: <1BE2AC63-06D7-4FFA-B95A-7678E1C46A51@the-watsons.org> Hell, we used to not have to bother notifying customers of anything, we just fixed the problem. Reminds me a of a story I've probably shared on the past. 1995, IETF in Dallas. The "big ISP" I worked for at the time got tripped up on a 24-day IS-IS timer bug (maybe all of them at the time did, I don't recall) where all adjacencies reset at once. That's like, entire network down. Working with our engineering team in the *terminal* lab mind you, and Ravi Chandra (then at Cisco) we reloaded the entire network of routers with new code from Cisco once they'd fixed the bug. I seem to remember this being my first exposure to Tony Li's infamous line, "... Confidence Level: boots in the lab." Good times. -b On Feb 6, 2013, at 5:41 PM, Brandt, Ralph wrote: > David. I am on an evening shift and am just now reading this thread. > > I was almost tempted to write an explanation that would have had > identical content with yours based simply on Level3 doing something and > keeping the information close. > > Responsible Vendors do not try to hide what is being done unless it is > an Op Sec issue and I have never seen Level3 act with less than > responsibility so it had to be Op Sec. > > When it is that, it is best if the remainder of us sit quietly on the > sidelines. > > Ralph Brandt > > > -----Original Message----- > From: Siegel, David [mailto:David.Siegel at Level3.com] > Sent: Wednesday, February 06, 2013 12:01 PM > To: 'Ray Wong'; nanog at nanog.org > Subject: RE: Level3 worldwide emergency upgrade? > > Hi Ray, > > This topic reminds me of yesterday's discussion in the conference around > getting some BCOP's drafted. it would be useful to confirm my own view > of the BCOP around communicating security issues. My understanding for > the best practice is to limit knowledge distribution of security related > problems both before and after the patches are deployed. You limit > knowledge before the patch is deployed to prevent yourself from being > exploited, but you also limit knowledge afterwards in order to limit > potential damage to others (customers, competitors...the Internet at > large). You also do not want to announce that you will be deploying a > security patch until you have a fix in hand and know when you will > deploy it (typically, next available maintenance window unless the cat > is out of the bag and danger is real and imminent). > > As a service provider, you should stay on top of security alerts from > your vendors so that you can make your own decision about what action is > required. I would not recommend relying on service provider maintenance > bulletins or public operations mailing lists for obtaining this type of > information. There is some information that can cause more harm than > good if it is distributed in the wrong way and information relating to > security vulnerabilities definitely falls into that category. > > Dave > > -----Original Message----- > From: Ray Wong [mailto:rayw at rayw.net] > Sent: Wednesday, February 06, 2013 9:16 AM > To: nanog at nanog.org > Subject: Re: Level3 worldwide emergency upgrade? > >> > > OK, having had that first cup of coffee, I can say perhaps the main > reason I was wondering is I've gotten used to Level3 always being on top > of things (and admittedly, rarely communicating). They've reached the > top by often being a black box of reliability, so it's (perhaps > unrealistically) surprising to see them caught by surprise. Anything > that pushes them into scramble mode causes me to lose a little sleep > anyway. The alternative to what they did seems likely for at least a few > providers who'll NOT manage to fix things in time, so I may well be > looking at longer outages from other providers, and need to issue > guidance to others on what to do if/when other links go down for periods > long enough that all the cost-bounding monitoring alarms start to scream > even louder. > > I was also grumpy at myself for having not noticed advance > communication, which I still don't seem to have, though since I > outsourced my email to bigG, I've noticed I'm more likely to miss > things. Perhaps giving up maintaining that massive set of procmail rules > has cost me a bit more edge. > > Related, of course, just because you design/run your network to tolerate > some issues doesn't mean you can also budget to be in support contract > as well. :) Knowing more about the exploit/fix might mean trying to find > a way to get free upgrades to some kit to prevent more localized attacks > to other types of gear, as well, though in this case it's all about > Juniper PR839412 then, so vendor specific, it seems? > > There are probably more reasons to wish for more info, too. There's > still more of them (exploiters/attackers) than there are those of us > trying to keep things running smoothly and transparently, so anything > that smells of "OMG new exploit found!" also triggers my desire to share > information. The network bad guys share information far more quickly and > effectively than we do, it often seems. > > -R> > > > From bmanning at vacation.karoshi.com Thu Feb 7 01:18:22 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 7 Feb 2013 01:18:22 +0000 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <1BE2AC63-06D7-4FFA-B95A-7678E1C46A51@the-watsons.org> References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <20130206151037.GJ27306@dyn.com> <970945E55BFD8C4EA4CAD74B647A9DC0AF7DD2@USIDCWVEMBX10.corp.global.level3.com> <51C66083768C2949A7EB14910C78B01701D94198@embgsr24.pateam.com> <1BE2AC63-06D7-4FFA-B95A-7678E1C46A51@the-watsons.org> Message-ID: <20130207011822.GA10510@vacation.karoshi.com.> ah - those were the days of glory... :) On Wed, Feb 06, 2013 at 06:06:39PM -0700, Brett Watson wrote: > Hell, we used to not have to bother notifying customers of anything, we just fixed the problem. Reminds me a of a story I've probably shared on the past. > > 1995, IETF in Dallas. The "big ISP" I worked for at the time got tripped up on a 24-day IS-IS timer bug (maybe all of them at the time did, I don't recall) where all adjacencies reset at once. That's like, entire network down. Working with our engineering team in the *terminal* lab mind you, and Ravi Chandra (then at Cisco) we reloaded the entire network of routers with new code from Cisco once they'd fixed the bug. I seem to remember this being my first exposure to Tony Li's infamous line, "... Confidence Level: boots in the lab." > > Good times. > > -b > > > On Feb 6, 2013, at 5:41 PM, Brandt, Ralph wrote: > > > David. I am on an evening shift and am just now reading this thread. > > > > I was almost tempted to write an explanation that would have had > > identical content with yours based simply on Level3 doing something and > > keeping the information close. > > > > Responsible Vendors do not try to hide what is being done unless it is > > an Op Sec issue and I have never seen Level3 act with less than > > responsibility so it had to be Op Sec. > > > > When it is that, it is best if the remainder of us sit quietly on the > > sidelines. > > > > Ralph Brandt > > > > > > -----Original Message----- > > From: Siegel, David [mailto:David.Siegel at Level3.com] > > Sent: Wednesday, February 06, 2013 12:01 PM > > To: 'Ray Wong'; nanog at nanog.org > > Subject: RE: Level3 worldwide emergency upgrade? > > > > Hi Ray, > > > > This topic reminds me of yesterday's discussion in the conference around > > getting some BCOP's drafted. it would be useful to confirm my own view > > of the BCOP around communicating security issues. My understanding for > > the best practice is to limit knowledge distribution of security related > > problems both before and after the patches are deployed. You limit > > knowledge before the patch is deployed to prevent yourself from being > > exploited, but you also limit knowledge afterwards in order to limit > > potential damage to others (customers, competitors...the Internet at > > large). You also do not want to announce that you will be deploying a > > security patch until you have a fix in hand and know when you will > > deploy it (typically, next available maintenance window unless the cat > > is out of the bag and danger is real and imminent). > > > > As a service provider, you should stay on top of security alerts from > > your vendors so that you can make your own decision about what action is > > required. I would not recommend relying on service provider maintenance > > bulletins or public operations mailing lists for obtaining this type of > > information. There is some information that can cause more harm than > > good if it is distributed in the wrong way and information relating to > > security vulnerabilities definitely falls into that category. > > > > Dave > > > > -----Original Message----- > > From: Ray Wong [mailto:rayw at rayw.net] > > Sent: Wednesday, February 06, 2013 9:16 AM > > To: nanog at nanog.org > > Subject: Re: Level3 worldwide emergency upgrade? > > > >> > > > > OK, having had that first cup of coffee, I can say perhaps the main > > reason I was wondering is I've gotten used to Level3 always being on top > > of things (and admittedly, rarely communicating). They've reached the > > top by often being a black box of reliability, so it's (perhaps > > unrealistically) surprising to see them caught by surprise. Anything > > that pushes them into scramble mode causes me to lose a little sleep > > anyway. The alternative to what they did seems likely for at least a few > > providers who'll NOT manage to fix things in time, so I may well be > > looking at longer outages from other providers, and need to issue > > guidance to others on what to do if/when other links go down for periods > > long enough that all the cost-bounding monitoring alarms start to scream > > even louder. > > > > I was also grumpy at myself for having not noticed advance > > communication, which I still don't seem to have, though since I > > outsourced my email to bigG, I've noticed I'm more likely to miss > > things. Perhaps giving up maintaining that massive set of procmail rules > > has cost me a bit more edge. > > > > Related, of course, just because you design/run your network to tolerate > > some issues doesn't mean you can also budget to be in support contract > > as well. :) Knowing more about the exploit/fix might mean trying to find > > a way to get free upgrades to some kit to prevent more localized attacks > > to other types of gear, as well, though in this case it's all about > > Juniper PR839412 then, so vendor specific, it seems? > > > > There are probably more reasons to wish for more info, too. There's > > still more of them (exploiters/attackers) than there are those of us > > trying to keep things running smoothly and transparently, so anything > > that smells of "OMG new exploit found!" also triggers my desire to share > > information. The network bad guys share information far more quickly and > > effectively than we do, it often seems. > > > > -R> > > > > > > > > From jcurran at arin.net Thu Feb 7 04:08:53 2013 From: jcurran at arin.net (John Curran) Date: Thu, 7 Feb 2013 04:08:53 +0000 Subject: Link to documents mentioned during ARIN Update presentation Q&A Message-ID: <8DA1853CE466B041B104C1CAEE00B3748F758ACC@CHAXCH01.corp.arin.net> NANOGers - During the Q&A portion of the ARIN Update today given at NANOG 57, I referenced some letters sent and received with regards to legacy addresses. Since a few folks have asked for a URL pointer to them, here is it: The particular question is in the FAQ section at the bottom (question #18); the links to the documents (in pdf form) are in the response text for that question. FYI, /John John Curran President and CEO ARIN From adam.vitkovsky at swan.sk Thu Feb 7 08:35:21 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Thu, 7 Feb 2013 09:35:21 +0100 Subject: Alcatel-Lucent and France Tel deploy 400G for testing In-Reply-To: <2515853.5185.1360173833619.JavaMail.root@benjamin.baylink.com> References: <2515853.5185.1360173833619.JavaMail.root@benjamin.baylink.com> Message-ID: <00f401ce050e$10e9ec90$32bdc5b0$@swan.sk> Can't find any statement whether the nifty proclaimed 400G wavelength is indeed a single 100GHz channel or just a bundled supper channel The only hint is the total capacity of a fiber of 17.6 Tbps with 44 wavelengths which is roughly the whole 100GHz spaced grid adam -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Wednesday, February 06, 2013 7:04 PM To: NANOG Subject: Alcatel-Lucent and France Tel deploy 400G for testing http://www.telecomramblings.com/2013/02/alcatel-lucent-and-france-telecom-surpass-100g-implement-400g/ -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From swmike at swm.pp.se Thu Feb 7 08:51:27 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 7 Feb 2013 09:51:27 +0100 (CET) Subject: Muni fiber: L1 or L2? In-Reply-To: References: <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> Message-ID: On Wed, 6 Feb 2013, Scott Helms wrote: > The cost difference in a single interface card to carry an OC-3/12 isn't > significantly more than a Gig-E card. Now, as I said there is no > advantage to doing ATM, but the real cost savings in a single interface > are not significant. There has always been a substantial price difference for ATM/POS compared to ethernet. But when designing ETTH networks, the cost saving is in the use of very simple devices. L2/L3 switches all the way. No tunneling, no fancy encap/decap Q-in-Q etc. Enough intelligence to do the BCP38 stuff to prevent spoofing, MitM-attacks, nothing more, but still deliver needed services over unicast and multicast. So as soon as the design contains any of the words L2TP, PPPoE/A, ATM, POS, OC-whatever, xPON or anything like it, you're incurring unneccessary cost, especially for high bw services. The most inexpensive device to L3-terminate 10GE worth of traffic from a few thousand customers is in the few thousand dollar range, what's the cost if you want to do the same using L2TP or PPPoE ? What about ATM? I don't even know if ATM on OC192/STM64 is even widely available. My guess is anyhow that you're not looking at a device that costs at least 5-10x the cost. Designing a fiber plant very much like the traditional copper plant, ie aggregating thousands of households in a single pop, and letting "anyone" terminate that fiber, is a very future proof and scalable approach. The fiber can be lit up using any technology (active p-t-p ethernet, or PON, or whatever is desired), this doesn't have to be chosen at time of actually drawing the fiber. Yes, it's a high initial cost but I firmly believe that over tens of years of lifetime of the fiber, this cost is lower than other solutions. -- Mikael Abrahamsson email: swmike at swm.pp.se From jeff.tantsura at ericsson.com Thu Feb 7 09:31:41 2013 From: jeff.tantsura at ericsson.com (Jeff Tantsura) Date: Thu, 7 Feb 2013 09:31:41 +0000 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <1BE2AC63-06D7-4FFA-B95A-7678E1C46A51@the-watsons.org> References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <20130206151037.GJ27306@dyn.com> <970945E55BFD8C4EA4CAD74B647A9DC0AF7DD2@USIDCWVEMBX10.corp.global.level3.com> <51C66083768C2949A7EB14910C78B01701D94198@embgsr24.pateam.com>, <1BE2AC63-06D7-4FFA-B95A-7678E1C46A51@the-watsons.org> Message-ID: Good times indeed... Regards, Jeff On Feb 7, 2013, at 2:09, "Brett Watson" wrote: > Hell, we used to not have to bother notifying customers of anything, we just fixed the problem. Reminds me a of a story I've probably shared on the past. > > 1995, IETF in Dallas. The "big ISP" I worked for at the time got tripped up on a 24-day IS-IS timer bug (maybe all of them at the time did, I don't recall) where all adjacencies reset at once. That's like, entire network down. Working with our engineering team in the *terminal* lab mind you, and Ravi Chandra (then at Cisco) we reloaded the entire network of routers with new code from Cisco once they'd fixed the bug. I seem to remember this being my first exposure to Tony Li's infamous line, "... Confidence Level: boots in the lab." > > Good times. > > -b > > > On Feb 6, 2013, at 5:41 PM, Brandt, Ralph wrote: > >> David. I am on an evening shift and am just now reading this thread. >> >> I was almost tempted to write an explanation that would have had >> identical content with yours based simply on Level3 doing something and >> keeping the information close. >> >> Responsible Vendors do not try to hide what is being done unless it is >> an Op Sec issue and I have never seen Level3 act with less than >> responsibility so it had to be Op Sec. >> >> When it is that, it is best if the remainder of us sit quietly on the >> sidelines. >> >> Ralph Brandt >> >> >> -----Original Message----- >> From: Siegel, David [mailto:David.Siegel at Level3.com] >> Sent: Wednesday, February 06, 2013 12:01 PM >> To: 'Ray Wong'; nanog at nanog.org >> Subject: RE: Level3 worldwide emergency upgrade? >> >> Hi Ray, >> >> This topic reminds me of yesterday's discussion in the conference around >> getting some BCOP's drafted. it would be useful to confirm my own view >> of the BCOP around communicating security issues. My understanding for >> the best practice is to limit knowledge distribution of security related >> problems both before and after the patches are deployed. You limit >> knowledge before the patch is deployed to prevent yourself from being >> exploited, but you also limit knowledge afterwards in order to limit >> potential damage to others (customers, competitors...the Internet at >> large). You also do not want to announce that you will be deploying a >> security patch until you have a fix in hand and know when you will >> deploy it (typically, next available maintenance window unless the cat >> is out of the bag and danger is real and imminent). >> >> As a service provider, you should stay on top of security alerts from >> your vendors so that you can make your own decision about what action is >> required. I would not recommend relying on service provider maintenance >> bulletins or public operations mailing lists for obtaining this type of >> information. There is some information that can cause more harm than >> good if it is distributed in the wrong way and information relating to >> security vulnerabilities definitely falls into that category. >> >> Dave >> >> -----Original Message----- >> From: Ray Wong [mailto:rayw at rayw.net] >> Sent: Wednesday, February 06, 2013 9:16 AM >> To: nanog at nanog.org >> Subject: Re: Level3 worldwide emergency upgrade? >> >> >> OK, having had that first cup of coffee, I can say perhaps the main >> reason I was wondering is I've gotten used to Level3 always being on top >> of things (and admittedly, rarely communicating). They've reached the >> top by often being a black box of reliability, so it's (perhaps >> unrealistically) surprising to see them caught by surprise. Anything >> that pushes them into scramble mode causes me to lose a little sleep >> anyway. The alternative to what they did seems likely for at least a few >> providers who'll NOT manage to fix things in time, so I may well be >> looking at longer outages from other providers, and need to issue >> guidance to others on what to do if/when other links go down for periods >> long enough that all the cost-bounding monitoring alarms start to scream >> even louder. >> >> I was also grumpy at myself for having not noticed advance >> communication, which I still don't seem to have, though since I >> outsourced my email to bigG, I've noticed I'm more likely to miss >> things. Perhaps giving up maintaining that massive set of procmail rules >> has cost me a bit more edge. >> >> Related, of course, just because you design/run your network to tolerate >> some issues doesn't mean you can also budget to be in support contract >> as well. :) Knowing more about the exploit/fix might mean trying to find >> a way to get free upgrades to some kit to prevent more localized attacks >> to other types of gear, as well, though in this case it's all about >> Juniper PR839412 then, so vendor specific, it seems? >> >> There are probably more reasons to wish for more info, too. There's >> still more of them (exploiters/attackers) than there are those of us >> trying to keep things running smoothly and transparently, so anything >> that smells of "OMG new exploit found!" also triggers my desire to share >> information. The network bad guys share information far more quickly and >> effectively than we do, it often seems. >> >> -R> > > From a.harrowell at gmail.com Thu Feb 7 10:38:31 2013 From: a.harrowell at gmail.com (Alex Harrowell) Date: Thu, 07 Feb 2013 10:38:31 +0000 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: <020901ce01d3$0da88c00$28f9a400$@iname.com> References: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> <020901ce01d3$0da88c00$28f9a400$@iname.com> Message-ID: <51138427.1070303@gmail.com> On 03/02/13 05:55, Frank Bulk wrote: > Yes, but IP TV is not profitable on stand-alone basis -- it's just a > necessary part of the triple play. A lot of the discussion has been about > Internet and network design, but not much about the other two "plays". I've certainly heard FTTH deployers mention that RFoG was important because of the impact on take-rates, which are typically the key variable in the economics. A lot of people have installed gear and subscribed channels and even internal co-ax, and it's helpful if they can plug it in the "telly port" and the football justworks on all three TVs. > > Frank > > -----Original Message----- > From: Brandon Ross [mailto:bross at pobox.com] > Sent: Saturday, February 02, 2013 3:53 PM > To: Jay Ashworth > Cc: NANOG > Subject: Re: Will wholesale-only muni actually bring the boys to your yard? > > On Sat, 2 Feb 2013, Jay Ashworth wrote: > >>> Perhaps I live in a different world, but just about all of the small to >>> midsize service providers I work with offer triple play today, and nearly >>> all of them are migrating their triple play services to IP. >> Really. Citations? I'd love to see it play that way, myself. > Okay: > > South Central Rural Telephone > Glasgow, KY > http://www.scrtc.com/ > Left side of page, "Digital TV service". See this news article: > > http://www.wcluradio.com/index.php?option=com_content&view=article&id=15567: > capacity-crowd-hears-good-report-at-scrtc-annuan-mee > > "He also reported that SCRTC is continuing to upgrade our services, > converting customers to the new IPTV service and trying to get as much > fiber optic cable built as possible." > > Camellia Communications > Greenville, AL > http://camelliacom.com/services/ctv-dvr.html > Note the models of set-top boxes they are using are IP based > > Griswold Cooperative Telephone > Griswold, IA > http://www.griswoldtelco.com/griswold-coop-iptv-video > > Farmer's Mutual Coopeative Telephone > Moulton, IA > http://farmersmutualcoop.com/ > > Citizens > Floyd, VA > http://www.citizens.coop/ > > > How about a Canadian example you say? > > CoopTel > Valcourt, QB > http://www.cooptel.qc.ca/en-residentiel-tele-guidesusager.php > Check out the models of set-top boxes here too. > > Oh, also, have you heard of ATT U-Verse? > > http://www.att.com/gen/press-room?pid=4800&cdvn=news&newsarticleid=26580 > > "AT&T U-verse TV is the only 100 percent Internet Protocol-based > television (IPTV) service offered by a national service provider" > > So even the likes of AT&T, in this scheme, could buy fiber paths to their > subs and provide TV service. I'm pretty sure AT&T knows how to deliver > voice services over IP as well. > > Do you want more examples? I bet I can come up with 50 small/regional > telecom companies that are providing TV services over IP in North America > if I put my mind to it. > From n-matsumoto at sakura.ad.jp Thu Feb 7 10:10:49 2013 From: n-matsumoto at sakura.ad.jp (Naoto MATSUMOTO) Date: Thu, 07 Feb 2013 19:10:49 +0900 Subject: FYI: PBR-LB - Direct Server Return Load Balancing using Policy Based Routing (MEMO) Message-ID: <20130207191048.B381.C42C3789@sakura.ad.jp> Hi All. Our Research Memo for Server ScaleOut Tips using Policy Based Routing is now available. PBR-LB - Direct Server Return Load Balancing using Policy Based Routing (MEMO) http://slidesha.re/VJvdbQ plz enjoy it if you are interested in this article. ;-) Best regard, -- SAKURA Internet Inc. / Senior Researcher Naoto MATSUMOTO SAKURA Research Center From nick at foobar.org Thu Feb 7 11:55:50 2013 From: nick at foobar.org (Nick Hilliard) Date: Thu, 07 Feb 2013 11:55:50 +0000 Subject: switch 10G standalone TOR, core to DC In-Reply-To: <5107B956.3080004@foobar.org> References: <5107B226.4020700@interia.pl> <5107B956.3080004@foobar.org> Message-ID: <51139646.3030105@foobar.org> On 29/01/2013 11:58, Nick Hilliard wrote: > None of them will do trill. The Extreme X670 and Juniper EX4550 will both > do VPLS, though. The X670 won't do BGP. this is incorrect: the ex4550 will do l2vpn/l3vpn but not vpls. The X480 does vpls, but not the X670. Nick From jra at baylink.com Thu Feb 7 14:40:25 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 7 Feb 2013 09:40:25 -0500 (EST) Subject: Alcatel-Lucent and France Tel deploy 400G for testing In-Reply-To: <00f401ce050e$10e9ec90$32bdc5b0$@swan.sk> Message-ID: <1198920.5257.1360248025986.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Adam Vitkovsky" > Can't find any statement whether the nifty proclaimed 400G wavelength > is indeed a single 100GHz channel or just a bundled supper channel > The only hint is the total capacity of a fiber of 17.6 Tbps with 44 > wavelengths which is roughly the whole 100GHz spaced grid Well, if you click through to his earlier piece, at http://newswire.telecomramblings.com/2013/02/france-telecom-orange-and-alcatel-lucent-deploy-worlds-first-live-400-gbps-per-wavelength-optical-link/ he does explicitly say "400Gb/s per wavelength"... Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From khelms at zcorum.com Thu Feb 7 15:18:58 2013 From: khelms at zcorum.com (Scott Helms) Date: Thu, 7 Feb 2013 10:18:58 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <510FA252.2000405@necom830.hpcl.titech.ac.jp> <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> Message-ID: On Thu, Feb 7, 2013 at 3:51 AM, Mikael Abrahamsson wrote: > On Wed, 6 Feb 2013, Scott Helms wrote: > > The cost difference in a single interface card to carry an OC-3/12 isn't >> significantly more than a Gig-E card. Now, as I said there is no advantage >> to doing ATM, but the real cost savings in a single interface are not >> significant. >> > > There has always been a substantial price difference for ATM/POS compared > to ethernet. > Yes this is true, which is why I specifically limited the scope to a single ATM interface. > > But when designing ETTH networks, the cost saving is in the use of very > simple devices. L2/L3 switches all the way. No tunneling, no fancy > encap/decap Q-in-Q etc. Enough intelligence to do the BCP38 stuff to > prevent spoofing, MitM-attacks, nothing more, but still deliver needed > services over unicast and multicast. > > So as soon as the design contains any of the words L2TP, PPPoE/A, ATM, > POS, OC-whatever, xPON or anything like it, you're incurring unneccessary > cost, especially for high bw services. > That really depends on how the technology is used, what is already in place especially on the WAN side, and what OSS the operator already has in place. Now, in general for greenfield builds I'd agree except for PON, which is in many cases cheaper than an Ethernet build. Cost of the physical pieces of the network are only one part of the cost of owning and running a network and over the long run its actually one of the smaller pieces. Now, I wouldn't build a PPPoE based network today UNLESS there were significant reasons that it would be be cheaper for that operator. The same is true of ATM, but I'll give you a concrete example of why it sometimes makes sense. In areas (and this is usually a rural challenge) there are a limited number of operators you can buy WAN connectivity from as a local ISP yourself. I have customers in Montana and Wyoming especially that have this challenge where they can either choose to pay for an ATM capable OC12 (622 mbps minus overhead) for a given price per month or a Gig-E connection for nearly twice the amount of MRC. In that case it makes much more sense to pay a 5-6 thousand more for the ATM interface once than to pay ~$1,500 per month more. This also takes into consideration that their current bandwidth requirements are around 300 mbps. > > The most inexpensive device to L3-terminate 10GE worth of traffic from a > few thousand customers is in the few thousand dollar range, what's the cost > if you want to do the same using L2TP or PPPoE ? What about ATM? I don't > even know if ATM on OC192/STM64 is even widely available. My guess is > anyhow that you're not looking at a device that costs at least 5-10x the > cost. > There are not generally available OC192 SAR engines. At the 10 Gig scale its certainly true that you'll have challenges. > > Designing a fiber plant very much like the traditional copper plant, ie > aggregating thousands of households in a single pop, and letting "anyone" > terminate that fiber, is a very future proof and scalable approach. The > fiber can be lit up using any technology (active p-t-p ethernet, or PON, or > whatever is desired), this doesn't have to be chosen at time of actually > drawing the fiber. Yes, it's a high initial cost but I firmly believe that > over tens of years of lifetime of the fiber, this cost is lower than other > solutions. That has not been demonstrated in the market. There are lots of people who say this, generally they're involved in building fiber plants, but in the US and Canada I've not seen a single report of an actual network where this was true. Do you have any documentation to this effect? I will also acknowledge that we don't have a large sample size in the US of plants built this way. > > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From drais at icantclick.org Thu Feb 7 16:59:23 2013 From: drais at icantclick.org (david raistrick) Date: Thu, 7 Feb 2013 11:59:23 -0500 (EST) Subject: NANOG 57 Notes (on location) In-Reply-To: <24839306.5215.1360184227017.JavaMail.root@benjamin.baylink.com> References: <24839306.5215.1360184227017.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, 6 Feb 2013, Jay Ashworth wrote: > ----- Original Message ----- >> From: "david raistrick" > >> sure would be nice if the nanog meetings were a bit better >> announced....why do I aways find out about the orlando ones during or >> after? > > I hadn't realized there was another one in Orlando, David; last Florida > ones I knew about were Miami, and 10 in Tampa. Yeah, my brain fart - ARIN XV was what I was thinking of (2005). -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org ascii ribbon campaign - stop html mail http://www.asciiribbon.org/ From excelsio at gmx.com Thu Feb 7 17:13:58 2013 From: excelsio at gmx.com (excelsio at gmx.com) Date: Thu, 07 Feb 2013 18:13:58 +0100 Subject: switch 10G standalone TOR, core to DC In-Reply-To: <51090F6F.1050601@interia.pl> References: <5107B226.4020700@interia.pl> <5108F643.80504@interia.pl> <51090B30.6070504@xip.at> <51090F6F.1050601@interia.pl> Message-ID: <5113E0D6.7050108@gmx.com> Well, talking about HP?s A5920/A5900 series. Last time I was looking, their virtual routing instances haven?t supported IPv4 multicast, nor IPv6 multicast/unicast, nor any policy based routing. Michael From swmike at swm.pp.se Thu Feb 7 17:24:41 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 7 Feb 2013 18:24:41 +0100 (CET) Subject: Muni fiber: L1 or L2? In-Reply-To: References: <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> Message-ID: On Thu, 7 Feb 2013, Scott Helms wrote: > That has not been demonstrated in the market. There are lots of people > who say this, generally they're involved in building fiber plants, but > in the US and Canada I've not seen a single report of an actual network > where this was true. Do you have any documentation to this effect? I > will also acknowledge that we don't have a large sample size in the US > of plants built this way. I never said there was installed base for this in north america. I have no knowledge of this. But I guess from your question that you wan to limit the discussion to what is commercially available today, which is a totally different question compared to what is best in the long run. I know the service exists here in Stockholm, Sweden. Here we don't have Telcos who sue municipality networks for providing L1 and L2 services to anyone who wants to buy them. However, the pricing model can still be worked on. Here it costs approximately 10 USD per month to rent this fiber from the central plant to the customer, meaning ISPs who have a lot of customers in a single place still opt to just rent a single operator fiber and then terminate the building fiber plant at the curb or in the building, instead of at the central (CO) plant when they light up multi-tenant buildings. -- Mikael Abrahamsson email: swmike at swm.pp.se From blair.trosper at gmail.com Thu Feb 7 17:41:59 2013 From: blair.trosper at gmail.com (Blair Trosper) Date: Thu, 7 Feb 2013 11:41:59 -0600 Subject: Google Public DNS having issues. Message-ID: ...seems to be having trouble as reported by Systems Watch: https://twitter.com/systemswatch/status/299572918936039424 Indeed, it's inaccessible to me from Minneapolis, Tampa, SJC, and Seattle...both 8.8.8.8 and 8.8.4.4. I know it's anycast, so I'm not sure which DCs are affected... Blair From deleskie at gmail.com Thu Feb 7 17:48:47 2013 From: deleskie at gmail.com (jim deleskie) Date: Thu, 7 Feb 2013 13:48:47 -0400 Subject: Google Public DNS having issues. In-Reply-To: References: Message-ID: reachable from eastern canada On Thu, Feb 7, 2013 at 1:41 PM, Blair Trosper wrote: > ...seems to be having trouble as reported by Systems Watch: > https://twitter.com/systemswatch/status/299572918936039424 > > Indeed, it's inaccessible to me from Minneapolis, Tampa, SJC, and > Seattle...both 8.8.8.8 and 8.8.4.4. > > I know it's anycast, so I'm not sure which DCs are affected... > > Blair > From mohta at necom830.hpcl.titech.ac.jp Thu Feb 7 17:58:06 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 08 Feb 2013 02:58:06 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> Message-ID: <5113EB2E.7080504@necom830.hpcl.titech.ac.jp> Scott Helms wrote: > Now, in general for greenfield builds I'd agree except for > PON, which is in many cases cheaper than an Ethernet build. As PON require considerably longer drop cable from a splitters to 4 or 8 subscribers, it can not be cheaper than Ethernet, unless subscriber density is very high. > I have customers in Montana and Wyoming especially that > have this challenge where they can either choose to pay > for an ATM capable OC12 (622 mbps minus overhead) for a > given price per month or a Gig-E connection for nearly > twice the amount of MRC. Obviously, the solution is IP over SONET. > Do you have any documentation to this effect? In http://www.soumu.go.jp/main_sosiki/joho_tsusin/policyreports/chousa/bb_seibi/pdf/041209_2_14.pdf you can see 51km cabling with PON costs 232000K JPY, whereas 221km cabling with SS costs 675000K JPY (in Japanese), For each subscriber, PON cost 311K JPY, whereas SS cost 304K JPY, even though SS case is about twice less subsrriber density (28.8 vs 16.2 subscribers/km2). Masataka Ohta From jra at baylink.com Thu Feb 7 18:39:58 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 7 Feb 2013 13:39:58 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: <5113EB2E.7080504@necom830.hpcl.titech.ac.jp> Message-ID: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Masataka Ohta" > Scott Helms wrote: > > Now, in general for greenfield builds I'd agree except for > > PON, which is in many cases cheaper than an Ethernet build. > > As PON require considerably longer drop cable from a splitters > to 4 or 8 subscribers, it can not be cheaper than Ethernet, > unless subscriber density is very high. Oh, ghod; we're not gonna go here, again, are we? Yes, a PON physical build can be somewhat cheaper, because it multiplexes your trunk cabling from 1pr per circuit to as many as 16-32pr per circuit on the trunk, allowing you to spec smaller cables. It does, however, limit you to being able to run PON capable L1 protocols over it, which may have *system*-cost implications over the life of the plant. But yes, the initial install *may* be a bit cheaper (depending on the tradeoff cost of the splitters vs the larger count fiber and the reduced size of patching facilities, and the relative cost of the access multiplexers, and... Hey, wait! How did I end up on Scott's side? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jason at thebaughers.com Thu Feb 7 19:21:07 2013 From: jason at thebaughers.com (Jason Baugher) Date: Thu, 7 Feb 2013 13:21:07 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> References: <5113EB2E.7080504@necom830.hpcl.titech.ac.jp> <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> Message-ID: In a greenfield build, cost difference for plant between PON and active will be negligible for field-based splitters, non-existent for CO-based splitters. If the company already has some fiber in the ground, then depending on where it is might drastically reduce build costs to use field-based splitters and PON. On the CO-side electronics, however... I think it's safe to say that you can do GPON under $100/port. AE is probably going to run close to $300/port. That's a pretty big cost difference, and if it were me I'd be looking pretty hard at a PON deployment for the majority of the customers along with a certain amount of fiber left over for those who need special services. On Thu, Feb 7, 2013 at 12:39 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Masataka Ohta" > > > Scott Helms wrote: > > > Now, in general for greenfield builds I'd agree except for > > > PON, which is in many cases cheaper than an Ethernet build. > > > > As PON require considerably longer drop cable from a splitters > > to 4 or 8 subscribers, it can not be cheaper than Ethernet, > > unless subscriber density is very high. > > Oh, ghod; we're not gonna go here, again, are we? > > Yes, a PON physical build can be somewhat cheaper, because it multiplexes > your trunk cabling from 1pr per circuit to as many as 16-32pr per circuit > on the trunk, allowing you to spec smaller cables. > > It does, however, limit you to being able to run PON capable L1 protocols > over it, which may have *system*-cost implications over the life of the > plant. But yes, the initial install *may* be a bit cheaper (depending > on the tradeoff cost of the splitters vs the larger count fiber and > the reduced size of patching facilities, and the relative cost of the > access multiplexers, and... > > Hey, wait! How did I end up on Scott's side? :-) > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > From khelms at zcorum.com Thu Feb 7 19:42:42 2013 From: khelms at zcorum.com (Scott Helms) Date: Thu, 7 Feb 2013 14:42:42 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> Message-ID: On Feb 7, 2013 12:24 PM, "Mikael Abrahamsson" wrote: > > On Thu, 7 Feb 2013, Scott Helms wrote: > >> That has not been demonstrated in the market. There are lots of people who say this, generally they're involved in building fiber plants, but in the US and Canada I've not seen a single report of an actual network where this was true. Do you have any documentation to this effect? I will also acknowledge that we don't have a large sample size in the US of plants built this way. > > > I never said there was installed base for this in north america. I have no knowledge of this. But I guess from your question that you wan to limit the discussion to what is commercially available today, which is a totally different question compared to what is best in the long run. Not at all, but the problem I have with projected numbers are that they frequently end up being inaccurate in the long term. If we model off of real networks then we have a much greater chance of getting the actual costs correct. > > I know the service exists here in Stockholm, Sweden. Here we don't have Telcos who sue municipality networks for providing L1 and L2 services to anyone who wants to buy them. The regulatory comment isn't particularly relevant since there in MOST places in the US muni's are free to do the same thing. IIRC, there are only 5 states that significantly restrict munis from building access networks, though there are another handful that restrict them from offering specific services. For example, in Texas a muni may not offer voice services. > > However, the pricing model can still be worked on. Here it costs approximately 10 USD per month to rent this fiber from the central plant to the customer, meaning ISPs who have a lot of customers in a single place still opt to just rent a single operator fiber and then terminate the building fiber plant at the curb or in the building, instead of at the central (CO) plant when they light up multi-tenant buildings. That $10 price tag is an easy number to toss around and in some builds it might be accurate, but the costs for the L1 infrastructure vary tremendously so using it as a guestimation is pretty dangerous. It may well be accurate in Stockholm, but its not in much/most of the US. > > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Thu Feb 7 19:43:00 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 7 Feb 2013 20:43:00 +0100 (CET) Subject: Muni fiber: L1 or L2? In-Reply-To: References: <5113EB2E.7080504@necom830.hpcl.titech.ac.jp> <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> Message-ID: On Thu, 7 Feb 2013, Jason Baugher wrote: > On the CO-side electronics, however... I think it's safe to say that you > can do GPON under $100/port. AE is probably going to run close to > $300/port. That's a pretty big cost difference, and if it were me I'd be > looking pretty hard at a PON deployment for the majority of the > customers along with a certain amount of fiber left over for those who > need special services. How do you come to the $300 per AE port? When I look at it, I get around USD100-150 per AE port including SFP. Also, I expect the customer end to be cheaper for AE than for PON, right? -- Mikael Abrahamsson email: swmike at swm.pp.se From brian at bluecoat93.org Thu Feb 7 20:10:40 2013 From: brian at bluecoat93.org (Brian Landers) Date: Thu, 7 Feb 2013 12:10:40 -0800 Subject: Level3 worldwide emergency upgrade? In-Reply-To: References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <2D0AF14BA6FB334988BC1F5D4FC38CB81E65E5D82C@EXCHMBX.hq.nac.net> <20130206131015.GE20536@hijacked.us> Message-ID: The Juniper PR in question is actually 836197. On Wed, Feb 6, 2013 at 10:22 AM, Matthew Petach wrote: > On Wed, Feb 6, 2013 at 5:10 AM, Jonathan Towne wrote: > > On Wed, Feb 06, 2013 at 07:57:06AM -0500, Alex Rubenstein scribbled: > > # The question should be more along the lines of, "why aren't you > multihomed in a way that would make a 30 minute outage (which is > inevitable) irrelevant to you? > > > > The fun part of this emergency maintenance in the northeast USA was that > even > > folks who are multihomed felt it: Level3 managed to do this in a way that > > kept BGP sessions up but killed the ability to actually pass traffic. > I'm not > > sure what they did that caused this, or whether anyone but northeast > folks > > were affected by it, but it sure was neat to be effectively blackholed > in and > > out of one of your provided circuits for a while. > > > I recommend you grab > http://kestrel3.netflight.com/2013.02.05-NANOG57-day2-afternoon-session.txt > > and search for PR8361907 > > Richard did a very good lightning talk about why > Juniper boxes will bring up BGP but blackhole > traffic for 30 minutes to over an hour, depending > on number of BGP sessions it is handling. > > His recommendation--if you don't like it, go tell > Juniper to fix that bug. > > Matt > > -- Brian C Landers http://www.packetslave.com/ CCIE #23115 (R&S + Security) From jra at baylink.com Thu Feb 7 20:41:05 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 7 Feb 2013 15:41:05 -0500 (EST) Subject: [rt-users] Ticket Image attach corruption In-Reply-To: <51140CD7.5010805@laserlinc.com> Message-ID: <4143818.5347.1360269665278.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joshua Lansford" > On 02/07/2013 02:43 PM, Jay Ashworth wrote: > > Question: do you guys make a point, at all, of evangelizing to > > distro > > maintainers and packagers that they package 4.x, or, more to the > > point > > pull 3.x*out* of repos? > > I checked and there are separate packages for rt4. I understand leaving > the 3.8 around as not to surprise folks when they do a system upgrade. Yeah. > It would have been nice if they had updated their wiki though. Quite a > bummer as I just went live. I am going to try and set up a duplicate > system on a virtual machine to test upgrade to 4.0. Thanks for > pointing this out. I will be following this guide: > http://blog.bestpractical.com/2011/07/upgrading-to-rt-4.html About the wiki, it's largely me you're complaining about, so you got the right guy: I did a large bolus of rework on it around 3.8 release time, and have not been using rt-due to job changes-since, so I haven't gotten around to reworking it again for 4.x. If I get a full-time $DAYJOB I'm in the running for right now, that will likely change, as I'll be rolling out 4.0 for there, and updating/merging the current doco to the wiki. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From fredan-nanog at fredan.se Thu Feb 7 20:46:08 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Thu, 07 Feb 2013 21:46:08 +0100 Subject: Global caches In-Reply-To: <510FDC84.9070805@fredan.se> References: <510FDC84.9070805@fredan.se> Message-ID: <51141290.8010205@fredan.se> When I did post the following, I did not, as it turns out, have good documentation of how TLMC actually works. I do hope that what I've done during these days, can describe TLMC better than the current website can. So there is a file called 'document packages' on the site right now. (tlmc-20130207-r1.tar.gz) The file 'TLMC.OVERVIEW' should, hopefully, get you an better idea of how TLMC works. The complete DNS server for both the CSP and the ISP is included as well as the plug-in for the Traffic Server (which is required to let end user/customer to cache the content at their home). >> Does anybody know of any other CDN providers that offer similar caches? >> > > Yes. > > The Last Mile Cache. > > http://tlmc.fredan.se > > It's an completely open solution for everybody, both the ISP (Internet > Service Provider) and CSP (Content Service Provider). > -- //fredan From jra at baylink.com Thu Feb 7 20:47:21 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 7 Feb 2013 15:47:21 -0500 (EST) Subject: [rt-users] Ticket Image attach corruption In-Reply-To: <4143818.5347.1360269665278.JavaMail.root@benjamin.baylink.com> Message-ID: <770305.5357.1360270041019.JavaMail.root@benjamin.baylink.com> [ Oops. Disregard. Damn, but I wish Zimbra understood List-Reply. I only hung the bug ticket 4 years (and two major releases) ago... --j ] ----- Original Message ----- > From: "Jay Ashworth" > To: "NANOG" > Sent: Thursday, February 7, 2013 3:41:05 PM > Subject: Re: [rt-users] Ticket Image attach corruption > ----- Original Message ----- > > From: "Joshua Lansford" > > > On 02/07/2013 02:43 PM, Jay Ashworth wrote: > > > Question: do you guys make a point, at all, of evangelizing to > > > distro > > > maintainers and packagers that they package 4.x, or, more to the > > > point > > > pull 3.x*out* of repos? > > > > I checked and there are separate packages for rt4. I understand > > leaving > > the 3.8 around as not to surprise folks when they do a system > > upgrade. > > Yeah. > > > It would have been nice if they had updated their wiki though. Quite > > a > > bummer as I just went live. I am going to try and set up a duplicate > > system on a virtual machine to test upgrade to 4.0. Thanks for > > pointing this out. I will be following this guide: > > http://blog.bestpractical.com/2011/07/upgrading-to-rt-4.html > > About the wiki, it's largely me you're complaining about, so you got > the right guy: I did a large bolus of rework on it around 3.8 release > time, and have not been using rt-due to job changes-since, so I > haven't > gotten around to reworking it again for 4.x. > > If I get a full-time $DAYJOB I'm in the running for right now, that > will > likely change, as I'll be rolling out 4.0 for there, and > updating/merging > the current doco to the wiki. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Thu Feb 7 21:15:29 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 7 Feb 2013 16:15:29 -0500 (EST) Subject: [rt-users] RT repo packages In-Reply-To: Message-ID: <6655377.5367.1360271729475.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Darin Perusich" > On Thu, Feb 7, 2013 at 3:38 PM, Jay Ashworth wrote: > > As a field report, BTW: SuSE 12.1 has no packages at all, even in Packman, > > and CentOS5 has only rt3 (of unknown release), even with epel and remi. > > I'm the request-tracker package maintainer for OpenSUSE and there are > current packages, rt-4.0.10, available for OpenSUSE 11.4, 12,1 and > 12.2 in the devel:languages:perl repositories. You can search all the > SuSE repositories at http://software.opensuse.org/search to find it or > use the below repo links. I'll make a note of that, but, for what its worth, I wouldn't expect to need to look for an end-user application package in a language-specific repository, which is why I had no idea it was available. I think you're shorting yourself by putting it there instead of in the mainline OSS repo. That said, thanks much for packaging it; it wasn't packaged in past years, and it was a PITA that it was not. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From David.Siegel at Level3.com Thu Feb 7 21:19:22 2013 From: David.Siegel at Level3.com (Siegel, David) Date: Thu, 7 Feb 2013 21:19:22 +0000 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <1BE2AC63-06D7-4FFA-B95A-7678E1C46A51@the-watsons.org> References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <20130206151037.GJ27306@dyn.com> <970945E55BFD8C4EA4CAD74B647A9DC0AF7DD2@USIDCWVEMBX10.corp.global.level3.com> <51C66083768C2949A7EB14910C78B01701D94198@embgsr24.pateam.com> <1BE2AC63-06D7-4FFA-B95A-7678E1C46A51@the-watsons.org> Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC0B0740E@USIDCWVEMBX10.corp.global.level3.com> I remember being glued to my workstation for 10 straight hours due to an OSPF bug that took down the whole of net99's network. I was pretty proud of our size at the time...about 30Mbps at peak. Times are different and so are expectations. :-) Dave -----Original Message----- From: Brett Watson [mailto:brett at the-watsons.org] Sent: Wednesday, February 06, 2013 6:07 PM To: nanog at nanog.org Subject: Re: Level3 worldwide emergency upgrade? Hell, we used to not have to bother notifying customers of anything, we just fixed the problem. Reminds me a of a story I've probably shared on the past. 1995, IETF in Dallas. The "big ISP" I worked for at the time got tripped up on a 24-day IS-IS timer bug (maybe all of them at the time did, I don't recall) where all adjacencies reset at once. That's like, entire network down. Working with our engineering team in the *terminal* lab mind you, and Ravi Chandra (then at Cisco) we reloaded the entire network of routers with new code from Cisco once they'd fixed the bug. I seem to remember this being my first exposure to Tony Li's infamous line, "... Confidence Level: boots in the lab." Good times. -b On Feb 6, 2013, at 5:41 PM, Brandt, Ralph wrote: > David. I am on an evening shift and am just now reading this thread. > > I was almost tempted to write an explanation that would have had > identical content with yours based simply on Level3 doing something > and keeping the information close. > > Responsible Vendors do not try to hide what is being done unless it is > an Op Sec issue and I have never seen Level3 act with less than > responsibility so it had to be Op Sec. > > When it is that, it is best if the remainder of us sit quietly on the > sidelines. > > Ralph Brandt > > > -----Original Message----- > From: Siegel, David [mailto:David.Siegel at Level3.com] > Sent: Wednesday, February 06, 2013 12:01 PM > To: 'Ray Wong'; nanog at nanog.org > Subject: RE: Level3 worldwide emergency upgrade? > > Hi Ray, > > This topic reminds me of yesterday's discussion in the conference > around getting some BCOP's drafted. it would be useful to confirm my > own view of the BCOP around communicating security issues. My > understanding for the best practice is to limit knowledge distribution > of security related problems both before and after the patches are > deployed. You limit knowledge before the patch is deployed to prevent > yourself from being exploited, but you also limit knowledge afterwards > in order to limit potential damage to others (customers, > competitors...the Internet at large). You also do not want to > announce that you will be deploying a security patch until you have a > fix in hand and know when you will deploy it (typically, next > available maintenance window unless the cat is out of the bag and danger is real and imminent). > > As a service provider, you should stay on top of security alerts from > your vendors so that you can make your own decision about what action > is required. I would not recommend relying on service provider > maintenance bulletins or public operations mailing lists for obtaining > this type of information. There is some information that can cause > more harm than good if it is distributed in the wrong way and > information relating to security vulnerabilities definitely falls into that category. > > Dave > > -----Original Message----- > From: Ray Wong [mailto:rayw at rayw.net] > Sent: Wednesday, February 06, 2013 9:16 AM > To: nanog at nanog.org > Subject: Re: Level3 worldwide emergency upgrade? > >> > > OK, having had that first cup of coffee, I can say perhaps the main > reason I was wondering is I've gotten used to Level3 always being on > top of things (and admittedly, rarely communicating). They've reached > the top by often being a black box of reliability, so it's (perhaps > unrealistically) surprising to see them caught by surprise. Anything > that pushes them into scramble mode causes me to lose a little sleep > anyway. The alternative to what they did seems likely for at least a > few providers who'll NOT manage to fix things in time, so I may well > be looking at longer outages from other providers, and need to issue > guidance to others on what to do if/when other links go down for > periods long enough that all the cost-bounding monitoring alarms start > to scream even louder. > > I was also grumpy at myself for having not noticed advance > communication, which I still don't seem to have, though since I > outsourced my email to bigG, I've noticed I'm more likely to miss > things. Perhaps giving up maintaining that massive set of procmail > rules has cost me a bit more edge. > > Related, of course, just because you design/run your network to > tolerate some issues doesn't mean you can also budget to be in support > contract as well. :) Knowing more about the exploit/fix might mean > trying to find a way to get free upgrades to some kit to prevent more > localized attacks to other types of gear, as well, though in this case > it's all about Juniper PR839412 then, so vendor specific, it seems? > > There are probably more reasons to wish for more info, too. There's > still more of them (exploiters/attackers) than there are those of us > trying to keep things running smoothly and transparently, so anything > that smells of "OMG new exploit found!" also triggers my desire to > share information. The network bad guys share information far more > quickly and effectively than we do, it often seems. > > -R> > > > From smarunich at hotmail.com Thu Feb 7 21:54:53 2013 From: smarunich at hotmail.com (Sergey Marunich) Date: Thu, 7 Feb 2013 16:54:53 -0500 Subject: switch 10G standalone TOR, core to DC In-Reply-To: <5113E0D6.7050108@gmx.com> References: <5107B226.4020700@interia.pl>, , <5108F643.80504@interia.pl> <51090B30.6070504@xip.at>, <51090F6F.1050601@interia.pl>, <5113E0D6.7050108@gmx.com> Message-ID: Hi Peter, http://www.aristanetworks.com/media/system/pdf/Datasheets/7050S_Datasheet.pdf Arista 7050S-64 48 x 10GE + 4 x 40 GE, price around 25k$ in gpl. Large buffers, supports MLAG, DCB, wire-speed L2/L3 (OSPF,BGP), but doesn't have any kind of TRILL implementation. Have it in production, but for now using for L2 only with MLAG. As option also can be considered: Brocade VDX6720, has own TRILL-like protocol to make STP-free topology, also can do L3, DCB but pay attention licensing is painful with Brocade. Best Regards,Sergey > Date: Thu, 7 Feb 2013 18:13:58 +0100 > From: excelsio at gmx.com > To: nanog at nanog.org > Subject: Re: switch 10G standalone TOR, core to DC > > Well, talking about HP?s A5920/A5900 series. Last time I was looking, > their virtual routing instances haven?t supported IPv4 multicast, nor > IPv6 multicast/unicast, nor any policy based routing. > > Michael > From dorian at blackrose.org Thu Feb 7 22:12:14 2013 From: dorian at blackrose.org (Dorian Kim) Date: Thu, 7 Feb 2013 17:12:14 -0500 Subject: Level3 worldwide emergency upgrade? In-Reply-To: <970945E55BFD8C4EA4CAD74B647A9DC0B0740E@USIDCWVEMBX10.corp.global.level3.com> References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <20130206151037.GJ27306@dyn.com> <970945E55BFD8C4EA4CAD74B647A9DC0AF7DD2@USIDCWVEMBX10.corp.global.level3.com> <51C66083768C2949A7EB14910C78B01701D94198@embgsr24.pateam.com> <1BE2AC63-06D7-4FFA-B95A-7678E1C46A51@the-watsons.org> <970945E55BFD8C4EA4CAD74B647A9DC0B0740E@USIDCWVEMBX10.corp.global.level3.com> Message-ID: <5F2DBAE3-685F-42A4-A120-15D6CF49DB83@blackrose.org> No one had hit the ISIS bug before the IETF enforced maintenance freeze because no one in their right mind would be running three week old code back then. I don't think things have changed that much. ;) -dorian On Feb 7, 2013, at 4:19 PM, Siegel, David wrote: > I remember being glued to my workstation for 10 straight hours due to an OSPF bug that took down the whole of net99's network. > > I was pretty proud of our size at the time...about 30Mbps at peak. Times are different and so are expectations. :-) > > Dave > > > -----Original Message----- > From: Brett Watson [mailto:brett at the-watsons.org] > Sent: Wednesday, February 06, 2013 6:07 PM > To: nanog at nanog.org > Subject: Re: Level3 worldwide emergency upgrade? > > Hell, we used to not have to bother notifying customers of anything, we just fixed the problem. Reminds me a of a story I've probably shared on the past. > > 1995, IETF in Dallas. The "big ISP" I worked for at the time got tripped up on a 24-day IS-IS timer bug (maybe all of them at the time did, I don't recall) where all adjacencies reset at once. That's like, entire network down. Working with our engineering team in the *terminal* lab mind you, and Ravi Chandra (then at Cisco) we reloaded the entire network of routers with new code from Cisco once they'd fixed the bug. I seem to remember this being my first exposure to Tony Li's infamous line, "... Confidence Level: boots in the lab." > > Good times. > > -b > > > On Feb 6, 2013, at 5:41 PM, Brandt, Ralph wrote: > >> David. I am on an evening shift and am just now reading this thread. >> >> I was almost tempted to write an explanation that would have had >> identical content with yours based simply on Level3 doing something >> and keeping the information close. >> >> Responsible Vendors do not try to hide what is being done unless it is >> an Op Sec issue and I have never seen Level3 act with less than >> responsibility so it had to be Op Sec. >> >> When it is that, it is best if the remainder of us sit quietly on the >> sidelines. >> >> Ralph Brandt >> >> >> -----Original Message----- >> From: Siegel, David [mailto:David.Siegel at Level3.com] >> Sent: Wednesday, February 06, 2013 12:01 PM >> To: 'Ray Wong'; nanog at nanog.org >> Subject: RE: Level3 worldwide emergency upgrade? >> >> Hi Ray, >> >> This topic reminds me of yesterday's discussion in the conference >> around getting some BCOP's drafted. it would be useful to confirm my >> own view of the BCOP around communicating security issues. My >> understanding for the best practice is to limit knowledge distribution >> of security related problems both before and after the patches are >> deployed. You limit knowledge before the patch is deployed to prevent >> yourself from being exploited, but you also limit knowledge afterwards >> in order to limit potential damage to others (customers, >> competitors...the Internet at large). You also do not want to >> announce that you will be deploying a security patch until you have a >> fix in hand and know when you will deploy it (typically, next >> available maintenance window unless the cat is out of the bag and danger is real and imminent). >> >> As a service provider, you should stay on top of security alerts from >> your vendors so that you can make your own decision about what action >> is required. I would not recommend relying on service provider >> maintenance bulletins or public operations mailing lists for obtaining >> this type of information. There is some information that can cause >> more harm than good if it is distributed in the wrong way and >> information relating to security vulnerabilities definitely falls into that category. >> >> Dave >> >> -----Original Message----- >> From: Ray Wong [mailto:rayw at rayw.net] >> Sent: Wednesday, February 06, 2013 9:16 AM >> To: nanog at nanog.org >> Subject: Re: Level3 worldwide emergency upgrade? >> >>> >> >> OK, having had that first cup of coffee, I can say perhaps the main >> reason I was wondering is I've gotten used to Level3 always being on >> top of things (and admittedly, rarely communicating). They've reached >> the top by often being a black box of reliability, so it's (perhaps >> unrealistically) surprising to see them caught by surprise. Anything >> that pushes them into scramble mode causes me to lose a little sleep >> anyway. The alternative to what they did seems likely for at least a >> few providers who'll NOT manage to fix things in time, so I may well >> be looking at longer outages from other providers, and need to issue >> guidance to others on what to do if/when other links go down for >> periods long enough that all the cost-bounding monitoring alarms start >> to scream even louder. >> >> I was also grumpy at myself for having not noticed advance >> communication, which I still don't seem to have, though since I >> outsourced my email to bigG, I've noticed I'm more likely to miss >> things. Perhaps giving up maintaining that massive set of procmail >> rules has cost me a bit more edge. >> >> Related, of course, just because you design/run your network to >> tolerate some issues doesn't mean you can also budget to be in support >> contract as well. :) Knowing more about the exploit/fix might mean >> trying to find a way to get free upgrades to some kit to prevent more >> localized attacks to other types of gear, as well, though in this case >> it's all about Juniper PR839412 then, so vendor specific, it seems? >> >> There are probably more reasons to wish for more info, too. There's >> still more of them (exploiters/attackers) than there are those of us >> trying to keep things running smoothly and transparently, so anything >> that smells of "OMG new exploit found!" also triggers my desire to >> share information. The network bad guys share information far more >> quickly and effectively than we do, it often seems. >> >> -R> >> >> >> > > > From cra at WPI.EDU Fri Feb 8 01:04:41 2013 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 7 Feb 2013 20:04:41 -0500 Subject: 2-Channel CWDM Add/Drop with SC/APC connectors Message-ID: <20130208010441.GN7970@angus.ind.WPI.EDU> Years ago I was able to purchase 2-Channel CWDM Plug-In 1-Wavelength Optical Add/Drop Multiplexors from Finisar with SC/APC connectors on them, even though they normally only make the SC/PC version shown here: FWSF-OADM-1-xx-SC http://www.finisar.com/products/passives/MUX-DEMUX/CWDM_OADM-1_Plug-in_Module but they won't do the SC/APC version for me now. Does anyone know of a good alternative? There are lots of options for modular/rack mount 2-Channel CWDM Add/Drops that have SC/PC or LC/PC connectors made for data networks. There are also lots of options for 1-Channel SC/APC or LC/APC modules made for CATV applications. But I'm having trouble finding 2-Channel versions with APC connectors that I can use with data equipment + CATV transmission on the same ring. I know I could combine two separate 1-Channel OADMs, but I prefer the integrated, modular solution. A bonus would be to find an alternative that fits in my existing Finisar 2-slot 1U chassis. In any case, I'm open to hearing about all options. Actually, I already have the 1490nm OADM in the SC/PC version, and I suppose I could cut off the connectors re-terminate with SC/APC and replace the bulkhead connectors with the green ones. My preferred fiber contractor doesn't have experience with terminating APC connectors though. Is it that much harder to terminate the angled connectors? Thanks, Chuck From faisal at snappydsl.net Fri Feb 8 01:56:08 2013 From: faisal at snappydsl.net (Faisal Imtiaz) Date: Thu, 7 Feb 2013 20:56:08 -0500 Subject: 2-Channel CWDM Add/Drop with SC/APC connectors In-Reply-To: <20130208010441.GN7970@angus.ind.WPI.EDU> References: <20130208010441.GN7970@angus.ind.WPI.EDU> Message-ID: <4058F446-43C0-4AF6-8B53-7F3614CC4882@snappydsl.net> http://datainterfaces.com/CWDM-DWDM-Solutions.aspx Try these folks. Faisal On Feb 7, 2013, at 8:04 PM, Chuck Anderson wrote: > Years ago I was able to purchase 2-Channel CWDM Plug-In 1-Wavelength > Optical Add/Drop Multiplexors from Finisar with SC/APC connectors on > them, even though they normally only make the SC/PC version shown > here: > > FWSF-OADM-1-xx-SC > > http://www.finisar.com/products/passives/MUX-DEMUX/CWDM_OADM-1_Plug-in_Module > > but they won't do the SC/APC version for me now. > > Does anyone know of a good alternative? There are lots of options for > modular/rack mount 2-Channel CWDM Add/Drops that have SC/PC or LC/PC > connectors made for data networks. There are also lots of options for > 1-Channel SC/APC or LC/APC modules made for CATV applications. But > I'm having trouble finding 2-Channel versions with APC connectors that > I can use with data equipment + CATV transmission on the same ring. > > I know I could combine two separate 1-Channel OADMs, but I prefer the > integrated, modular solution. A bonus would be to find an alternative > that fits in my existing Finisar 2-slot 1U chassis. > > In any case, I'm open to hearing about all options. Actually, I > already have the 1490nm OADM in the SC/PC version, and I suppose I > could cut off the connectors re-terminate with SC/APC and replace the > bulkhead connectors with the green ones. My preferred fiber > contractor doesn't have experience with terminating APC connectors > though. Is it that much harder to terminate the angled connectors? > > Thanks, > Chuck > > From johnl at iecc.com Fri Feb 8 04:39:45 2013 From: johnl at iecc.com (John Levine) Date: 8 Feb 2013 04:39:45 -0000 Subject: Any experience with Grandstream VoIP equipment ? Message-ID: <20130208043945.3101.qmail@joyce.lan> I'm in the midst of what would be a comedy of errors if it weren't so annoying. I bought a new Grandstream HT701 VoIP terminal adapter from a guy on eBay who is apparently an official Grandstream reseller. It doesn't work. The guy I bought it from (whose support ends at "nobody else has that problem") pointed fingers at Grandstream, whose support has been, well, impressive and not in a good way. I've done packet traces on the LAN with the box, I know what the problem is: there's something wrong with the box so it doesn't respond to the Proxy-Authenticate: challenge from my SIP provider. I know the challenge is OK, I have an old VoIP phone of theirs which works fine, on the same LAN with the same provider and the same configuration. Unfortunately, Grandstream's support staff is apparently unfamilar with packet traces and networks, and after a variety of obviously wrong diagoses (no, it's not a NAT problem, you can see the responses coming back from the remote system, etc.) seems unable to understand that a packet trace is, you know, a trace of the actual packets that have passed by the device's NIC. There's more, but you get the idea. Does anyone else here use their equipment? Is there any way to find support for this stuff who can actually provide support? R's, John From mohta at necom830.hpcl.titech.ac.jp Fri Feb 8 08:36:31 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 08 Feb 2013 17:36:31 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> References: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> Message-ID: <5114B90F.50002@necom830.hpcl.titech.ac.jp> Jay Ashworth wrote: >> As PON require considerably longer drop cable from a splitters >> to 4 or 8 subscribers, it can not be cheaper than Ethernet, >> unless subscriber density is very high. > > Oh, ghod; we're not gonna go here, again, are we? That PON is more expensive than SS is the reality of an example contained in a document provided by regulatory body (soumu sho) of Japanese government. http://www.soumu.go.jp/main_sosiki/joho_tsusin/policyreports/chousa/bb_seibi/pdf/041209_2_14.pdf. Assume you have 4000 subscribers and total trunk cable length is 51.1Km, which is the PON case with example and trunk cable length will be identical regardless of whether you use PON or SS. The problem of PON is that, to efficiently share a fiber and a splitter, they must be shared by many subscribers, which means drop cables are longer than those of SS. For example, if drop cables of PON are 10m longer in average than that of SS, it's total length is 40km, which is *SIGNIFICANT*. Just as the last miles matter, the last yards do matter. > Yes, a PON physical build can be somewhat cheaper, because it multiplexes > your trunk cabling from 1pr per circuit to as many as 16-32pr per circuit > on the trunk, allowing you to spec smaller cables. That is a negligible part of the cost. Cable cost is not very sensitive to the number of fibers in a cable. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Fri Feb 8 08:48:24 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 08 Feb 2013 17:48:24 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: <5114B90F.50002@necom830.hpcl.titech.ac.jp> References: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> <5114B90F.50002@necom830.hpcl.titech.ac.jp> Message-ID: <5114BBD8.6050501@necom830.hpcl.titech.ac.jp> Masataka Ohta wrote: > Assume you have 4000 subscribers and total trunk cable length Correction. Though I wrote 4000, it is a population and the number of subscribers are 1150. > For example, if drop cables of PON are 10m longer in average than > that of SS, it's total length is 40km, which is *SIGNIFICANT*. Total drop cable length is still 11.5km and is *SIGNIFICANT*. Note that when population density is lower, extra drop cable length will be longer that 10m is now a very humble estimation. As for equipment cost, for CO PON 92000 KJPY/1150 SS 182000 KJPY/3100 and for CP PON 33200 KJPY/1150 SS 84600 KJPY/3100 not so different but SS is a little more inexpensive. Masataka Ohta From thilo.bangert at gmail.com Fri Feb 8 09:55:34 2013 From: thilo.bangert at gmail.com (Thilo Bangert) Date: Fri, 08 Feb 2013 10:55:34 +0100 Subject: 2-Channel CWDM Add/Drop with SC/APC connectors In-Reply-To: <20130208010441.GN7970@angus.ind.WPI.EDU> References: <20130208010441.GN7970@angus.ind.WPI.EDU> Message-ID: <2106315.rcdYSKZv0V@gaston> On Thursday, February 07, 2013 08:04:41 PM Chuck Anderson wrote: > Years ago I was able to purchase 2-Channel CWDM Plug-In 1-Wavelength > Optical Add/Drop Multiplexors from Finisar with SC/APC connectors on > them, even though they normally only make the SC/PC version shown > here: > > FWSF-OADM-1-xx-SC > > http://www.finisar.com/products/passives/MUX-DEMUX/CWDM_OADM-1_Plug-in_Modul > e > > but they won't do the SC/APC version for me now. > > Does anyone know of a good alternative? for cwdm ADM i dont, sorry. our supplier just has regular multiplexers. [snip] > Is it that much harder to terminate the angled connectors? no - its just a different type of pigtail, but adding another splice, will increase the insertion loss slightly. we once ordered a cwdm splitter box at a different than usual place - as always with sc/apc connectors. the supplier changed the pigtails to accomodate our request. unfortunatly he didnt change the bulkheads, which was less than helpfull. kind regards Thilo > > Thanks, > Chuck From jfmezei_nanog at vaxination.ca Fri Feb 8 10:53:27 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 08 Feb 2013 05:53:27 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <5114B90F.50002@necom830.hpcl.titech.ac.jp> References: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> <5114B90F.50002@necom830.hpcl.titech.ac.jp> Message-ID: <5114D927.10908@vaxination.ca> On 13-02-08 03:36, Masataka Ohta wrote: > The problem of PON is that, to efficiently share a fiber and > a splitter, they must be shared by many subscribers, which > means drop cables are longer than those of SS. Pardon my ignorance here, but could you explain why the cables would be physically different in the last mile ? It is my understanding that the last mile of a PON and a point to point would be indentical with individual strands for each home passed, and then a drop between the cable and each home that wishes to connect. Why would this be different in a PON vs Point to Point system ? Wher I see a difference is between the neighbourhood aggregation point and the CO where the PON system will have just 1 strand for 32 homes whereas point to point will have 1 strand per home passed. But the lengths should be the same, shouldn't they ? From mwalter at 3z.net Fri Feb 8 13:11:56 2013 From: mwalter at 3z.net (Mike Walter) Date: Fri, 8 Feb 2013 13:11:56 +0000 Subject: Windstream Issues Message-ID: Is everyone having Windstream issues? Our BGP sessions are down and MPLS network connectivity as of 2/8 @ 3:56 am EST. -Mike From fredan-nanog at fredan.se Fri Feb 8 13:23:37 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Fri, 08 Feb 2013 14:23:37 +0100 Subject: The 100 Gbit/s problem in your network Message-ID: <5114FC59.9030406@fredan.se> - Well, as it turns out, we don't have that kind of a problem. - You don't? - No, we do not have that kind of a problem in our network. We have plenty of bandwidth available to our customers, thank-you-every-much. - Do you have, just to make an example, about 10 000 customers in a specific area, like an city/county or part of a city/county? - Yes, of course! - Does these customers have at least 10 Mbit/s connection to the Internet? - Yes! Who do you think we are, like stupid! Haha! - Could all those 10 000 customers, just to make it theoretical, hit the 'play'-button on their Internet-connected-TV, at the same time, to watch the latest Quad-HD movie? - Yes. Oh wait a minute now! This is not fair! Damn. We're toast. -- //fredan From jra at baylink.com Fri Feb 8 13:38:46 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 08 Feb 2013 08:38:46 -0500 Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: <20130208043945.3101.qmail@joyce.lan> References: <20130208043945.3101.qmail@joyce.lan> Message-ID: <5a29d7e4-b71f-4f18-a99c-27efbf8666db@email.android.com> You should try the voiceops list. Or maybe #natog John Levine wrote: >I'm in the midst of what would be a comedy of errors if it weren't so >annoying. I bought a new Grandstream HT701 VoIP terminal adapter from >a guy on eBay who is apparently an official Grandstream reseller. It >doesn't work. The guy I bought it from (whose support ends at "nobody >else has that problem") pointed fingers at Grandstream, whose support >has been, well, impressive and not in a good way. > >I've done packet traces on the LAN with the box, I know what the >problem is: there's something wrong with the box so it doesn't respond >to the Proxy-Authenticate: challenge from my SIP provider. I know the >challenge is OK, I have an old VoIP phone of theirs which works fine, >on the same LAN with the same provider and the same configuration. > >Unfortunately, Grandstream's support staff is apparently unfamilar >with packet traces and networks, and after a variety of obviously >wrong diagoses (no, it's not a NAT problem, you can see the responses >coming back from the remote system, etc.) seems unable to understand >that a packet trace is, you know, a trace of the actual packets that >have passed by the device's NIC. There's more, but you get the idea. > >Does anyone else here use their equipment? Is there any way to find >support for this stuff who can actually provide support? > >R's, >John -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From jra at baylink.com Fri Feb 8 13:42:05 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 08 Feb 2013 08:42:05 -0500 Subject: The 100 Gbit/s problem in your network In-Reply-To: <5114FC59.9030406@fredan.se> References: <5114FC59.9030406@fredan.se> Message-ID: <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> "Akamai". The actual example is "to watch the Super Bowl". :-) fredrik danerklint wrote: >- Well, as it turns out, we don't have that kind of a problem. > >- You don't? > >- No, we do not have that kind of a problem in our network. > We have plenty of bandwidth available to our customers, > thank-you-every-much. > >- Do you have, just to make an example, about 10 000 customers > in a specific area, like an city/county or part of a > city/county? > >- Yes, of course! > >- Does these customers have at least 10 Mbit/s connection to the > Internet? > >- Yes! Who do you think we are, like stupid! Haha! > >- Could all those 10 000 customers, just to make it theoretical, > hit the 'play'-button on their Internet-connected-TV, at the same > time, to watch the latest Quad-HD movie? > >- Yes. Oh wait a minute now! This is not fair! Damn. We're toast. > > >-- >//fredan -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From hank at efes.iucc.ac.il Fri Feb 8 14:08:33 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 08 Feb 2013 16:08:33 +0200 Subject: Ddos mitigation service In-Reply-To: References: <2ba901ce008d$1993d2f0$4cbb78d0$@paulstewart.org> <510BD7E8.4010805@userid.org> <2ba901ce008d$1993d2f0$4cbb78d0$@paulstewart.org> Message-ID: <5.1.1.6.2.20130208160646.002fe088@efes.iucc.ac.il> At 11:06 01/02/2013 -0500, Patrick W. Gilmore wrote: >On Feb 01, 2013, at 10:02 , "Paul Stewart" wrote: > > > Akamai (CDN) does scrubbing??? > > > >I'm sure there are other things Akamai does in the security sector as well. And now Juniper is possibly getting into the act: http://forums.juniper.net/t5/The-New-Network/Juniper-Networks-Acquires-Webscreen-Systems/ba-p/177177 -Hank From aledm at qix.co.uk Fri Feb 8 14:15:40 2013 From: aledm at qix.co.uk (Aled Morris) Date: Fri, 8 Feb 2013 14:15:40 +0000 Subject: The 100 Gbit/s problem in your network In-Reply-To: <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> Message-ID: "Multicast" Aled On 8 February 2013 13:42, Jay Ashworth wrote: > "Akamai". > > The actual example is "to watch the Super Bowl". :-) > > fredrik danerklint wrote: > > >- Well, as it turns out, we don't have that kind of a problem. > > > >- You don't? > > > >- No, we do not have that kind of a problem in our network. > > We have plenty of bandwidth available to our customers, > > thank-you-every-much. > > > >- Do you have, just to make an example, about 10 000 customers > > in a specific area, like an city/county or part of a > > city/county? > > > >- Yes, of course! > > > >- Does these customers have at least 10 Mbit/s connection to the > > Internet? > > > >- Yes! Who do you think we are, like stupid! Haha! > > > >- Could all those 10 000 customers, just to make it theoretical, > > hit the 'play'-button on their Internet-connected-TV, at the same > > time, to watch the latest Quad-HD movie? > > > >- Yes. Oh wait a minute now! This is not fair! Damn. We're toast. > > > > > >-- > >//fredan > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > From jason at thebaughers.com Fri Feb 8 14:18:02 2013 From: jason at thebaughers.com (Jason Baugher) Date: Fri, 8 Feb 2013 08:18:02 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: <5114B90F.50002@necom830.hpcl.titech.ac.jp> References: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> <5114B90F.50002@necom830.hpcl.titech.ac.jp> Message-ID: On Fri, Feb 8, 2013 at 2:36 AM, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > Jay Ashworth wrote: > > >> As PON require considerably longer drop cable from a splitters > >> to 4 or 8 subscribers, it can not be cheaper than Ethernet, > >> unless subscriber density is very high. > > > > Oh, ghod; we're not gonna go here, again, are we? > > That PON is more expensive than SS is the reality of an example > contained in a document provided by regulatory body (soumu sho) > of Japanese government. > > > http://www.soumu.go.jp/main_sosiki/joho_tsusin/policyreports/chousa/bb_seibi/pdf/041209_2_14.pdf > . > > Sorry, but I can't read Japanese, and the pictures aren't enough to explain the thrust of the document. Also, you keep using the acronym "SS". Maybe I'm showing ignorance, but what are you referring to? A little Googling this morning only came up with SS-WDM PON, which is completely different than the PON vs Active debate we've been having. > Assume you have 4000 subscribers and total trunk cable length > is 51.1Km, which is the PON case with example and trunk cable > length will be identical regardless of whether you use PON > or SS. > > The problem of PON is that, to efficiently share a fiber and > a splitter, they must be shared by many subscribers, which > means drop cables are longer than those of SS. > > For example, if drop cables of PON are 10m longer in average than > that of SS, it's total length is 40km, which is *SIGNIFICANT*. > > Just as the last miles matter, the last yards do matter. > > > Yes, a PON physical build can be somewhat cheaper, because it multiplexes > > your trunk cabling from 1pr per circuit to as many as 16-32pr per circuit > > on the trunk, allowing you to spec smaller cables. > > That is a negligible part of the cost. Cable cost is not very > sensitive to the number of fibers in a cable. > > Masataka Ohta > > > From viraviralh at gmail.com Fri Feb 8 14:26:28 2013 From: viraviralh at gmail.com (Viral Vira) Date: Fri, 8 Feb 2013 19:56:28 +0530 Subject: Windstream Issues In-Reply-To: References: Message-ID: We are also seeing problem with Windstream that's affecting our link in Sanford.They have major outage going on and there is no ETR given. -Thanks, Viral On 8 February 2013 18:41, Mike Walter wrote: > Is everyone having Windstream issues? Our BGP sessions are down and MPLS > network connectivity as of 2/8 @ 3:56 am EST. > > -Mike > > > From ikiris at gmail.com Fri Feb 8 14:28:29 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Fri, 8 Feb 2013 08:28:29 -0600 Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: <5a29d7e4-b71f-4f18-a99c-27efbf8666db@email.android.com> References: <20130208043945.3101.qmail@joyce.lan> <5a29d7e4-b71f-4f18-a99c-27efbf8666db@email.android.com> Message-ID: My experience: we called them the princess phones. They were useful for people who wanted really big buttons, and didn't care if the phones worked half the time. I wouldn't use them unless you have a specific reason to. On Fri, Feb 8, 2013 at 7:38 AM, Jay Ashworth wrote: > You should try the voiceops list. Or maybe #natog > > John Levine wrote: > > >I'm in the midst of what would be a comedy of errors if it weren't so > >annoying. I bought a new Grandstream HT701 VoIP terminal adapter from > >a guy on eBay who is apparently an official Grandstream reseller. It > >doesn't work. The guy I bought it from (whose support ends at "nobody > >else has that problem") pointed fingers at Grandstream, whose support > >has been, well, impressive and not in a good way. > > > >I've done packet traces on the LAN with the box, I know what the > >problem is: there's something wrong with the box so it doesn't respond > >to the Proxy-Authenticate: challenge from my SIP provider. I know the > >challenge is OK, I have an old VoIP phone of theirs which works fine, > >on the same LAN with the same provider and the same configuration. > > > >Unfortunately, Grandstream's support staff is apparently unfamilar > >with packet traces and networks, and after a variety of obviously > >wrong diagoses (no, it's not a NAT problem, you can see the responses > >coming back from the remote system, etc.) seems unable to understand > >that a packet trace is, you know, a trace of the actual packets that > >have passed by the device's NIC. There's more, but you get the idea. > > > >Does anyone else here use their equipment? Is there any way to find > >support for this stuff who can actually provide support? > > > >R's, > >John > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > From JFaraone at paulo.com Fri Feb 8 13:23:40 2013 From: JFaraone at paulo.com (Jason Faraone) Date: Fri, 8 Feb 2013 13:23:40 +0000 Subject: Windstream Issues In-Reply-To: References: Message-ID: I have circuits in Nashville, Murfreesboro, and Cleveland - All are up and healthy. -----Original Message----- From: Mike Walter [mailto:mwalter at 3z.net] Sent: Friday, February 08, 2013 7:12 AM To: nanog at nanog.org Subject: Windstream Issues Is everyone having Windstream issues? Our BGP sessions are down and MPLS network connectivity as of 2/8 @ 3:56 am EST. -Mike From fredan-nanog at fredan.se Fri Feb 8 14:38:09 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Fri, 08 Feb 2013 15:38:09 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> Message-ID: <51150DD1.4020302@fredan.se> A movie is static. The content does not change despite how many times you watch it. > "Multicast" Can be useful for live events, like news or sports. I give you that. -- //fredan From ahebert at pubnix.net Fri Feb 8 14:39:13 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 08 Feb 2013 09:39:13 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <5112E110.2090400@vaxination.ca> References: <51103D0E.4050905@necom830.hpcl.titech.ac.jp> <51104465.6050606@necom830.hpcl.titech.ac.jp> <5111A10F.3060300@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C2@mailserver2007.nyigc.globe> <5111A6C6.5060803@necom830.hpcl.titech.ac.jp> <616B4ECE1290D441AD56124FEBB03D0810FE5424C8@mailserver2007.nyigc.globe> <51120B49.80606@necom830.hpcl.titech.ac.jp> <5112CFA9.3070809@necom830.hpcl.titech.ac.jp> <5112D354.1010905@vaxination.ca> <5112E110.2090400@vaxination.ca> Message-ID: <51150E11.8040204@pubnix.net> Hi, If by FTTH you mean the ADSL2+/VDSL offering they packaged as Fibe (yes the named it that). It is available to resellers... /wave ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 02/06/13 18:02, Jean-Francois Mezei wrote: > On 13-02-06 17:12, Scott Helms wrote: >> Correct, there are few things that cost nothing, but the point is here that >> PPPoE has been successful for open access to a far greater degree than any >> other technology I'm aware of > By default, Telus in western Canada has deployed ethernet based DSL for > wholesale, although PPPoE is available. Its own customers are ethernet > based wth DHCP service. > > Some of the ISPs have chosen PPPoE since it makes it easier to do usage > accounting at the router (since packets are already asscoated with the > PPPoE session account). > > The difference is that Telus had purchased/developed software that made > it easy to change the PVC to point a user to one ISP or the other, so > changing ISPs is relatively painless. Bell Canada decided to abandon > etyernet based DSL and go PPPoE because it didn't want to develop that > software. > > Bell is deploying PPPoE for its FTTH (which is not *yet) available to > wholesalers, something I am hoping to help change in the coming months) > > > However, the australian NBN model is far superior because it enables far > more flexibility such as multicasting etc. PPPoE is useless overhead if > you have the right management tools to point a customer to his ISP. (and > it also means that the wholesale infrastructure can be switch based > intead of router based). > > > > From adam.vitkovsky at swan.sk Fri Feb 8 14:39:34 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Fri, 8 Feb 2013 15:39:34 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> Message-ID: <01da01ce060a$1ce4a830$56adf890$@swan.sk> > > to watch the latest Quad-HD movie >"Multicast" -I'm afraid it has to be unicast so that people can pause/resume anytime they need to go... well you know what I mean adam From jeroen at massar.ch Fri Feb 8 14:53:50 2013 From: jeroen at massar.ch (Jeroen Massar) Date: Fri, 08 Feb 2013 15:53:50 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <01da01ce060a$1ce4a830$56adf890$@swan.sk> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <01da01ce060a$1ce4a830$56adf890$@swan.sk> Message-ID: <5115117E.7060304@massar.ch> On 2013-02-08 15:39 , Adam Vitkovsky wrote: >>> to watch the latest Quad-HD movie >> "Multicast" > -I'm afraid it has to be unicast so that people can pause/resume anytime > they need to go... well you know what I mean Works fine too with multicast, for instance with FuzzyCast: https://marcel.wanda.ch/Fuzzycast/ The only little snag with multicast is that it typically is only on the last leg and it fails when a transit or simply multiple domains become involved. Greets, Jeroen From ahebert at pubnix.net Fri Feb 8 14:58:39 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Fri, 08 Feb 2013 09:58:39 -0500 Subject: Interesting debugging: Specific packets cause some Intel gigabit ethernet controllers to reset In-Reply-To: <11656280.5209.1360183670284.JavaMail.root@benjamin.baylink.com> References: <11656280.5209.1360183670284.JavaMail.root@benjamin.baylink.com> Message-ID: <5115129F.2050904@pubnix.net> Hi, Yes I had that issue, it was a firmware problem... and a timed one too :( We had a customer with a few Raid5 of 3 drives, once 1 drive go bad he had about 20m before another drive would. And they where bricked btw, you couldn't just upload the new firmware. Wasn't an happy weekend. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 02/06/13 15:47, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Kristian Kielhofner" >> Over the year I've read some interesting (horrifying?) tales of >> debugging on NANOG. It seems I finally have my own to contribute: >> >> http://blog.krisk.org/2013/02/packets-of-death.html >> >> The strangest issue I've experienced, that's for sure. > FWIW, I had a similar situation crop up a couple of years ago with *five > different* Seagate SATA drives: they grew some specific type of bad spot > on the drive which, if you even tried to read it, would *knock the drive > adapter off line until powercycle*; even a reboot didn't clear it. > > Nice writeup. > > Cheers, > -- jra From fredan-nanog at fredan.se Fri Feb 8 15:13:44 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Fri, 08 Feb 2013 16:13:44 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <5115117E.7060304@massar.ch> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <01da01ce060a$1ce4a830$56adf890$@swan.sk> <5115117E.7060304@massar.ch> Message-ID: <51151628.9020902@fredan.se> >>>> to watch the latest Quad-HD movie >>> "Multicast" >> -I'm afraid it has to be unicast so that people can pause/resume anytime >> they need to go... well you know what I mean > > Works fine too with multicast, for instance with FuzzyCast: > https://marcel.wanda.ch/Fuzzycast/ > (I did notice that this was developed in 2001 - 2002!) That works if you are only distributing Video on Demands content. "32 seconds after the later, after the initial delay, enough data has been received such that playout can begin" So we are back to the b..u..f..f..e..r..i..n..g.. thing, again? If you also want, for example, to have the possibility to distribute software, (static content as well), can you do that with Fussycast? -- //fredan From adam.vitkovsky at swan.sk Fri Feb 8 15:17:13 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Fri, 8 Feb 2013 16:17:13 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <5115117E.7060304@massar.ch> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <01da01ce060a$1ce4a830$56adf890$@swan.sk> <5115117E.7060304@massar.ch> Message-ID: <01df01ce060f$5f3fdce0$1dbf96a0$@swan.sk> > Works fine too with multicast, for instance with FuzzyCast: Well yes but you need to make some compromises on behalf of user experience. And 30sec delay is unacceptable. You can use 10 cheaper VOD servers closer to eyeballs making it 1000 customers abusing the particular portion of the local access/aggregation network. adam From jeroen at massar.ch Fri Feb 8 15:43:54 2013 From: jeroen at massar.ch (Jeroen Massar) Date: Fri, 08 Feb 2013 16:43:54 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <51151628.9020902@fredan.se> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <01da01ce060a$1ce4a830$56adf890$@swan.sk> <5115117E.7060304@massar.ch> <51151628.9020902@fredan.se> Message-ID: <51151D3A.9060206@massar.ch> On 2013-02-08 16:13 , fredrik danerklint wrote: >>>>> to watch the latest Quad-HD movie >>>> "Multicast" >>> -I'm afraid it has to be unicast so that people can pause/resume anytime >>> they need to go... well you know what I mean >> >> Works fine too with multicast, for instance with FuzzyCast: >> https://marcel.wanda.ch/Fuzzycast/ >> > > (I did notice that this was developed in 2001 - 2002!) You really think people did not have problems with the 1mbit links they had back then? And you really think that we won't have problems with Zillion-HD or whatever they will call it in another 20 years? > That works if you are only distributing Video on Demands content. Thus the question becomes, for what would it not work? > "32 seconds after the later, after the initial delay, enough data has > been received such that playout can begin" > > So we are back to the b..u..f..f..e..r..i..n..g.. thing, again? > > If you also want, for example, to have the possibility to distribute > software, (static content as well), can you do that with Fussycast? and: On 2013-02-08 16:17 , Adam Vitkovsky wrote: > And 30sec delay is unacceptable. > You can use 10 cheaper VOD servers closer to eyeballs making it 1000 > customers abusing the particular portion of the local > access/aggregation network. Read the documents and other related literature on that site a little bit further: you can overcome those first couple of seconds by fetching those 'quickly' using unicast. Yes, that does not make it a full multicast solution, but the whole idea of multicast usage in these scenarios: less traffic on the backbone. With this setup you only get the hits for the first couple of seconds and after that they have it all from multicast. And one can of course employ strategies as used currently by for instance UPC's Horizon TV boxes that already 'tune in' to the channel that the user is likely going to zap to next, thus shaving off another few bits there too... Greets, Jeroen From fredan-nanog at fredan.se Fri Feb 8 16:03:52 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Fri, 08 Feb 2013 17:03:52 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <51151D3A.9060206@massar.ch> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <01da01ce060a$1ce4a830$56adf890$@swan.sk> <5115117E.7060304@massar.ch> <51151628.9020902@fredan.se> <51151D3A.9060206@massar.ch> Message-ID: <511521E8.2060705@fredan.se> > You really think people did not have problems with the 1mbit links they > had back then? Yes, I do. > And you really think that we won't have problems with > Zillion-HD or whatever they will call it in another 20 years? I think that this is something I'm trying to say, with the creation of this thread. >> That works if you are only distributing Video on Demands content. > Thus the question becomes, for what would it not work? >> If you also want, for example, to have the possibility to distribute >> software, (static content as well), can you do that with Fussycast? As I asked; Static content, like in files (*.zip, *.tar.gz, *.iso, etc...) > Read the documents and other related literature on that site a little > bit further: you can overcome those first couple of seconds by fetching > those 'quickly' using unicast. Since you are back to the Unicast thing, and as you sad the problem with the 1 Mbit/s links, I do think your question whould be: How could we put the cache servers right next to our DSLAM:s, aggregation switches (or what ever you want to place them in your network) and have everything that's static content, cached? I do have an suggestion for how to solve this. See my message yesterday to the mailing list. -- //fredan From joelja at bogus.com Fri Feb 8 16:12:11 2013 From: joelja at bogus.com (joel jaeggli) Date: Fri, 08 Feb 2013 08:12:11 -0800 Subject: The 100 Gbit/s problem in your network In-Reply-To: <5114FC59.9030406@fredan.se> References: <5114FC59.9030406@fredan.se> Message-ID: <511523DB.5030705@bogus.com> On 2/8/13 5:23 AM, fredrik danerklint wrote: > - Well, as it turns out, we don't have that kind of a problem. > > - You don't? > > - No, we do not have that kind of a problem in our network. > We have plenty of bandwidth available to our customers, > thank-you-every-much. > > - Do you have, just to make an example, about 10 000 customers > in a specific area, like an city/county or part of a > city/county? > > - Yes, of course! > > - Does these customers have at least 10 Mbit/s connection to the > Internet? > > - Yes! Who do you think we are, like stupid! Haha! > > - Could all those 10 000 customers, just to make it theoretical, > hit the 'play'-button on their Internet-connected-TV, at the same > time, to watch the latest Quad-HD movie? > The media market has fragmented, so unless we're talking about the first week in February in the US it's not all from one source or 3 or 5. So far the most common delivery format for quad HD content online rings in at around 20Mb/s so you're not delivering that to 10Mb/s customer(s). On the other hand, two weekends ago I bought skyrim on steam and it was delivered, all 5.5GB of it in about 20 minutes. That's not instant gratification but it's acceptable. > - Yes. Oh wait a minute now! This is not fair! Damn. We're toast. > > From fredan-nanog at fredan.se Fri Feb 8 16:23:16 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Fri, 08 Feb 2013 17:23:16 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <511523DB.5030705@bogus.com> References: <5114FC59.9030406@fredan.se> <511523DB.5030705@bogus.com> Message-ID: <51152674.2050703@fredan.se> > The media market has fragmented, so unless we're talking about the first > week in February in the US it's not all from one source or 3 or 5. Explain further. I did not get that. > So far the most common delivery format for quad HD content online rings > in at around 20Mb/s so you're not delivering that to 10Mb/s customer(s). Isn't 20 Mbit/s more than 10 Mbit/s? (If so, we're taking about 10 000 customers * 20 Mbit/s = 200 000 Mbit/s or 200 Gbit/s). > On the other hand, two weekends ago I bought skyrim on steam and it was > delivered, all 5.5GB of it in about 20 minutes. That's not instant > gratification but it's acceptable. About 40 - 50 Mbit/s. Not bad at all. Downloading software does not have to be in real-time, like watching a movie, does. -- //fredan From jeroen at massar.ch Fri Feb 8 16:31:24 2013 From: jeroen at massar.ch (Jeroen Massar) Date: Fri, 08 Feb 2013 17:31:24 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <511521E8.2060705@fredan.se> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <01da01ce060a$1ce4a830$56adf890$@swan.sk> <5115117E.7060304@massar.ch> <51151628.9020902@fredan.se> <51151D3A.9060206@massar.ch> <511521E8.2060705@fredan.se> Message-ID: <5115285C.2040104@massar.ch> On 2013-02-08 17:03 , fredrik danerklint wrote: >> You really think people did not have problems with the 1mbit links they >> had back then? > > Yes, I do. > >> And you really think that we won't have problems with >> Zillion-HD or whatever they will call it in another 20 years? > > I think that this is something I'm trying to say, with the creation of > this thread. > >>> That works if you are only distributing Video on Demands content. >> Thus the question becomes, for what would it not work? >>> If you also want, for example, to have the possibility to distribute >>> software, (static content as well), can you do that with Fussycast? > > As I asked; Static content, like in files (*.zip, *.tar.gz, *.iso, etc...) There is a difference in serving FriendsS01E01.mpg, FriendsS020E3.mkv and FriendsS03.iso ??? Video On Demand is pretty static, perfect for distributing with multicast. (now you will run out of multicast groups in IPv4/Ethernet if you have a large amount of small files though, but there are other protocols for that around) [..] > I do have an suggestion for how to solve this. See my message yesterday > to the mailing list. Ah, I get it, you are trying to get people to acknowledge the non-existence of your tool that does what every transparent HTTP proxy has been doing for years! ;) For that you do not need to do strange DNS-stealing hacks or coordination with various parties, one only has to steal port 80. For instance see this nice FAQ from 2002: http://tldp.org/HOWTO/TransparentProxy.html Fortunately quite a few content providers are moving to HTTPS so that that can't happen anymore. Greets, Jeroen From jra at baylink.com Fri Feb 8 16:36:08 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 8 Feb 2013 11:36:08 -0500 (EST) Subject: The 100 Gbit/s problem in your network In-Reply-To: <51152674.2050703@fredan.se> Message-ID: <21241255.5435.1360341368629.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "fredrik danerklint" > > The media market has fragmented, so unless we're talking about the > > first week in February in the US it's not all from one source or 3 or 5. > > Explain further. I did not get that. Joel is saying that the problem you posit: *everyone* wanting to watch the same exact thing at the same exact time, only applies to live TV, and these days, substantially the only thing that can pull anywhere *near* that kind of share is the Super Bowl, which happens to occur the first Sunday in February. Er, Febru-ANY. :-) > Isn't 20 Mbit/s more than 10 Mbit/s? (If so, we're taking about > 10 000 customers * 20 Mbit/s = 200 000 Mbit/s or 200 Gbit/s). Sure; he was just picking a nit about your specification of the customer loops: those people aren't watching QHD anyway, so no sense in using it as an exemplar. My understanding is there is no appreciable amount of QHD programming available to watch anyway, and certainly nothing a) in English b) that isn't sports. > > On the other hand, two weekends ago I bought skyrim on steam and it > > was delivered, all 5.5GB of it in about 20 minutes. That's not instant > > gratification but it's acceptable. > > About 40 - 50 Mbit/s. Not bad at all. > > Downloading software does not have to be in real-time, like watching > a movie, does. Real-time is not the constraint you're looking for. To deliver watchable video, the average end-to-end transport bit rate must merely be higher than the program encoding bitrate, with some extra overhead for the lack of real QoS and other traffic on the link; receiver buffers help with this. The only time real-time per se matters is if you're playing the same content on multiple screens and *synchronization* matters. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mfidelman at meetinghouse.net Fri Feb 8 16:40:50 2013 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Fri, 08 Feb 2013 11:40:50 -0500 Subject: Windstream Issues In-Reply-To: References: Message-ID: <51152A92.2000203@meetinghouse.net> We have hosts in their Boston data center, and haven't seen any problems. Jason Faraone wrote: > I have circuits in Nashville, Murfreesboro, and Cleveland - All are up and healthy. > > -----Original Message----- > From: Mike Walter [mailto:mwalter at 3z.net] > Sent: Friday, February 08, 2013 7:12 AM > To: nanog at nanog.org > Subject: Windstream Issues > > Is everyone having Windstream issues? Our BGP sessions are down and MPLS network connectivity as of 2/8 @ 3:56 am EST. > > -Mike > > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From NANOG at enger.us Fri Feb 8 16:49:47 2013 From: NANOG at enger.us (Robert M. Enger) Date: Fri, 08 Feb 2013 08:49:47 -0800 Subject: The 100 Gbit/s problem in your network In-Reply-To: <21241255.5435.1360341368629.JavaMail.root@benjamin.baylink.com> References: <21241255.5435.1360341368629.JavaMail.root@benjamin.baylink.com> Message-ID: <51152CAB.3040003@enger.us> Perhaps the solution is to have a 400Gbit/s problem :-) http://newswire.telecomramblings.com/2013/02/france-telecom-orange-and-alcatel-lucent-deploy-worlds-first-live-400-gbps-per-wavelength-optical-link/ From christophe at clucas.fr Fri Feb 8 16:51:52 2013 From: christophe at clucas.fr (Christophe Lucas) Date: Fri, 08 Feb 2013 17:51:52 +0100 Subject: Alcatel-Lucent and France Tel deploy 400G for testing In-Reply-To: <1198920.5257.1360248025986.JavaMail.root@benjamin.baylink.com> References: <1198920.5257.1360248025986.JavaMail.root@benjamin.baylink.com> Message-ID: Le 2013-02-07 15:40, Jay Ashworth a ?crit?: > ----- Original Message ----- >> From: "Adam Vitkovsky" > >> Can't find any statement whether the nifty proclaimed 400G >> wavelength >> is indeed a single 100GHz channel or just a bundled supper channel >> The only hint is the total capacity of a fiber of 17.6 Tbps with 44 >> wavelengths which is roughly the whole 100GHz spaced grid > > Well, if you click through to his earlier piece, at > > > http://newswire.telecomramblings.com/2013/02/france-telecom-orange-and-alcatel-lucent-deploy-worlds-first-live-400-gbps-per-wavelength-optical-link/ > > he does explicitly say "400Gb/s per wavelength"... > > Cheers, > -- jra Hello, From France Telecom : http://www.orange.com/en/press/press-releases/press-releases-2013/France-Telecom-Orange-and-Alcatel-Lucent-deploy-world-s-first-live-400-Gbps-per-wavelength-optical-link As said by Jay : 400Gbits per wavelength :) Best regards, -- Christophe Lucas http://www.clucas.fr/blog/ From saku at ytti.fi Fri Feb 8 17:02:08 2013 From: saku at ytti.fi (Saku Ytti) Date: Fri, 8 Feb 2013 19:02:08 +0200 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> Message-ID: <20130208170208.GA28509@pob.ytti.fi> On (2013-02-08 14:15 +0000), Aled Morris wrote: > "Multicast" I don't see multicast working in Internet scale. Essentially multicast means core is flow-routing. So we'd need some way to decide who gets to send their content as multicast and who are forced to send unicast. It could create de-facto monopolies, as new entries to the market wont have their multicast carried, they cannot compete pricing wise with established players who are carried. -- ++ytti From jvanick at oaknet.com Fri Feb 8 17:03:07 2013 From: jvanick at oaknet.com (Jason Vanick) Date: Fri, 08 Feb 2013 12:03:07 -0500 Subject: The 100 Gbit/s problem in your network Message-ID: <4c5j642w5i2fby2kp9bhxgih.1360342987871@email.android.com> Can you set something up for the week of the 18th? fredrik danerklint wrote: >> The media market has fragmented, so unless we're talking about the first >> week in February in the US it's not all from one source or 3 or 5. > >Explain further. I did not get that. > >> So far the most common delivery format for quad HD content online rings >> in at around 20Mb/s so you're not delivering that to 10Mb/s customer(s). > >Isn't 20 Mbit/s more than 10 Mbit/s? (If so, we're taking about >10 000 customers * 20 Mbit/s = 200 000 Mbit/s or 200 Gbit/s). > >> On the other hand, two weekends ago I bought skyrim on steam and it was >> delivered, all 5.5GB of it in about 20 minutes. That's not instant >> gratification but it's acceptable. > >About 40 - 50 Mbit/s. Not bad at all. > >Downloading software does not have to be in real-time, like watching >a movie, does. > > >-- >//fredan > > From fredan-nanog at fredan.se Fri Feb 8 17:15:25 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Fri, 08 Feb 2013 18:15:25 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <5115285C.2040104@massar.ch> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <01da01ce060a$1ce4a830$56adf890$@swan.sk> <5115117E.7060304@massar.ch> <51151628.9020902@fredan.se> <51151D3A.9060206@massar.ch> <511521E8.2060705@fredan.se> <5115285C.2040104@massar.ch> Message-ID: <511532AD.7030006@fredan.se> >> I do have an suggestion for how to solve this. See my message yesterday >> to the mailing list. > > Ah, I get it, you are trying to get people to acknowledge the > non-existence of your tool that does what every transparent HTTP proxy > has been doing for years! ;) Where exactly do you put those transparent http proxy servers in your network? > For that you do not need to do strange DNS-stealing hacks or > coordination with various parties, one only has to steal port 80. There is two thing that The Last Mile Cache does _not_ do; Steal either the DNS nor the port 80 part. (I have to give it to you that it is a DNS solution part involved in TLMC as well as a reverse proxy server). It's an solution which does not force either the CSP (Content Service Provider) nor the ISP to participate in TLMC. It will tough, allow a customer of an ISP (which has to participate in TLMC in the first place) to have it's own cache server at their home. (And yes, the CSP needs to participate as well for it to work). > Fortunately quite a few content providers are moving to HTTPS so that > that can't happen anymore. If you want your content cached at various ISP:s around the world, encrypt the content, not the session. -- //fredan From cra at WPI.EDU Fri Feb 8 17:17:54 2013 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 8 Feb 2013 12:17:54 -0500 Subject: 2-Channel CWDM Add/Drop with SC/APC connectors In-Reply-To: <2106315.rcdYSKZv0V@gaston> References: <20130208010441.GN7970@angus.ind.WPI.EDU> <2106315.rcdYSKZv0V@gaston> Message-ID: <20130208171754.GI8974@angus.ind.WPI.EDU> On Fri, Feb 08, 2013 at 10:55:34AM +0100, Thilo Bangert wrote: > On Thursday, February 07, 2013 08:04:41 PM Chuck Anderson wrote: > > Is it that much harder to terminate the angled connectors? > > no - its just a different type of pigtail, but adding another splice, will > increase the insertion loss slightly. When I looked inside the OADM module, I don't remember seeing any splices, but that may just be because I didn't look inside the optobox itself. I was under the impression that the connectors were not pigtails spliced to the optobox fibers, but rather directly terminated to the fibers emerging from the optobox. I'm not sure the optobox is meant to be opened. So my question is, how hard is it to put a raw angled connector onto a strand of fiber in the field without using factory pre-terminated pigtails? I assume the process would be the same as any other connector: insert strand, cleave, polish, but using an angled sleeve to polish the end at the correct angle? > we once ordered a cwdm splitter box at a different than usual place - as > always with sc/apc connectors. > the supplier changed the pigtails to accomodate our request. unfortunatly he > didnt change the bulkheads, which was less than helpfull. Wow, that would be confusing. From fredan-nanog at fredan.se Fri Feb 8 17:22:53 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Fri, 08 Feb 2013 18:22:53 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <21241255.5435.1360341368629.JavaMail.root@benjamin.baylink.com> References: <21241255.5435.1360341368629.JavaMail.root@benjamin.baylink.com> Message-ID: <5115346D.9080508@fredan.se> > My understanding is there is no appreciable amount of QHD programming > available to watch anyway, and certainly nothing a) in English b) that > isn't sports. Why wouldn't you like to solve the problem before it can happen? (I'm talk about static content here, not live events). -- //fredan From jra at baylink.com Fri Feb 8 17:24:46 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 08 Feb 2013 12:24:46 -0500 Subject: The 100 Gbit/s problem in your network In-Reply-To: <5115346D.9080508@fredan.se> References: <21241255.5435.1360341368629.JavaMail.root@benjamin.baylink.com> <5115346D.9080508@fredan.se> Message-ID: Again: Akamai. See also Limelight, etc... fredrik danerklint wrote: >> My understanding is there is no appreciable amount of QHD programming >> available to watch anyway, and certainly nothing a) in English b) >that >> isn't sports. > >Why wouldn't you like to solve the problem before it can happen? > >(I'm talk about static content here, not live events). > > >-- >//fredan -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From joelja at bogus.com Fri Feb 8 17:32:53 2013 From: joelja at bogus.com (joel jaeggli) Date: Fri, 08 Feb 2013 09:32:53 -0800 Subject: The 100 Gbit/s problem in your network In-Reply-To: <51152674.2050703@fredan.se> References: <5114FC59.9030406@fredan.se> <511523DB.5030705@bogus.com> <51152674.2050703@fredan.se> Message-ID: <511536C5.6080305@bogus.com> On 2/8/13 8:23 AM, fredrik danerklint wrote: >> The media market has fragmented, so unless we're talking about the first >> week in February in the US it's not all from one source or 3 or 5. > > Explain further. I did not get that. > The superbowl is the first sunday in feb, it pulls a 75 share of the tv market, about the only thing that does so it's a pretty good example of all eyeballs facing the same direction, of course it's also available via terestrial broadcast, satellite, cable RF and so forth . other than that you talking about a couple of hundred of the most popular content items, followed by a very long tail worth of everything else. While I'm pretty sure somebody in my building watches glee for example or downloaded skyfall in the last week, I'm probably the only one to have streamed a canucks hockey game from 2 weeks ago last night in 1080p. >> So far the most common delivery format for quad HD content online rings >> in at around 20Mb/s so you're not delivering that to 10Mb/s >> customer(s). > > Isn't 20 Mbit/s more than 10 Mbit/s? (If so, we're taking about > 10 000 customers * 20 Mbit/s = 200 000 Mbit/s or 200 Gbit/s). > 10Mb/s was your number not mine, my crystal ball is total garbage but I don't see delivery 20Mb/s streaming services as a dramatically different problem then delivering 6-8Mb/s streaming services is today. >> On the other hand, two weekends ago I bought skyrim on steam and it was >> delivered, all 5.5GB of it in about 20 minutes. That's not instant >> gratification but it's acceptable. > > About 40 - 50 Mbit/s. Not bad at all. > > Downloading software does not have to be in real-time, like watching > a movie, does. In both cases it's actually rather convenient if it's as fast as possible, That movie I bought 5 minutes ago from apple I might be streaming to my apple-tv (which has effectively negligible storage), or I might be dumping it on my ipad, in the later case the sooner it arrives the sooner that process is finished and I can unplug it. With the game download, with some exceptions like DLC's I can't start playing until it has arrived so fullfilment is very very important, come back tomorrow when it's done downloading loses you a lot of sales. > > From fredan-nanog at fredan.se Fri Feb 8 17:33:18 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Fri, 08 Feb 2013 18:33:18 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <21241255.5435.1360341368629.JavaMail.root@benjamin.baylink.com> <5115346D.9080508@fredan.se> Message-ID: <511536DE.9060601@fredan.se> How does Akamai or Limelight or any other CDN, allow your customers as an ISP to cache the content at their home, in their own cache server? > Again: Akamai. See also Limelight, etc... > > fredrik danerklint wrote: > >>> My understanding is there is no appreciable amount of QHD programming >>> available to watch anyway, and certainly nothing a) in English b) >> that >>> isn't sports. >> >> Why wouldn't you like to solve the problem before it can happen? >> >> (I'm talk about static content here, not live events). >> >> >> -- >> //fredan > -- //fredan http://tlmc.fredan.se From joelja at bogus.com Fri Feb 8 17:41:00 2013 From: joelja at bogus.com (joel jaeggli) Date: Fri, 08 Feb 2013 09:41:00 -0800 Subject: The 100 Gbit/s problem in your network In-Reply-To: <20130208170208.GA28509@pob.ytti.fi> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> Message-ID: <511538AC.3050602@bogus.com> On 2/8/13 9:02 AM, Saku Ytti wrote: > On (2013-02-08 14:15 +0000), Aled Morris wrote: > >> "Multicast" > I don't see multicast working in Internet scale. > > Essentially multicast means core is flow-routing. So we'd need some way to > decide who gets to send their content as multicast and who are forced to > send unicast. The market already ruled on who gets to insert MSDP state in your routers. inter-domain multicast to the extent that it exists is between consenting adults. Which is fine, it turns out we don't need it for youtube or justin.tv to exist, and I don't need to signal into the core of the internet to make my small group conferencing app work. > It could create de-facto monopolies, as new entries to the market wont have > their multicast carried, they cannot compete pricing wise with established > players who are carried. > From fredan-nanog at fredan.se Fri Feb 8 17:46:44 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Fri, 08 Feb 2013 18:46:44 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <511536C5.6080305@bogus.com> References: <5114FC59.9030406@fredan.se> <511523DB.5030705@bogus.com> <51152674.2050703@fredan.se> <511536C5.6080305@bogus.com> Message-ID: <51153A04.4090209@fredan.se> >> About 40 - 50 Mbit/s. Not bad at all. >> >> Downloading software does not have to be in real-time, like watching >> a movie, does. > In both cases it's actually rather convenient if it's as fast as > possible, Yes. What I would like to have is to allow the access switch, which a customer for an ISP is connected to, to let the customer have 1 Gbit/s of bandwidth if the traffic is to or from the cache servers at their ISP. -- //fredan From cscora at apnic.net Fri Feb 8 18:33:05 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 Feb 2013 04:33:05 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201302081833.r18IX5JL018570@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 09 Feb, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 442644 Prefixes after maximum aggregation: 182109 Deaggregation factor: 2.43 Unique aggregates announced to Internet: 217103 Total ASes present in the Internet Routing Table: 43259 Prefixes per ASN: 10.23 Origin-only ASes present in the Internet Routing Table: 34144 Origin ASes announcing only one prefix: 15933 Transit ASes present in the Internet Routing Table: 5751 Transit-only ASes present in the Internet Routing Table: 139 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 29 Max AS path prepend of ASN ( 35412) 17 Prefixes from unregistered ASNs in the Routing Table: 379 Unregistered ASNs in the Routing Table: 135 Number of 32-bit ASNs allocated by the RIRs: 3742 Number of 32-bit ASNs visible in the Routing Table: 3364 Prefixes from 32-bit ASNs in the Routing Table: 9204 Special use prefixes present in the Routing Table: 17 Prefixes being announced from unallocated address space: 196 Number of addresses announced to Internet: 2615509516 Equivalent to 155 /8s, 229 /16s and 130 /24s Percentage of available address space announced: 70.6 Percentage of allocated address space announced: 70.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.3 Total number of prefixes smaller than registry allocations: 156304 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 106381 Total APNIC prefixes after maximum aggregation: 33119 APNIC Deaggregation factor: 3.21 Prefixes being announced from the APNIC address blocks: 107440 Unique aggregates announced from the APNIC address blocks: 43969 APNIC Region origin ASes present in the Internet Routing Table: 4818 APNIC Prefixes per ASN: 22.30 APNIC Region origin ASes announcing only one prefix: 1238 APNIC Region transit ASes present in the Internet Routing Table: 801 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 423 Number of APNIC addresses announced to Internet: 718725120 Equivalent to 42 /8s, 214 /16s and 224 /24s Percentage of available APNIC address space announced: 84.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 155461 Total ARIN prefixes after maximum aggregation: 78762 ARIN Deaggregation factor: 1.97 Prefixes being announced from the ARIN address blocks: 156125 Unique aggregates announced from the ARIN address blocks: 70765 ARIN Region origin ASes present in the Internet Routing Table: 15450 ARIN Prefixes per ASN: 10.11 ARIN Region origin ASes announcing only one prefix: 5837 ARIN Region transit ASes present in the Internet Routing Table: 1597 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 29 Number of ARIN region 32-bit ASNs visible in the Routing Table: 18 Number of ARIN addresses announced to Internet: 1075995264 Equivalent to 64 /8s, 34 /16s and 98 /24s Percentage of available ARIN address space announced: 56.9 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 114050 Total RIPE prefixes after maximum aggregation: 58645 RIPE Deaggregation factor: 1.94 Prefixes being announced from the RIPE address blocks: 117158 Unique aggregates announced from the RIPE address blocks: 74928 RIPE Region origin ASes present in the Internet Routing Table: 17055 RIPE Prefixes per ASN: 6.87 RIPE Region origin ASes announcing only one prefix: 8160 RIPE Region transit ASes present in the Internet Routing Table: 2785 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2174 Number of RIPE addresses announced to Internet: 653118564 Equivalent to 38 /8s, 237 /16s and 204 /24s Percentage of available RIPE address space announced: 94.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 46948 Total LACNIC prefixes after maximum aggregation: 9123 LACNIC Deaggregation factor: 5.15 Prefixes being announced from the LACNIC address blocks: 50659 Unique aggregates announced from the LACNIC address blocks: 23552 LACNIC Region origin ASes present in the Internet Routing Table: 1810 LACNIC Prefixes per ASN: 27.99 LACNIC Region origin ASes announcing only one prefix: 521 LACNIC Region transit ASes present in the Internet Routing Table: 337 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 742 Number of LACNIC addresses announced to Internet: 123125544 Equivalent to 7 /8s, 86 /16s and 191 /24s Percentage of available LACNIC address space announced: 73.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 10472 Total AfriNIC prefixes after maximum aggregation: 2408 AfriNIC Deaggregation factor: 4.35 Prefixes being announced from the AfriNIC address blocks: 11066 Unique aggregates announced from the AfriNIC address blocks: 3716 AfriNIC Region origin ASes present in the Internet Routing Table: 593 AfriNIC Prefixes per ASN: 18.66 AfriNIC Region origin ASes announcing only one prefix: 177 AfriNIC Region transit ASes present in the Internet Routing Table: 133 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 16 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 7 Number of AfriNIC addresses announced to Internet: 44187648 Equivalent to 2 /8s, 162 /16s and 64 /24s Percentage of available AfriNIC address space announced: 43.9 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2942 11558 924 Korea Telecom (KIX) 17974 2482 824 84 PT TELEKOMUNIKASI INDONESIA 7545 1824 301 88 TPG Internet Pty Ltd 4755 1684 382 190 TATA Communications formerly 9829 1428 1145 45 BSNL National Internet Backbo 9583 1204 90 499 Sify Limited 7552 1161 1070 12 Vietel Corporation 4808 1109 2040 316 CNCGROUP IP network: China169 9498 1058 310 75 BHARTI Airtel Ltd. 24560 1044 385 160 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3071 3697 105 bellsouth.net, inc. 7029 2263 1265 211 Windstream Communications Inc 18566 2081 382 183 Covad Communications 22773 1966 2931 128 Cox Communications, Inc. 1785 1953 678 125 PaeTec Communications, Inc. 20115 1689 1609 624 Charter Communications 4323 1600 1155 395 Time Warner Telecom 30036 1342 287 689 Mediacom Communications Corp 7018 1305 10552 859 AT&T WorldNet Services 7011 1200 316 683 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1872 544 16 Corbina telecom 2118 1114 97 13 EUnet/RELCOM Autonomous Syste 34984 1052 232 204 BILISIM TELEKOM 13188 854 99 22 Educational Network 12479 840 782 68 Uni2 Autonomous System 31148 757 39 17 FreeNet ISP 20940 747 255 590 Akamai Technologies European 8551 716 367 39 Bezeq International 6830 713 2313 434 UPC Distribution Services 34744 669 186 47 SC GVM SISTEM 2003 SRL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 2356 1325 86 NET Servicos de Comunicao S.A 10620 2311 396 225 TVCABLE BOGOTA 7303 1679 1147 206 Telecom Argentina Stet-France 8151 1511 2830 390 UniNet S.A. de C.V. 6503 1473 435 67 AVANTEL, S.A. 14754 940 120 78 Telgua S. A. 27947 775 86 97 Telconet S.A 18881 758 716 18 Global Village Telecom 3816 683 306 86 Empresa Nacional de Telecomun 11172 604 86 67 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1286 80 4 MOBITEL 24863 898 275 36 LINKdotNET AS number 8452 534 958 13 TEDATA 6713 499 602 20 Itissalat Al-MAGHRIB 24835 329 80 8 RAYA Telecom - Egypt 3741 266 906 224 The Internet Solution 12258 193 28 67 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 16637 191 696 90 MTN Network Solutions 29975 191 667 21 Vodacom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3071 3697 105 bellsouth.net, inc. 4766 2942 11558 924 Korea Telecom (KIX) 17974 2482 824 84 PT TELEKOMUNIKASI INDONESIA 28573 2356 1325 86 NET Servicos de Comunicao S.A 10620 2311 396 225 TVCABLE BOGOTA 7029 2263 1265 211 Windstream Communications Inc 18566 2081 382 183 Covad Communications 22773 1966 2931 128 Cox Communications, Inc. 1785 1953 678 125 PaeTec Communications, Inc. 8402 1872 544 16 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 2482 2398 PT TELEKOMUNIKASI INDONESIA 28573 2356 2270 NET Servicos de Comunicao S.A 10620 2311 2086 TVCABLE BOGOTA 7029 2263 2052 Windstream Communications Inc 4766 2942 2018 Korea Telecom (KIX) 18566 2081 1898 Covad Communications 8402 1872 1856 Corbina telecom 22773 1966 1838 Cox Communications, Inc. 1785 1953 1828 PaeTec Communications, Inc. 7545 1824 1736 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.60.0/23 57417 INTERNET TASMANIA SRL 128.0.62.0/23 57417 INTERNET TASMANIA SRL 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.96.0/21 12886 LEWTelNet GmbH 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.210.16.0/22 15657 Neural Networks ASN 41.138.95.0/24 36930 ZanZibar Telecom 41.222.80.0/21 37110 Moztel LDA 62.12.96.0/19 38478 SunnyVision Limited 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:17 /9:13 /10:29 /11:88 /12:246 /13:482 /14:865 /15:1551 /16:12571 /17:6599 /18:10990 /19:21739 /20:31215 /21:33260 /22:45385 /23:41009 /24:232313 /25:1374 /26:1745 /27:861 /28:181 /29:74 /30:16 /31:0 /32:21 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2031 2081 Covad Communications 6389 1759 3071 bellsouth.net, inc. 7029 1637 2263 Windstream Communications Inc 8402 1601 1872 Corbina telecom 22773 1292 1966 Cox Communications, Inc. 36998 1280 1286 MOBITEL 30036 1234 1342 Mediacom Communications Corp 11492 1158 1195 Cable One 1785 1033 1953 PaeTec Communications, Inc. 6503 983 1473 AVANTEL, S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:668 2:731 3:3 4:13 5:748 6:3 8:486 12:1930 13:3 14:738 15:11 16:3 17:8 20:24 23:237 24:1801 27:1474 31:1129 32:54 33:2 34:5 36:10 37:1299 38:846 39:2 40:141 41:2685 42:179 44:4 46:1735 47:1 49:577 50:648 52:12 54:28 55:7 57:28 58:1082 59:559 60:251 61:1317 62:1025 63:2025 64:4320 65:2143 66:4272 67:2022 68:1121 69:3248 70:858 71:532 72:1876 74:2536 75:421 76:291 77:1072 78:1028 79:555 80:1226 81:992 82:638 83:539 84:574 85:1150 86:475 87:980 88:376 89:1743 90:286 91:5384 92:626 93:1706 94:2030 95:1607 96:490 97:334 98:1049 99:52 100:30 101:313 103:2094 105:519 106:132 107:207 108:511 109:1765 110:854 111:1012 112:480 113:735 114:685 115:922 116:873 117:792 118:980 119:1267 120:375 121:699 122:1734 123:1190 124:1317 125:1309 128:548 129:201 130:313 131:649 132:326 133:143 134:260 135:62 136:222 137:235 138:342 139:155 140:216 141:315 142:501 143:390 144:481 145:88 146:530 147:357 148:727 149:341 150:158 151:400 152:395 153:190 154:27 155:370 156:241 157:392 158:259 159:697 160:334 161:422 162:361 163:203 164:580 165:448 166:439 167:573 168:1009 169:131 170:1016 171:164 172:4 173:1545 174:613 175:421 176:1123 177:1677 178:1739 180:1373 181:220 182:1147 183:317 184:632 185:217 186:2268 187:1421 188:1967 189:1548 190:6641 192:6320 193:5672 194:4640 195:3650 196:1302 197:848 198:4131 199:5195 200:6045 201:2182 202:8895 203:8770 204:4439 205:2542 206:2798 207:2804 208:4056 209:3514 210:2919 211:1568 212:2013 213:1887 214:904 215:93 216:5088 217:1582 218:592 219:328 220:1264 221:550 222:337 223:422 End of report From joelja at bogus.com Fri Feb 8 18:50:45 2013 From: joelja at bogus.com (joel jaeggli) Date: Fri, 08 Feb 2013 10:50:45 -0800 Subject: The 100 Gbit/s problem in your network In-Reply-To: <51153A04.4090209@fredan.se> References: <5114FC59.9030406@fredan.se> <511523DB.5030705@bogus.com> <51152674.2050703@fredan.se> <511536C5.6080305@bogus.com> <51153A04.4090209@fredan.se> Message-ID: <51154905.2040502@bogus.com> On 2/8/13 9:46 AM, fredrik danerklint wrote: >>> About 40 - 50 Mbit/s. Not bad at all. >>> >>> Downloading software does not have to be in real-time, like watching >>> a movie, does. >> In both cases it's actually rather convenient if it's as fast as >> possible, > > Yes. What I would like to have is to allow the access switch, which a > customer for an ISP is connected to, to let the customer have 1 Gbit/s > of bandwidth if the traffic is to or from the cache servers at their > ISP. > You're positing a situation where a cache infrastructure at scale built close to the user has a sufficiently high hit rate for rather large objects to be more cost effective than increasing capacity in the middle of the network as the bandwidth/price curve declines. My early career as an http cache dude makes me a bit suspicious. I'm pretty confident that denser/cheaper/faster silicon is less expensive than deploying boxes of spinning disks closer to the customer(s) than they are today (netflix's cache for example isn't that close to the edge (would support 2-10k simultaneous customers for that one application per box), it aims to get inside the isp however) when you add power/cooling/space/lifecycle-maintenance (I'm a datacenter operator) if it wasn't the CDN's would have pushed even closer to the edge. Of course if you can limit consumer choice then you can push your hit rate to 100% but then you're running a VOD service in a walled garden and there are plenty of those already. That said provide compelling numbers and I'll change my mind. From JTyler at fiberutilities.com Fri Feb 8 19:00:57 2013 From: JTyler at fiberutilities.com (Jensen Tyler) Date: Fri, 8 Feb 2013 19:00:57 +0000 Subject: 2-Channel CWDM Add/Drop with SC/APC connectors In-Reply-To: <20130208171754.GI8974@angus.ind.WPI.EDU> References: <20130208010441.GN7970@angus.ind.WPI.EDU> <2106315.rcdYSKZv0V@gaston> <20130208171754.GI8974@angus.ind.WPI.EDU> Message-ID: I have seen cwdm Add/Drop muxes that fit in a splice case. May fit what you need. Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC Suite 500, 222 3rd Ave, SE Cedar Rapids, IA 52401 http://www.fiberutilities.com -----Original Message----- From: Chuck Anderson [mailto:cra at WPI.EDU] Sent: Friday, February 08, 2013 11:18 AM To: nanog at nanog.org Subject: Re: 2-Channel CWDM Add/Drop with SC/APC connectors On Fri, Feb 08, 2013 at 10:55:34AM +0100, Thilo Bangert wrote: > On Thursday, February 07, 2013 08:04:41 PM Chuck Anderson wrote: > > Is it that much harder to terminate the angled connectors? > > no - its just a different type of pigtail, but adding another splice, > will increase the insertion loss slightly. When I looked inside the OADM module, I don't remember seeing any splices, but that may just be because I didn't look inside the optobox itself. I was under the impression that the connectors were not pigtails spliced to the optobox fibers, but rather directly terminated to the fibers emerging from the optobox. I'm not sure the optobox is meant to be opened. So my question is, how hard is it to put a raw angled connector onto a strand of fiber in the field without using factory pre-terminated pigtails? I assume the process would be the same as any other connector: insert strand, cleave, polish, but using an angled sleeve to polish the end at the correct angle? > we once ordered a cwdm splitter box at a different than usual place - > as always with sc/apc connectors. > the supplier changed the pigtails to accomodate our request. > unfortunatly he didnt change the bulkheads, which was less than helpfull. Wow, that would be confusing. From jra at baylink.com Fri Feb 8 19:35:44 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 8 Feb 2013 14:35:44 -0500 (EST) Subject: The 100 Gbit/s problem in your network In-Reply-To: <51155330.40908@fredan.se> Message-ID: <2393592.5481.1360352144518.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "fredrik danerklint" > > "allow my customers as an ISP to cache the content at their home". > > > > Do you *mean* "their home" -- an end-user residence? > > Yes, I do *mean* that. > > As in you, Jay, should be allowed to run your own cache server in your > home (Traffic Server is the one that I'm using in the TLMC concept). > > Wouldn't you like that? It would do little good; my hit rate on such a cache would be unlikely to be high enough to merit the traffic to keep it charged. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From fredan-nanog at fredan.se Fri Feb 8 19:58:42 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Fri, 08 Feb 2013 20:58:42 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <2393592.5481.1360352144518.JavaMail.root@benjamin.baylink.com> References: <2393592.5481.1360352144518.JavaMail.root@benjamin.baylink.com> Message-ID: <511558F2.9090003@fredan.se> >>> "allow my customers as an ISP to cache the content at their home". >>> >>> Do you *mean* "their home" -- an end-user residence? >> >> Yes, I do *mean* that. >> >> As in you, Jay, should be allowed to run your own cache server in your >> home (Traffic Server is the one that I'm using in the TLMC concept). >> >> Wouldn't you like that? > > It would do little good; my hit rate on such a cache would be unlikely to > be high enough to merit the traffic to keep it charged. (Children watching a movie only once? Not a chance. It's more like unlimited number of times and then some more...). So don't set-up an cache server at your home/residence. -- //fredan From jra at baylink.com Fri Feb 8 20:11:18 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 8 Feb 2013 15:11:18 -0500 (EST) Subject: The 100 Gbit/s problem in your network In-Reply-To: <511558F2.9090003@fredan.se> Message-ID: <31245655.5493.1360354278086.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "fredrik danerklint" > > It would do little good; my hit rate on such a cache would be > > unlikely to be high enough to merit the traffic to keep it charged. > > (Children watching a movie only once? Not a chance. It's more like > unlimited number of times and then some more...). "DVD's." "MythTV" > So don't set-up an cache server at your home/residence. I probably won't. But it has become unclear what your fundamental premise and argument are, by this point in the game. Is it: "it is bad that content providers choose a business and technical model wherein local in-home transparent caching proxies won't work?" Cause that's a non-starter. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From aplato at coldwater.org Fri Feb 8 20:15:50 2013 From: aplato at coldwater.org (Art Plato) Date: Fri, 8 Feb 2013 15:15:50 -0500 (EST) Subject: The 100 Gbit/s problem in your network In-Reply-To: <511558F2.9090003@fredan.se> Message-ID: <3940444.187.1360354551648.JavaMail.art@DQT6ZQ1> How about buy the movies in question, convert them to MP4, install a media server on a local box and configure Xbox, tablet, smart-phone, whatever to access the media server? That is how my 3 year old grandson watches the Bubble Guppies movie umpteen million times during a 4 day stay. Just a thought. Oh, it also affords my wife and I the luxury of having our entire movie collection available for on demand viewing. No searching through cases or disc binders. Just a thought. ----- Original Message ----- From: "fredrik danerklint" To: nanog at nanog.org Sent: Friday, February 8, 2013 2:58:42 PM Subject: Re: The 100 Gbit/s problem in your network >>> "allow my customers as an ISP to cache the content at their home". >>> >>> Do you *mean* "their home" -- an end-user residence? >> >> Yes, I do *mean* that. >> >> As in you, Jay, should be allowed to run your own cache server in your >> home (Traffic Server is the one that I'm using in the TLMC concept). >> >> Wouldn't you like that? > > It would do little good; my hit rate on such a cache would be unlikely to > be high enough to merit the traffic to keep it charged. (Children watching a movie only once? Not a chance. It's more like unlimited number of times and then some more...). So don't set-up an cache server at your home/residence. -- //fredan From kris at kriskinc.com Fri Feb 8 20:50:51 2013 From: kris at kriskinc.com (Kristian Kielhofner) Date: Fri, 8 Feb 2013 15:50:51 -0500 Subject: Interesting debugging: Specific packets cause some Intel gigabit ethernet controllers to reset In-Reply-To: References: Message-ID: Update with a response to the statement from Intel: http://blog.krisk.org/2013/02/packets-of-death-update.html On Wed, Feb 6, 2013 at 3:33 PM, Kristian Kielhofner wrote: > Over the year I've read some interesting (horrifying?) tales of > debugging on NANOG. It seems I finally have my own to contribute: > > http://blog.krisk.org/2013/02/packets-of-death.html > > The strangest issue I've experienced, that's for sure. > > -- > Kristian Kielhofner -- Kristian Kielhofner From j at 2600hz.com Fri Feb 8 20:56:59 2013 From: j at 2600hz.com (Joshua Goldbard) Date: Fri, 8 Feb 2013 20:56:59 +0000 Subject: Interesting debugging: Specific packets cause some Intel gigabit ethernet controllers to reset In-Reply-To: References: Message-ID: I just want you to know that this was the best piece of technical debugging I've read in years. Absolutely awesome. Thank you so much for sharing what I can only imagine was an endless series of nightmares. I've done debugging like this before and I can only say: I feel your pain and I wish I documented my previous efforts. Great writing sir. Cheers, Joshua Joshua Goldbard VP of Marketing, 2600hz 116 Natoma Street, Floor 2 San Francisco, CA, 94104 415.886.7923 | j at 2600hz.com On Feb 8, 2013, at 12:50 PM, Kristian Kielhofner > wrote: Update with a response to the statement from Intel: http://blog.krisk.org/2013/02/packets-of-death-update.html On Wed, Feb 6, 2013 at 3:33 PM, Kristian Kielhofner wrote: Over the year I've read some interesting (horrifying?) tales of debugging on NANOG. It seems I finally have my own to contribute: http://blog.krisk.org/2013/02/packets-of-death.html The strangest issue I've experienced, that's for sure. -- Kristian Kielhofner -- Kristian Kielhofner From laurent at guerby.net Fri Feb 8 20:58:56 2013 From: laurent at guerby.net (Laurent GUERBY) Date: Fri, 08 Feb 2013 21:58:56 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <51154905.2040502@bogus.com> References: <5114FC59.9030406@fredan.se> <511523DB.5030705@bogus.com> <51152674.2050703@fredan.se> <511536C5.6080305@bogus.com> <51153A04.4090209@fredan.se> <51154905.2040502@bogus.com> Message-ID: <1360357136.3337.364.camel@pc2> On Fri, 2013-02-08 at 10:50 -0800, joel jaeggli wrote: > On 2/8/13 9:46 AM, fredrik danerklint wrote: > >>> About 40 - 50 Mbit/s. Not bad at all. > >>> > >>> Downloading software does not have to be in real-time, like watching > >>> a movie, does. > >> In both cases it's actually rather convenient if it's as fast as > >> possible, > > > > Yes. What I would like to have is to allow the access switch, which a > > customer for an ISP is connected to, to let the customer have 1 Gbit/s > > of bandwidth if the traffic is to or from the cache servers at their > > ISP. > > > You're positing a situation where a cache infrastructure at scale built > close to the user has a sufficiently high hit rate for rather large > objects to be more cost effective than increasing capacity in the > middle of the network as the bandwidth/price curve declines. My early > career as an http cache dude makes me a bit suspicious. I'm pretty > confident that denser/cheaper/faster silicon is less expensive than > deploying boxes of spinning disks closer to the customer(s) than they > are today (netflix's cache for example isn't that close to the edge > (would support 2-10k simultaneous customers for that one application per > box), it aims to get inside the isp however) when you add > power/cooling/space/lifecycle-maintenance (I'm a datacenter operator) if > it wasn't the CDN's would have pushed even closer to the edge. Of course > if you can limit consumer choice then you can push your hit rate to 100% > but then you're running a VOD service in a walled garden and there are > plenty of those already. > > That said provide compelling numbers and I'll change my mind. The "problem" with increasing capacity is that it opens up captive eyeballs to innovative services from "outside": monopoly operators will prefer to deal with CDN providers & the like and keep control. Sincerely, Laurent From morrowc.lists at gmail.com Fri Feb 8 21:13:37 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 8 Feb 2013 16:13:37 -0500 Subject: The 100 Gbit/s problem in your network In-Reply-To: <1360357136.3337.364.camel@pc2> References: <5114FC59.9030406@fredan.se> <511523DB.5030705@bogus.com> <51152674.2050703@fredan.se> <511536C5.6080305@bogus.com> <51153A04.4090209@fredan.se> <51154905.2040502@bogus.com> <1360357136.3337.364.camel@pc2> Message-ID: On Fri, Feb 8, 2013 at 3:58 PM, Laurent GUERBY wrote: > The "problem" with increasing capacity is that it opens up captive > eyeballs to innovative services from "outside": monopoly operators will > prefer to deal with CDN providers & the like and keep control. there are ways to offer vod/etc without pulling that content across your 'internet' backbone, of course you'd still have to provide enough capacity at the last L3 device (probably) to get all customers fed, but... at least it's not all aggregated with cat videos from vimeo? From cidr-report at potaroo.net Fri Feb 8 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Feb 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201302082200.r18M00Yw034663@wattle.apnic.net> This report has been generated at Fri Feb 8 21:13:12 2013 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 01-02-13 443327 254928 02-02-13 443678 255044 03-02-13 443774 254726 04-02-13 443962 255027 05-02-13 444400 255194 06-02-13 444683 255265 07-02-13 444729 253993 08-02-13 444908 254207 AS Summary 43368 Number of ASes in routing system 18002 Number of ASes announcing only one prefix 3071 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 116912864 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 08Feb13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 445259 254196 191063 42.9% All ASes AS6389 3071 109 2962 96.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2356 88 2268 96.3% NET Servicos de Comunicao S.A. AS17974 2482 465 2017 81.3% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2939 941 1998 68.0% KIXS-AS-KR Korea Telecom AS22773 1967 132 1835 93.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2081 425 1656 79.6% COVAD - Covad Communications Co. AS10620 2312 681 1631 70.5% Telmex Colombia S.A. AS7303 1679 407 1272 75.8% Telecom Argentina S.A. AS4323 1604 400 1204 75.1% TWTC - tw telecom holdings, inc. AS4755 1684 583 1101 65.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1114 83 1031 92.5% RELCOM-AS OOO "NPO Relcom" AS7029 2264 1250 1014 44.8% WINDSTREAM - Windstream Communications Inc AS7552 1161 186 975 84.0% VIETEL-AS-AP Vietel Corporation AS36998 1286 381 905 70.4% SDN-MOBITEL AS18101 1009 170 839 83.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7545 1832 1021 811 44.3% TPG-INTERNET-AP TPG Internet Pty Ltd AS1785 1953 1164 789 40.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS8151 1520 732 788 51.8% Uninet S.A. de C.V. AS4808 1109 352 757 68.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS18881 758 26 732 96.6% Global Village Telecom AS14754 941 210 731 77.7% Telgua AS13977 838 123 715 85.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS9808 741 54 687 92.7% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS855 713 52 661 92.7% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS22561 1066 444 622 58.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS17676 718 97 621 86.5% GIGAINFRA Softbank BB Corp. AS24560 1044 429 615 58.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3356 1103 499 604 54.8% LEVEL3 Level 3 Communications AS3549 1047 448 599 57.2% GBLX Global Crossing Ltd. AS19262 997 404 593 59.5% VZGNI-TRANSIT - Verizon Online LLC Total 45389 12356 33033 72.8% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 31.210.16.0/22 AS15657 SPEEDBONE-AS Speedbone Internet & Connectivity GmbH 41.138.95.0/24 AS36930 Zantel-AS 41.222.80.0/21 AS37110 moztel-as 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.5.152.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC. 103.11.148.0/24 AS58452 103.11.149.0/24 AS58452 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 185.18.112.0/22 AS30729 TRANSFERTTK-AS Transfer ltd. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.252.0/22 AS2386 INS-AS - AT&T Data Communications Services 208.89.253.0/24 AS2386 INS-AS - AT&T Data Communications Services 208.89.254.0/24 AS2386 INS-AS - AT&T Data Communications Services 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 8 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Feb 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201302082200.r18M01ha034671@wattle.apnic.net> BGP Update Report Interval: 31-Jan-13 -to- 07-Feb-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9498 122743 4.0% 114.9 -- BBIL-AP BHARTI Airtel Ltd. 2 - AS24560 92362 3.0% 88.4 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 3 - AS8402 51328 1.7% 23.5 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS18207 49601 1.6% 90.8 -- YOU-INDIA-AP YOU Broadband & Cable India Ltd. 5 - AS3909 43487 1.4% 1317.8 -- QWEST-AS-3908 - Qwest Communications Company, LLC 6 - AS9829 36729 1.2% 25.6 -- BSNL-NIB National Internet Backbone 7 - AS29256 33329 1.1% 505.0 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 8 - AS18002 28395 0.9% 134.6 -- WORLDPHONE-IN AS Number for Interdomain Routing 9 - AS45609 27850 0.9% 107.5 -- BHARTI-MOBILITY-AS-AP Bharti Airtel Ltd. AS for GPRS Service 10 - AS45514 22498 0.7% 73.5 -- TELEMEDIA-SMB-AS-AP Bharti Airtel Ltd., TELEMEDIA Services, for SMB customers 11 - AS2118 21085 0.7% 18.9 -- RELCOM-AS OOO "NPO Relcom" 12 - AS28573 19649 0.6% 8.2 -- NET Servicos de Comunicao S.A. 13 - AS45528 18907 0.6% 30.2 -- TDN Tikona Digital Networks Pvt Ltd. 14 - AS45271 17141 0.6% 55.5 -- ICLNET-AS-AP 5th Floor, Windsor Building, Off: CST Road 15 - AS7633 16734 0.5% 80.1 -- SOFTNET-AS-AP Software Technology Parks of India - Bangalore 16 - AS2708 16719 0.5% 119.4 -- Universidad de Guanajuato 17 - AS7552 16660 0.5% 14.3 -- VIETEL-AS-AP Vietel Corporation 18 - AS17488 15577 0.5% 23.2 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 19 - AS7029 14007 0.5% 5.4 -- WINDSTREAM - Windstream Communications Inc 20 - AS17974 13323 0.4% 5.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32847 5458 0.2% 5458.0 -- LMGINC-ORL - LMG, Inc 2 - AS6174 5795 0.2% 2897.5 -- SPRINTLINK8 - Sprint 3 - AS14680 6061 0.2% 2020.3 -- REALE-6 - Auction.com 4 - AS24773 1716 0.1% 1716.0 -- ASN-HH-LB HSH Nordbank AG 5 - AS57918 1678 0.1% 1678.0 -- ACOD-AS ACOD CJSC 6 - AS3909 43487 1.4% 1317.8 -- QWEST-AS-3908 - Qwest Communications Company, LLC 7 - AS59620 1263 0.0% 1263.0 -- GESBG Global Electronic Solutions LTD 8 - AS40946 5758 0.2% 1151.6 -- PROCON - Sat Track 9 - AS4 1993 0.1% 51.0 -- COMUNICALO DE MEXICO S.A. DE C.V 10 - AS17293 3489 0.1% 872.2 -- VTXC - VTX Communications 11 - AS22140 8332 0.3% 833.2 -- T-MOBILE-AS22140 - T-Mobile USA, Inc. 12 - AS57201 587 0.0% 587.0 -- EDF-AS Estonian Defence Forces 13 - AS40931 1688 0.1% 562.7 -- MOBITV - MobiTV, Inc 14 - AS2 529 0.0% 649.0 -- DHRUBO-AS-AP Dhrubo 15 - AS29256 33329 1.1% 505.0 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 16 - AS2033 3981 0.1% 497.6 -- PANIX - Panix Network Information Center 17 - AS51341 3104 0.1% 388.0 -- GCS-AS Gigacom Systems Ltd. 18 - AS6507 1129 0.0% 376.3 -- RIOT-NA1 - Riot Games, Inc 19 - AS33976 744 0.0% 372.0 -- AFTONBLADET-SE aftonbladet.se 20 - AS19406 3998 0.1% 363.5 -- TWRS-MA - Towerstream I, Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 151.118.254.0/24 14494 0.5% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 2 - 151.118.255.0/24 14494 0.5% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - 151.118.18.0/24 14446 0.5% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - 184.159.130.0/23 10514 0.3% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 5 - 208.14.186.0/24 8312 0.3% AS22140 -- T-MOBILE-AS22140 - T-Mobile USA, Inc. 6 - 202.41.70.0/24 7848 0.2% AS2697 -- ERX-ERNET-AS Education and Research Network 7 - 192.58.232.0/24 7223 0.2% AS6629 -- NOAA-AS - NOAA 8 - 208.92.131.0/24 5752 0.2% AS40946 -- PROCON - Sat Track 9 - 173.227.147.0/24 5458 0.2% AS32847 -- LMGINC-ORL - LMG, Inc 10 - 196.1.167.0/24 4993 0.1% AS11139 -- CWRIN CW BARBADOS 11 - 12.139.133.0/24 4951 0.1% AS14680 -- REALE-6 - Auction.com 12 - 194.63.9.0/24 4831 0.1% AS1273 -- CW Cable and Wireless Worldwide plc 13 - 58.184.229.0/24 4614 0.1% AS9950 -- PUBNETPLUS2-AS-KR DACOM 14 - 209.48.168.0/24 3972 0.1% AS2033 -- PANIX - Panix Network Information Center 15 - 69.38.178.0/24 3969 0.1% AS19406 -- TWRS-MA - Towerstream I, Inc. 16 - 5.0.32.0/19 3504 0.1% AS29386 -- EXT-PDN-STE-AS Syrian Telecommunications Establishment 17 - 5.0.128.0/19 3032 0.1% AS29256 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 18 - 5.0.160.0/19 3032 0.1% AS29256 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 19 - 5.0.192.0/19 3032 0.1% AS29256 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 20 - 31.9.96.0/19 3030 0.1% AS29256 -- INT-PDN-STE-AS Syrian Telecommunications Establishment Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From johnl at iecc.com Fri Feb 8 22:32:21 2013 From: johnl at iecc.com (John Levine) Date: 8 Feb 2013 22:32:21 -0000 Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: Message-ID: <20130208223221.19138.qmail@joyce.lan> >I wouldn't use them unless you have a specific reason to. That seems to be the consensus. Lucky I didn't pay very much. Any ATAs that people acually like? -- Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From aplato at coldwater.org Fri Feb 8 22:44:23 2013 From: aplato at coldwater.org (Plato, Art) Date: Fri, 8 Feb 2013 17:44:23 -0500 (EST) Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: <20130208223221.19138.qmail@joyce.lan> References: <20130208223221.19138.qmail@joyce.lan> Message-ID: <96D24EB9-905E-4AED-8618-DA9570FB6D45@coldwater.org> Arris. One failure of 500 deployed so far and call jitter issues disappeared once we switched to the Arris Emta's On Feb 8, 2013, at 5:33 PM, "John Levine" wrote: >> I wouldn't use them unless you have a specific reason to. > > That seems to be the consensus. Lucky I didn't pay very much. > > Any ATAs that people acually like? > > -- > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. http://jl.ly > From aplato at coldwater.org Fri Feb 8 22:45:28 2013 From: aplato at coldwater.org (Plato, Art) Date: Fri, 8 Feb 2013 17:45:28 -0500 (EST) Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: <20130208223221.19138.qmail@joyce.lan> References: <20130208223221.19138.qmail@joyce.lan> Message-ID: <58B56D51-CD5E-4CC4-91AC-ED952492A05E@coldwater.org> Guess I should clarify that these are Cable Emta's. Not stand alone. On Feb 8, 2013, at 5:33 PM, "John Levine" wrote: >> I wouldn't use them unless you have a specific reason to. > > That seems to be the consensus. Lucky I didn't pay very much. > > Any ATAs that people acually like? > > -- > Regards, > John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. http://jl.ly > From mohta at necom830.hpcl.titech.ac.jp Fri Feb 8 23:58:41 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 09 Feb 2013 08:58:41 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <5113EB2E.7080504@necom830.hpcl.titech.ac.jp> <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> Message-ID: <51159131.2040403@necom830.hpcl.titech.ac.jp> Jason Baugher wrote: > In a greenfield build, cost difference for plant between PON and active > will be negligible for field-based splitters, non-existent for CO-based > splitters. If you choose to have CO-based splitters, you need to have MDF for L1 unbundling, and 1:8 (or 1:4, 1:32 or whatever) optical splitter module for PON, combination of which requires more CO space and money than SS (single star) optical equipment (just MDF). > On the CO-side electronics, however... I think it's safe to say that you > can do GPON under $100/port. Never ignore space and cost of optical splitters required only for PON. Note that the splitters cost even if they are located in field. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Sat Feb 9 00:43:47 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 09 Feb 2013 09:43:47 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: <5114D927.10908@vaxination.ca> References: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> <5114B90F.50002@necom830.hpcl.titech.ac.jp> <5114D927.10908@vaxination.ca> Message-ID: <51159BC3.4050709@necom830.hpcl.titech.ac.jp> Jean-Francois Mezei wrote: >> The problem of PON is that, to efficiently share a fiber and >> a splitter, they must be shared by many subscribers, which >> means drop cables are longer than those of SS. > > Pardon my ignorance here, but could you explain why the cables would be > physically different in the last mile ? Drop cables are not for last miles, but for last yards. Let's assume 4:1 concentration with PON. Let's also assume that 1150 subscribers are evenly distributed over 51km trunk cable, which means distance between adjacent subscribers is 44.3m. > Why would this be different in a PON vs Point to Point system ? If you use SS, you need a closure every 44.3m drop cable length from which will be 5 or 10m. -C-------C-------C-------C-------C-------C-------C- trunk cable | | | | | | | drop cable S S S S S S S S: Subscriber C: Closure OTOH, if you use PON and have 4 drop cables from an in-field splitter, two drop cables needs extra 22.2 m and other two needs extra 66.5 m. ------------C-------------------------------C----- trunk cable || || || || ^ +---------+| |+---------+ +---------+| |+--- | | | | | | | | | drop cable | +--+ +--+ | | +--+ +--+ | | | | | | | | v S S S S S S S S: Subscriber C: Closure In this case, total extra drop cable length for PON is 51km, identical to the trunk cable length. It all depends how (initial and subsequent) subscribers are distributed, but tendency is same. As for cost for closures, while SS needs four times more closures than PON, a closure for SS is simpler and cheaper than that for PON to purchase, install and maintain. > Wher I see a difference is between the neighbourhood aggregation point > and the CO where the PON system will have just 1 strand for 32 homes > whereas point to point will have 1 strand per home passed. But the > lengths should be the same, shouldn't they ? Never ignore topology at the last yards. Masataka Ohta From rs at seastrom.com Sat Feb 9 06:50:03 2013 From: rs at seastrom.com (Robert E. Seastrom) Date: Sat, 09 Feb 2013 01:50:03 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <51159BC3.4050709@necom830.hpcl.titech.ac.jp> (Masataka Ohta's message of "Sat, 09 Feb 2013 09:43:47 +0900") References: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> <5114B90F.50002@necom830.hpcl.titech.ac.jp> <5114D927.10908@vaxination.ca> <51159BC3.4050709@necom830.hpcl.titech.ac.jp> Message-ID: <86r4kq7zhg.fsf@seastrom.com> Masataka Ohta writes: > Let's assume 4:1 concentration with PON. Why on earth would we assume that when industry standard is 16 or 32? 16 is a safe number. -r From mohta at necom830.hpcl.titech.ac.jp Sat Feb 9 11:41:48 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 09 Feb 2013 20:41:48 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: <86r4kq7zhg.fsf@seastrom.com> References: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> <5114B90F.50002@necom830.hpcl.titech.ac.jp> <5114D927.10908@vaxination.ca> <51159BC3.4050709@necom830.hpcl.titech.ac.jp> <86r4kq7zhg.fsf@seastrom.com> Message-ID: <511635FC.1030402@necom830.hpcl.titech.ac.jp> Robert E. Seastrom wrote: >> Let's assume 4:1 concentration with PON. > > Why on earth would we assume that when industry standard is 16 or 32? That is because additional 4:1 concentration is usually at CO, which does not contribute to reduce the number of fibers in a trunk cable. > 16 is a safe number. Do you mean a splitter in field should be shared by 16 subscribers? Then, with the otherwise same assumptions of my previous mail, total extra drop cable length for PON will be 204km, four times more than the trunk cable length. Thus, it is so obvious that SS is better than PON. OTOH, if concentration is 2:1 or less, it is, again, obvious that SS is better than PON, because of extra complexity of PON. So, 4:1 is the safe number to obfuscate lack of merit of PON. If you can read Japanese or FTTH is serious business of you worth hiring a translator of your own, you can find average number of subscribers sharing a splitter in field is 3.68, a little less than 4, from: http://itpro.nikkeibp.co.jp/article/COLUMN/20080619/308665/ Masataka Ohta From fredan-nanog at fredan.se Sat Feb 9 12:45:42 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Sat, 09 Feb 2013 13:45:42 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <3940444.187.1360354551648.JavaMail.art@DQT6ZQ1> References: <3940444.187.1360354551648.JavaMail.art@DQT6ZQ1> Message-ID: <511644F6.6020900@fredan.se> > How about buy the movies in question, convert them to MP4, install a media server on a local box and configure Xbox, tablet, smart-phone, whatever to access the media server? No. Streaming from services, like Netflix, HBO, etc..., is what's coming. We need to prepare for the bandwidth they are going to be using. > Oh, it also affords my wife and I the luxury of having our entire movie collection available for on demand viewing. No searching through cases or disc binders. Just a thought. You do have one point with this, though. Being able to watch movies when the Internet connection is down. -- //fredan From rs at seastrom.com Sat Feb 9 13:35:40 2013 From: rs at seastrom.com (Robert E. Seastrom) Date: Sat, 09 Feb 2013 08:35:40 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <511635FC.1030402@necom830.hpcl.titech.ac.jp> (Masataka Ohta's message of "Sat, 09 Feb 2013 20:41:48 +0900") References: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> <5114B90F.50002@necom830.hpcl.titech.ac.jp> <5114D927.10908@vaxination.ca> <51159BC3.4050709@necom830.hpcl.titech.ac.jp> <86r4kq7zhg.fsf@seastrom.com> <511635FC.1030402@necom830.hpcl.titech.ac.jp> Message-ID: <86obft7gpf.fsf@seastrom.com> Masataka Ohta writes: > Robert E. Seastrom wrote: > >>> Let's assume 4:1 concentration with PON. >> >> Why on earth would we assume that when industry standard is 16 or 32? > > That is because additional 4:1 concentration is usually at CO, > which does not contribute to reduce the number of fibers in a > trunk cable. > >> 16 is a safe number. > > Do you mean a splitter in field should be shared by 16 > subscribers? > > Then, with the otherwise same assumptions of my previous mail, > total extra drop cable length for PON will be 204km, four times > more than the trunk cable length. > > Thus, it is so obvious that SS is better than PON. You're confusing fiber architecture with what gets laid on top of it. Where the splitters go is entirely irrelevant. Rule of thumb in the US is that 80% of the costs of a fiber build are in engineering, planning, RoW acquisition, lawyers, etc. Of the remaining 20%, more of it is labor than materials. Price per fiber strand in the bundle is noise in the larger equation. You have to pay for splitters in the PON architecture regardless of where you put them, of course, so just bake that into the port cost side of per-customer-served. > OTOH, if concentration is 2:1 or less, it is, again, obvious that > SS is better than PON, because of extra complexity of PON. Again, home run central splitter vs. distributed splitter architecture has nothing to do with PON being better or worse than a technology that forces single strand all the way to the endpoint. > So, 4:1 is the safe number to obfuscate lack of merit of PON. > > If you can read Japanese or FTTH is serious business of you > worth hiring a translator of your own, you can find average > number of subscribers sharing a splitter in field is 3.68, > a little less than 4, from: > > http://itpro.nikkeibp.co.jp/article/COLUMN/20080619/308665/ Having actually been involved in building a business plan surrounding this, I don't need to read Japanese to be able to tell you that the outside plant engineering was clearly assigned to the madogiwazoku if they're only getting a 4:1 split on average. -r From fredan-nanog at fredan.se Sat Feb 9 13:47:35 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Sat, 09 Feb 2013 14:47:35 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <31245655.5493.1360354278086.JavaMail.root@benjamin.baylink.com> References: <31245655.5493.1360354278086.JavaMail.root@benjamin.baylink.com> Message-ID: <51165377.10003@fredan.se> > But it has become unclear what your fundamental premise and argument are, > by this point in the game. See the subject of this thread? > Is it: "it is bad that content providers choose a business and technical > model wherein local in-home transparent caching proxies won't work?" No, it's not. -- //fredan From jason at thebaughers.com Sat Feb 9 14:05:44 2013 From: jason at thebaughers.com (Jason Baugher) Date: Sat, 9 Feb 2013 08:05:44 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: <511635FC.1030402@necom830.hpcl.titech.ac.jp> References: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> <5114B90F.50002@necom830.hpcl.titech.ac.jp> <5114D927.10908@vaxination.ca> <51159BC3.4050709@necom830.hpcl.titech.ac.jp> <86r4kq7zhg.fsf@seastrom.com> <511635FC.1030402@necom830.hpcl.titech.ac.jp> Message-ID: You are seriously saying I should hire a translator to tell me what your document says? That is hilarious. How about you point out a reference written in a language common to North America, since this IS NANOG. Anyone here doing or know someone doing 4-1 or 8-1 splits, in a typical American town? I believe most people were talking about areas <50000 population. Our main cost is labor. Fiber, fdh, splitters, etc... are marginal. On Feb 9, 2013 5:42 AM, "Masataka Ohta" wrote: > Robert E. Seastrom wrote: > > >> Let's assume 4:1 concentration with PON. > > > > Why on earth would we assume that when industry standard is 16 or 32? > > That is because additional 4:1 concentration is usually at CO, > which does not contribute to reduce the number of fibers in a > trunk cable. > > > 16 is a safe number. > > Do you mean a splitter in field should be shared by 16 > subscribers? > > Then, with the otherwise same assumptions of my previous mail, > total extra drop cable length for PON will be 204km, four times > more than the trunk cable length. > > Thus, it is so obvious that SS is better than PON. > > OTOH, if concentration is 2:1 or less, it is, again, obvious that > SS is better than PON, because of extra complexity of PON. > > So, 4:1 is the safe number to obfuscate lack of merit of PON. > > If you can read Japanese or FTTH is serious business of you > worth hiring a translator of your own, you can find average > number of subscribers sharing a splitter in field is 3.68, > a little less than 4, from: > > http://itpro.nikkeibp.co.jp/article/COLUMN/20080619/308665/ > > Masataka Ohta > > From jra at baylink.com Sat Feb 9 15:22:19 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 9 Feb 2013 10:22:19 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: <511635FC.1030402@necom830.hpcl.titech.ac.jp> Message-ID: <24263853.5563.1360423339258.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Masataka Ohta" > Robert E. Seastrom wrote: > > >> Let's assume 4:1 concentration with PON. > > > > Why on earth would we assume that when industry standard is 16 or > > 32? > > That is because additional 4:1 concentration is usually at CO, > which does not contribute to reduce the number of fibers in a > trunk cable. Not to my understanding. > > 16 is a safe number. > > Do you mean a splitter in field should be shared by 16 > subscribers? He means that, yes. > Then, with the otherwise same assumptions of my previous mail, > total extra drop cable length for PON will be 204km, four times > more than the trunk cable length. > > Thus, it is so obvious that SS is better than PON. Nope. We're all looking at you funny because your math seems *exactly* backwards. Let me plot it for you. Assume 100m from the access mux (OLT) to the ONT: 2M from the OLT to the CO patch 73M from the CO patch to the neighborhood pedestal 25M from the pedestal to each house (assume a spherical neighborhood). So, if we put the splitter in the pedestal, splitting 16 houses, we get 2 + 73 + (25 * 16) = 475 meters of total glass, plus 1 16:1 splitter. If we put the splitter in the CO (which I believe is what you mean by "SS"; we call it "home-run" fiber), you get: 2 + ((73 + 25) * 16) = 1570 meters of total glass, optionally plus 1 16:1 splitter, if you're still doing PON, instead of AE. So, over three times as much fiber if you're not putting the splitter in the field, which is... the opposite of what you assert? Or am I dense? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From rs at seastrom.com Sat Feb 9 15:25:42 2013 From: rs at seastrom.com (Robert E. Seastrom) Date: Sat, 09 Feb 2013 10:25:42 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: (Jason Baugher's message of "Sat, 9 Feb 2013 08:05:44 -0600") References: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> <5114B90F.50002@necom830.hpcl.titech.ac.jp> <5114D927.10908@vaxination.ca> <51159BC3.4050709@necom830.hpcl.titech.ac.jp> <86r4kq7zhg.fsf@seastrom.com> <511635FC.1030402@necom830.hpcl.titech.ac.jp> Message-ID: <86obft5x1l.fsf@seastrom.com> Jason Baugher writes: > Our main cost is labor. Fiber, fdh, splitters, etc... are marginal. dingdingdingding WE HAVE A WINNER. :-) -r From jra at baylink.com Sat Feb 9 19:02:35 2013 From: jra at baylink.com (Jay Ashworth) Date: Sat, 9 Feb 2013 14:02:35 -0500 (EST) Subject: Fiber project/IPTV multicast Message-ID: <25231684.5607.1360436555185.JavaMail.root@benjamin.baylink.com> Do any of the people who've worked with some of the IPTV delivery services mentioned here know if their live TV services can be handled via Multicast? Off-list replies are fine; will summarize if anyone else cares. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jfmezei_nanog at vaxination.ca Sat Feb 9 19:18:21 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 09 Feb 2013 14:18:21 -0500 Subject: Fiber project/IPTV multicast In-Reply-To: <25231684.5607.1360436555185.JavaMail.root@benjamin.baylink.com> References: <25231684.5607.1360436555185.JavaMail.root@benjamin.baylink.com> Message-ID: <5116A0FD.3020908@vaxination.ca> On 13-02-09 14:02, Jay Ashworth wrote: > Do any of the people who've worked with some of the IPTV delivery services > mentioned here know if their live TV services can be handled via Multicast? I know that Bell Canada uses the Microsoft MediaRoom IPTV servers and they support multicast. The delivery network is somewhat separate from the data network. At the DSLAM, they travel as separate VLANs to the customer. Bell Canada hasn't provided technical answers to exactly where IPTV and data start to share transmission facilities (from a tariff point of view, they do not wish to admit that both share trunk lines to COs). You may also wish to look at the Australian NBN. http://www.nbnco.com.au/multicast Somewhere on their web site, they have the specs of the L2 service with regards to voice and data. Recently, they announced a trial for multicast IPTV retailer over the wholesale NBN. From cjp at 0x1.net Sat Feb 9 19:31:00 2013 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Sat, 9 Feb 2013 14:31:00 -0500 Subject: Multicast Ethernet frames not bridging between wired and wireless, Netgear CPE Message-ID: I've a Netgear 7550 B90 provided by Frontier. (Yes, it's my only choice other than VSAT. Rural US. Yes, I am already looking into getting my own CPE, but humor me.) Since Frontier doesn't support IPv6, I've linux box on the LAN building an AYIYA tunnel, and doing the usual router thing on the wired Ethernet. Everything on the wired side works splendid. Wireless clients didn't seem to want to play. Further digging indicates that RA and NS don't cross the bridge from wired to wireless. Manually assigning IPv6 address and nailing NDP entries allows ICMPv6 echo request to work. Has anyone seen this class of device drop multicast between the wireless radio and the wired ethernet switch? Or am I brain dead this morning and missing something obvious? Heck, I even tried disabling WPA2 thinking it was some wonky encryption thing. Thanks, -cjp From wbailey at satelliteintelligencegroup.com Sat Feb 9 20:19:41 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 9 Feb 2013 20:19:41 +0000 Subject: Fiber project/IPTV multicast In-Reply-To: <5116A0FD.3020908@vaxination.ca> References: <25231684.5607.1360436555185.JavaMail.root@benjamin.baylink.com>, <5116A0FD.3020908@vaxination.ca> Message-ID: Nearly all IPTV is multicast via group joins. That is how they limit access to content. It is all technically live (save for vod) as it is down linked from a source and fed into the head end. A lot of cable providers do multi cast over coax now as well. Check out cable labs if you haven't, they have some neat stuff they discuss. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Jean-Francois Mezei Date: 02/09/2013 11:19 AM (GMT-08:00) To: nanog at nanog.org Subject: Re: Fiber project/IPTV multicast On 13-02-09 14:02, Jay Ashworth wrote: > Do any of the people who've worked with some of the IPTV delivery services > mentioned here know if their live TV services can be handled via Multicast? I know that Bell Canada uses the Microsoft MediaRoom IPTV servers and they support multicast. The delivery network is somewhat separate from the data network. At the DSLAM, they travel as separate VLANs to the customer. Bell Canada hasn't provided technical answers to exactly where IPTV and data start to share transmission facilities (from a tariff point of view, they do not wish to admit that both share trunk lines to COs). You may also wish to look at the Australian NBN. http://www.nbnco.com.au/multicast Somewhere on their web site, they have the specs of the L2 service with regards to voice and data. Recently, they announced a trial for multicast IPTV retailer over the wholesale NBN. From khelms at zcorum.com Sat Feb 9 20:55:15 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 9 Feb 2013 15:55:15 -0500 Subject: Fiber project/IPTV multicast In-Reply-To: <25231684.5607.1360436555185.JavaMail.root@benjamin.baylink.com> References: <25231684.5607.1360436555185.JavaMail.root@benjamin.baylink.com> Message-ID: However you get your video feed you can encode it as ip and feed it out to your shelves as IGMP streams. This is the "normal" way to handle linear programming. On Feb 9, 2013 2:03 PM, "Jay Ashworth" wrote: > Do any of the people who've worked with some of the IPTV delivery services > mentioned here know if their live TV services can be handled via Multicast? > > Off-list replies are fine; will summarize if anyone else cares. > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > From khelms at zcorum.com Sat Feb 9 21:31:13 2013 From: khelms at zcorum.com (Scott Helms) Date: Sat, 9 Feb 2013 16:31:13 -0500 Subject: Fiber project/IPTV multicast In-Reply-To: References: <25231684.5607.1360436555185.JavaMail.root@benjamin.baylink.com> Message-ID: More accurately you'll do MPEG 4 streams controlled by IGMP. On Feb 9, 2013 3:55 PM, "Scott Helms" wrote: > However you get your video feed you can encode it as ip and feed it out to > your shelves as IGMP streams. This is the "normal" way to handle linear > programming. > On Feb 9, 2013 2:03 PM, "Jay Ashworth" wrote: > >> Do any of the people who've worked with some of the IPTV delivery services >> mentioned here know if their live TV services can be handled via >> Multicast? >> >> Off-list replies are fine; will summarize if anyone else cares. >> >> Cheers, >> -- jra >> >> -- >> Jay R. Ashworth Baylink >> jra at baylink.com >> Designer The Things I Think RFC >> 2100 >> Ashworth & Associates http://baylink.pitas.com 2000 Land >> Rover DII >> St Petersburg FL USA #natog +1 727 >> 647 1274 >> >> From benny+usenet at amorsen.dk Sat Feb 9 21:33:59 2013 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Sat, 09 Feb 2013 22:33:59 +0100 Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: <20130208223221.19138.qmail@joyce.lan> (John Levine's message of "8 Feb 2013 22:32:21 -0000") References: <20130208223221.19138.qmail@joyce.lan> Message-ID: "John Levine" writes: > Any ATAs that people acually like? Strangely enough, "Cisco" SPA-112. Formerly known as Sipura, then Linksys. I do not know if they move to Belkin as part of the Linksys sale. They are not perfect, but they are pretty good. /Benny From jackson.tim at gmail.com Sat Feb 9 21:58:48 2013 From: jackson.tim at gmail.com (Tim Jackson) Date: Sat, 9 Feb 2013 15:58:48 -0600 Subject: Fiber project/IPTV multicast In-Reply-To: <25231684.5607.1360436555185.JavaMail.root@benjamin.baylink.com> References: <25231684.5607.1360436555185.JavaMail.root@benjamin.baylink.com> Message-ID: Yes. Most live IPTV is delivered across multicast*. There are a few gotchas. MMR uses a unicast fill for instant channel change (configurable bandwidth ammounts, etc) on top of Multicast. Some other middleware may have similar methods to accomplish this. Usually at the DSLAM you'll see "hax" to forward IGMP requests and multicast ingress to/from a specific VLAN. Most EFM based DSLAMs will segregate this all the way down to the CPE, and let the CPE handle differentiating the joins on the particular VLANs. Sometimes it's handled inside the DSLAM, but usually it's all configurable. Handling live TV unicast is definitely possible but brings up another set of challenges across the SP network towards the DSLAM/Agg point. Mainly reproduction of the same content * subscriber count, so your bandwidth towards a given DSLAM/Agg point grows with every subscriber. Low penetration count of IPTV, this can be less bandwidth, as IPTV penetration grows this could be several times the multicast bandwidth. Usually most channel lineups are 1gbps->2.5gbps of multicast bandwidth, depending on channel bitrates, amount of content, etc, etc.. MMR == Microsoft Mediaroom -- Tim On Sat, Feb 9, 2013 at 1:02 PM, Jay Ashworth wrote: > Do any of the people who've worked with some of the IPTV delivery services > mentioned here know if their live TV services can be handled via Multicast? > > Off-list replies are fine; will summarize if anyone else cares. > > Cheers, > -- jra > > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > From j at 2600hz.com Sat Feb 9 22:18:40 2013 From: j at 2600hz.com (Joshua Goldbard) Date: Sat, 9 Feb 2013 22:18:40 +0000 Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: References: <20130208223221.19138.qmail@joyce.lan>, Message-ID: <1B00C5BD-3150-4CEA-97D4-4BAA65AF6424@2600hz.com> We've used the HT502 ata's on a number of deployments, but voiceops has a thread going now about a buffer overflow issue that leaks credentials. We're evaluating the issue now to see if any of our units are on the old firmware and, if so, how best to handle it. That being said they're great little ata's. No issues. Cheers, Joshua Sent from my iPhone On Feb 9, 2013, at 1:35 PM, "Benny Amorsen" wrote: > "John Levine" writes: > >> Any ATAs that people acually like? > > Strangely enough, "Cisco" SPA-112. Formerly known as Sipura, then > Linksys. I do not know if they move to Belkin as part of the Linksys > sale. > > They are not perfect, but they are pretty good. > > > /Benny > > From frnkblk at iname.com Sat Feb 9 22:18:53 2013 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 9 Feb 2013 16:18:53 -0600 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: References: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> <020901ce01d3$0da88c00$28f9a400$@iname.com> <004301ce0292$2b85c1b0$82914510$@iname.com> Message-ID: <00a701ce0713$720a1700$561e4500$@iname.com> I know of two state-wide head ends and one of them has the agreements in place for all their channels. So a new telco coming on needs only to some documents, to be sure, but there's not much (if anything) they need to negotiate directly with a content owner. Frank From: Scott Helms [mailto:khelms at zcorum.com] Sent: Monday, February 04, 2013 2:50 PM To: Frank Bulk Cc: Brandon Ross; NANOG Subject: Re: Will wholesale-only muni actually bring the boys to your yard? Frank, One thing to keep in mind is that I don't believe its possible to get a contract with the bulk of the content owners in a wholesale scenario. This would be a different kind of situation than I've seen attempted in the past but in general the content guys get very picky about how video delivery is done. I'd certainly not claim to be authoritative on this, but I've never seen it done and I have seen the content guys strike down shared head end systems in almost all cases. Also, apologies for the rash of emails since this is the first time I've been able to get back to this thread. On Sun, Feb 3, 2013 at 11:43 PM, Frank Bulk > wrote: Brandon: My apologies, I didn't mean to suggest that providers would be unable to provide video services across the muni fiber infrastructure. I was just pointing out that many customers want a triple play, so that should be a factor that Jay considers when considering a GPON-only or ActiveE design, as an RF-overlay on a GPON network is likely more profitable than an IP TV service on top of GPON or ActiveE. And Jay wants to attract multiple providers, so he wants a fiber design that's as attractive to as many parties as reasonably possible. Frank -----Original Message----- From: Brandon Ross [mailto:bross at pobox.com ] Sent: Sunday, February 03, 2013 9:56 AM To: Frank Bulk Cc: NANOG; Jay Ashworth Subject: RE: Will wholesale-only muni actually bring the boys to your yard? On Sat, 2 Feb 2013, Frank Bulk wrote: > Yes, but IP TV is not profitable on stand-alone basis -- it's just a > necessary part of the triple play. A lot of the discussion has been about > Internet and network design, but not much about the other two "plays". I don't know if that's true or not, but so what? The concern was that providers would be unable to provide television services across this muni fiber infrastructure and that customers would demand triple play. I showed that they absolutely can provide this service by doing it across IP. If a provider can't make money at it, then they don't have to provide it. This whole exercise, I thought, was about removing the tyranny of the monopoly of the last mine so that these other innovations could take place in an open market. And as far as the "other" triple play, it's even more well established that delivery of voice over IP can be done economically. Or do you need me to send you URLs of companies that do it to prove it? > -----Original Message----- > From: Brandon Ross [mailto:bross at pobox.com ] > Sent: Saturday, February 02, 2013 3:53 PM > To: Jay Ashworth > Cc: NANOG > Subject: Re: Will wholesale-only muni actually bring the boys to your yard? > > On Sat, 2 Feb 2013, Jay Ashworth wrote: > >>> Perhaps I live in a different world, but just about all of the small to >>> midsize service providers I work with offer triple play today, and nearly >>> all of them are migrating their triple play services to IP. >> >> Really. Citations? I'd love to see it play that way, myself. > > Okay: > > South Central Rural Telephone > Glasgow, KY > http://www.scrtc.com/ > Left side of page, "Digital TV service". See this news article: > > http://www.wcluradio.com/index.php?option=com_content &view=article&id=15567: > capacity-crowd-hears-good-report-at-scrtc-annuan-mee > > "He also reported that SCRTC is continuing to upgrade our services, > converting customers to the new IPTV service and trying to get as much > fiber optic cable built as possible." > > Camellia Communications > Greenville, AL > http://camelliacom.com/services/ctv-dvr.html > Note the models of set-top boxes they are using are IP based > > Griswold Cooperative Telephone > Griswold, IA > http://www.griswoldtelco.com/griswold-coop-iptv-video > > Farmer's Mutual Coopeative Telephone > Moulton, IA > http://farmersmutualcoop.com/ > > Citizens > Floyd, VA > http://www.citizens.coop/ > > > How about a Canadian example you say? > > CoopTel > Valcourt, QB > http://www.cooptel.qc.ca/en-residentiel-tele-guidesusager.php > Check out the models of set-top boxes here too. > > Oh, also, have you heard of ATT U-Verse? > > http://www.att.com/gen/press-room?pid=4800 &cdvn=news&newsarticleid=26580 > > "AT&T U-verse TV is the only 100 percent Internet Protocol-based > television (IPTV) service offered by a national service provider" > > So even the likes of AT&T, in this scheme, could buy fiber paths to their > subs and provide TV service. I'm pretty sure AT&T knows how to deliver > voice services over IP as well. > > Do you want more examples? I bet I can come up with 50 small/regional > telecom companies that are providing TV services over IP in North America > if I put my mind to it. > > -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From wbailey at satelliteintelligencegroup.com Sat Feb 9 22:21:03 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 9 Feb 2013 22:21:03 +0000 Subject: Any experience with Grandstream VoIP equipment ? Message-ID: Spa is an excellent ATA. From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Benny Amorsen Date: 02/09/2013 1:35 PM (GMT-08:00) To: John Levine Cc: nanog at nanog.org Subject: Re: Any experience with Grandstream VoIP equipment ? "John Levine" writes: > Any ATAs that people acually like? Strangely enough, "Cisco" SPA-112. Formerly known as Sipura, then Linksys. I do not know if they move to Belkin as part of the Linksys sale. They are not perfect, but they are pretty good. /Benny From johnl at iecc.com Sat Feb 9 22:26:16 2013 From: johnl at iecc.com (John R. Levine) Date: 9 Feb 2013 17:26:16 -0500 Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: References: <20130208223221.19138.qmail@joyce.lan> Message-ID: > Strangely enough, "Cisco" SPA-112. Formerly known as Sipura, then > Linksys. I do not know if they move to Belkin as part of the Linksys > sale. Just got a Sipura SPA-1001. It also has registration problems. Hmmn. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From wbailey at satelliteintelligencegroup.com Sat Feb 9 22:28:55 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sat, 9 Feb 2013 22:28:55 +0000 Subject: Will wholesale-only muni actually bring the boys to your yard? In-Reply-To: <00a701ce0713$720a1700$561e4500$@iname.com> References: <24088354.4606.1359827662481.JavaMail.root@benjamin.baylink.com> <020901ce01d3$0da88c00$28f9a400$@iname.com> <004301ce0292$2b85c1b0$82914510$@iname.com> , <00a701ce0713$720a1700$561e4500$@iname.com> Message-ID: <1vqg7kn5b1fdjnnlckmo22k1.1360448932617@email.android.com> I was a lead engineer on a satellite based aeronautical connectivity platform. We sent live video via multicast over our satellite data stream as multicast. The aircraft performed the join and all seat backs had/have live TV (not a demodulator on the plane like domestic carriers, true multicast video). The amount of pain we went through with encryption required by the content providers was nuts. I don't know how they do it on the ground, but we ended up with a sizable PKI at the end of the day. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Frank Bulk Date: 02/09/2013 2:23 PM (GMT-08:00) To: 'Scott Helms' Cc: NANOG ,Brandon Ross Subject: RE: Will wholesale-only muni actually bring the boys to your yard? I know of two state-wide head ends and one of them has the agreements in place for all their channels. So a new telco coming on needs only to some documents, to be sure, but there's not much (if anything) they need to negotiate directly with a content owner. Frank From: Scott Helms [mailto:khelms at zcorum.com] Sent: Monday, February 04, 2013 2:50 PM To: Frank Bulk Cc: Brandon Ross; NANOG Subject: Re: Will wholesale-only muni actually bring the boys to your yard? Frank, One thing to keep in mind is that I don't believe its possible to get a contract with the bulk of the content owners in a wholesale scenario. This would be a different kind of situation than I've seen attempted in the past but in general the content guys get very picky about how video delivery is done. I'd certainly not claim to be authoritative on this, but I've never seen it done and I have seen the content guys strike down shared head end systems in almost all cases. Also, apologies for the rash of emails since this is the first time I've been able to get back to this thread. On Sun, Feb 3, 2013 at 11:43 PM, Frank Bulk > wrote: Brandon: My apologies, I didn't mean to suggest that providers would be unable to provide video services across the muni fiber infrastructure. I was just pointing out that many customers want a triple play, so that should be a factor that Jay considers when considering a GPON-only or ActiveE design, as an RF-overlay on a GPON network is likely more profitable than an IP TV service on top of GPON or ActiveE. And Jay wants to attract multiple providers, so he wants a fiber design that's as attractive to as many parties as reasonably possible. Frank -----Original Message----- From: Brandon Ross [mailto:bross at pobox.com ] Sent: Sunday, February 03, 2013 9:56 AM To: Frank Bulk Cc: NANOG; Jay Ashworth Subject: RE: Will wholesale-only muni actually bring the boys to your yard? On Sat, 2 Feb 2013, Frank Bulk wrote: > Yes, but IP TV is not profitable on stand-alone basis -- it's just a > necessary part of the triple play. A lot of the discussion has been about > Internet and network design, but not much about the other two "plays". I don't know if that's true or not, but so what? The concern was that providers would be unable to provide television services across this muni fiber infrastructure and that customers would demand triple play. I showed that they absolutely can provide this service by doing it across IP. If a provider can't make money at it, then they don't have to provide it. This whole exercise, I thought, was about removing the tyranny of the monopoly of the last mine so that these other innovations could take place in an open market. And as far as the "other" triple play, it's even more well established that delivery of voice over IP can be done economically. Or do you need me to send you URLs of companies that do it to prove it? > -----Original Message----- > From: Brandon Ross [mailto:bross at pobox.com ] > Sent: Saturday, February 02, 2013 3:53 PM > To: Jay Ashworth > Cc: NANOG > Subject: Re: Will wholesale-only muni actually bring the boys to your yard? > > On Sat, 2 Feb 2013, Jay Ashworth wrote: > >>> Perhaps I live in a different world, but just about all of the small to >>> midsize service providers I work with offer triple play today, and nearly >>> all of them are migrating their triple play services to IP. >> >> Really. Citations? I'd love to see it play that way, myself. > > Okay: > > South Central Rural Telephone > Glasgow, KY > http://www.scrtc.com/ > Left side of page, "Digital TV service". See this news article: > > http://www.wcluradio.com/index.php?option=com_content &view=article&id=15567: > capacity-crowd-hears-good-report-at-scrtc-annuan-mee > > "He also reported that SCRTC is continuing to upgrade our services, > converting customers to the new IPTV service and trying to get as much > fiber optic cable built as possible." > > Camellia Communications > Greenville, AL > http://camelliacom.com/services/ctv-dvr.html > Note the models of set-top boxes they are using are IP based > > Griswold Cooperative Telephone > Griswold, IA > http://www.griswoldtelco.com/griswold-coop-iptv-video > > Farmer's Mutual Coopeative Telephone > Moulton, IA > http://farmersmutualcoop.com/ > > Citizens > Floyd, VA > http://www.citizens.coop/ > > > How about a Canadian example you say? > > CoopTel > Valcourt, QB > http://www.cooptel.qc.ca/en-residentiel-tele-guidesusager.php > Check out the models of set-top boxes here too. > > Oh, also, have you heard of ATT U-Verse? > > http://www.att.com/gen/press-room?pid=4800 &cdvn=news&newsarticleid=26580 > > "AT&T U-verse TV is the only 100 percent Internet Protocol-based > television (IPTV) service offered by a national service provider" > > So even the likes of AT&T, in this scheme, could buy fiber paths to their > subs and provide TV service. I'm pretty sure AT&T knows how to deliver > voice services over IP as well. > > Do you want more examples? I bet I can come up with 50 small/regional > telecom companies that are providing TV services over IP in North America > if I put my mind to it. > > -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From frnkblk at iname.com Sat Feb 9 23:16:24 2013 From: frnkblk at iname.com (Frank Bulk) Date: Sat, 9 Feb 2013 17:16:24 -0600 Subject: Rollup: Small City Municipal Broadband In-Reply-To: References: <9941705.4764.1359923608048.JavaMail.root@benjamin.baylink.com> <004001ce028f$a384c790$ea8e56b0$@iname.com> <51102190.6020103@vaxination.ca> Message-ID: <00b701ce071b$7aedcf80$70c96e80$@iname.com> Unless it's a really small shop, Scott is right that the installers don't touch the EMS. Most don't want to look at it. The good news is that fiber problems are rare, electronics more often. We budget $200/home for a FTTH cutover (install ONT, remove DSL or cable modem, connect CPE to connections off of ONT). Frank -----Original Message----- From: Scott Helms [mailto:khelms at zcorum.com] Sent: Monday, February 04, 2013 3:42 PM To: Jean-Francois Mezei Cc: NANOG Subject: Re: Rollup: Small City Municipal Broadband On Mon, Feb 4, 2013 at 4:01 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > On 13-02-04 15:46, Scott Helms wrote: > > > I certainly agree that fiber plant is in general easier than copper plant > > to maintain. My main concern is that in this case Jay is considering > > allowing not only different vendors but different technologies on the > same > > fiber plant. > > If you are strictly a layer 1 provider, I would assume that you have > setup properly documented procedures and responsabilities in case of > faults. Operationally you're never gonna get here. Installers are guys making $200 bucks an install whether it takes them 30 minutes or 4 hours. Most major operators (all I've worked with) struggle to get their own employees to do troubleshooting and installs correctly. We actually had to write software to ensure that installers are doing basic verification of levels before they leave home. > Perhaps the ISP is responsible for debugging their problems and if they > can show a layer 1 problem, then the city steps in, disconnects the > strand at both ends and uses its own L1 equipment to test the strand. > > If the rules are clear, then ISPs would choose OLT and ONT equipment > which provides remote debugging capabilities since physical visits to > the city owned aggregation point will be difficult. > In really small numbers this is OK. The problem is that there seems to be a thought that a given network will have more than 4-5 dark fiber connections and that they will be a part of the pay back. Getting staff to even log into the web client of the OLT is generally problematic since the guys who do installs aren't normally allowed or even capable of safely using the EMS console. If they can even get the "right" version of Java running to get the JIMC working :( -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From mohta at necom830.hpcl.titech.ac.jp Sun Feb 10 00:03:34 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sun, 10 Feb 2013 09:03:34 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: <86obft7gpf.fsf@seastrom.com> References: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> <5114B90F.50002@necom830.hpcl.titech.ac.jp> <5114D927.10908@vaxination.ca> <51159BC3.4050709@necom830.hpcl.titech.ac.jp> <86r4kq7zhg.fsf@seastrom.com> <511635FC.1030402@necom830.hpcl.titech.ac.jp> <86obft7gpf.fsf@seastrom.com> Message-ID: <5116E3D6.8060407@necom830.hpcl.titech.ac.jp> Robert E. Seastrom wrote: >> Then, with the otherwise same assumptions of my previous mail, >> total extra drop cable length for PON will be 204km, four times >> more than the trunk cable length. >> >> Thus, it is so obvious that SS is better than PON. > > You're confusing fiber architecture with what gets laid on top of it. > Where the splitters go is entirely irrelevant. If you ignore so lengthy drop cables. > Rule of thumb in the US is that 80% of the costs of a fiber build are > in engineering, planning, RoW acquisition, lawyers, etc. That's obviously because of your madogiwazoku quality of engineering. > Of the > remaining 20%, more of it is labor than materials. Price per fiber > strand in the bundle is noise in the larger equation. Drop cables increase the length of the bundle and labor for it. >> http://itpro.nikkeibp.co.jp/article/COLUMN/20080619/308665/ > > Having actually been involved in building a business plan surrounding > this, As a person who have been involved in building a business plan surrounding this several times, it is obvious to me that you have no or little experience on FTTH. > I don't need to read Japanese to be able to tell you that the > outside plant engineering was clearly assigned to the madogiwazoku if > they're only getting a 4:1 split on average. Of course, anyone who try to use PON for FTTH is madogiwazoku like you. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Sun Feb 10 00:13:19 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sun, 10 Feb 2013 09:13:19 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> <5114B90F.50002@necom830.hpcl.titech.ac.jp> <5114D927.10908@vaxination.ca> <51159BC3.4050709@necom830.hpcl.titech.ac.jp> <86r4kq7zhg.fsf@seastrom.com> <511635FC.1030402@necom830.hpcl.titech.ac.jp> Message-ID: <5116E61F.9060902@necom830.hpcl.titech.ac.jp> Jason Baugher wrote: > You are seriously saying I should hire a translator to tell me what your > document says? You don't have to, as you are not seriously interested in the topic. BTW, it is not my document but an article in a famous online magazine. > How about you point out a reference > written in a language common to North America, since this IS NANOG. Feel free to do so. > Anyone here doing or know someone doing 4-1 or 8-1 splits, in a typical > American town? I believe most people were talking about areas <50000 > population. The figure of 3.68-1 is by NTT. > Our main cost is labor. Fiber, fdh, splitters, etc... are marginal. You never forget labor cost. Installing more lengthy drop cable, in addition to trunk cable, means more labor. Installing a bulky PON closure with splitter means more labor. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Sun Feb 10 00:22:31 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sun, 10 Feb 2013 09:22:31 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: <24263853.5563.1360423339258.JavaMail.root@benjamin.baylink.com> References: <24263853.5563.1360423339258.JavaMail.root@benjamin.baylink.com> Message-ID: <5116E847.3000001@necom830.hpcl.titech.ac.jp> Jay Ashworth wrote: > So, over three times as much fiber if you're not putting the splitter > in the field, which is... the opposite of what you assert? That is a very minor material cost. What matters is labor, which is mostly proportional to not total length of fiber but total length of cable (including both trunk and drop). Note also that sharing a drop cable between multiple subscribers is virtually impossible. > Or am I dense? Feel free to call yourself so. Masataka Ohta From wbailey at satelliteintelligencegroup.com Sun Feb 10 00:45:40 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Sun, 10 Feb 2013 00:45:40 +0000 Subject: Muni fiber: L1 or L2? In-Reply-To: <5116E61F.9060902@necom830.hpcl.titech.ac.jp> Message-ID: Japan has fiber optic internet all figured out, however cable dressing 101 was a class everyone skipped. http://www.dannychoo.com/post/en/1653/Japan+Optic+Fiber+Internet.html On 2/9/13 4:13 PM, "Masataka Ohta" wrote: >Jason Baugher wrote: > >> You are seriously saying I should hire a translator to tell me what your >> document says? > >You don't have to, as you are not seriously interested in the >topic. > >BTW, it is not my document but an article in a famous online >magazine. > >> How about you point out a reference >> written in a language common to North America, since this IS NANOG. > >Feel free to do so. > >> Anyone here doing or know someone doing 4-1 or 8-1 splits, in a typical >> American town? I believe most people were talking about areas <50000 >> population. > >The figure of 3.68-1 is by NTT. > >> Our main cost is labor. Fiber, fdh, splitters, etc... are marginal. > >You never forget labor cost. > >Installing more lengthy drop cable, in addition to trunk cable, >means more labor. > >Installing a bulky PON closure with splitter means more labor. > > Masataka Ohta > > From jason at thebaughers.com Sun Feb 10 01:21:53 2013 From: jason at thebaughers.com (Jason Baugher) Date: Sat, 9 Feb 2013 19:21:53 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: <5116E61F.9060902@necom830.hpcl.titech.ac.jp> References: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> <5114B90F.50002@necom830.hpcl.titech.ac.jp> <5114D927.10908@vaxination.ca> <51159BC3.4050709@necom830.hpcl.titech.ac.jp> <86r4kq7zhg.fsf@seastrom.com> <511635FC.1030402@necom830.hpcl.titech.ac.jp> <5116E61F.9060902@necom830.hpcl.titech.ac.jp> Message-ID: On Feb 9, 2013 6:14 PM, "Masataka Ohta" wrote: > > Jason Baugher wrote: > > > You are seriously saying I should hire a translator to tell me what your > > document says? > > You don't have to, as you are not seriously interested in the > topic. > If you say so. In your own mind you obviously know far more about this topic than anyone else. I'm shocked that you waste time trying to educate us. > BTW, it is not my document but an article in a famous online > magazine. > There are many famous online magazines. Some have merit. That one may. Who knows? > > How about you point out a reference > > written in a language common to North America, since this IS NANOG. > > Feel free to do so. > You're the one making the assertion, it's not my job to help you make it. > > Anyone here doing or know someone doing 4-1 or 8-1 splits, in a typical > > American town? I believe most people were talking about areas <50000 > > population. > > The figure of 3.68-1 is by NTT. > > Our main cost is labor. Fiber, fdh, splitters, etc... are marginal. > > You never forget labor cost. > > Installing more lengthy drop cable, in addition to trunk cable, > means more labor. > > Installing a bulky PON closure with splitter means more labor. Drops from a splitter vs drops from a splice case for your SS.... Not much difference from what I've seen. > > Masataka Ohta From jfmezei_nanog at vaxination.ca Sun Feb 10 02:43:40 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Sat, 09 Feb 2013 21:43:40 -0500 Subject: Fiber project/IPTV multicast In-Reply-To: <25231684.5607.1360436555185.JavaMail.root@benjamin.baylink.com> References: <25231684.5607.1360436555185.JavaMail.root@benjamin.baylink.com> Message-ID: <5117095C.2020406@vaxination.ca> On 13-02-09 14:02, Jay Ashworth wrote: > Do any of the people who've worked with some of the IPTV delivery services > mentioned here know if their live TV services can be handled via Multicast? Note that in Canada, because incumbents refuse access to their multicast enabled infrastructure, some of the newer (small) IPTV providers use unicast via the GAS/TPIA networks to deliver to individual customers. Obviously, they do not get bandwidth savings when many customers watch the same program, but they are at least able to offer some TV service which allows them to bundle Internet and TV instead of forcing their internet customers to subscribe to the cable service. Bell Canada (telco) does not allow indie ISPs to resell Bell Canada's IPTV service, nor does Bell canada accept to sell it to end users who are not subscribed to ell Canada's own internet service. So for folks on DSL based indie ISPs, , because the telco refuses to sell them IPTV services, the indie smaller IPTV providers provide an alternative. Note that in Canada, there are geographical restrictions to "BDU" (broadcast distribution undertaking). So an IPTV provider who is alower to distributre only in a certan region of Ontario for instance will to geolocate the subscriber before allowing access to the TV data. This geolocation is done by a transaction with the ISP to confirm the address/city of the subscriber falls within the allowed serving area. So the IPTV supplier needs to setup with each ISP to allow for this to happen (and sign contracts, billing etc etc). OTT providers who obtain "network" distribution risght are not regulated. But Broadcast distribution are highly regulated in Canada. From mureninc at gmail.com Sun Feb 10 03:55:59 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Sat, 9 Feb 2013 19:55:59 -0800 Subject: 10 Mbit/s problem in your network Message-ID: Dear NANOG@, In light of the recent discussion titled, "The 100 Gbit/s problem in your network", I'd like to point out that smaller operators and end-sites are currently very busy having and ignoring the 10 Mbit/s problem in their networks. Hotels in major metro areas, for example. Some have great connectivity (e.g. through high-capacity microwave links), and always have a latency of between 5ms and 15ms to the nearest internet exchange, and YouTube and Netflix just work, always, and nearly flawlessly, and in full HD. Others think that load-balancing 150+ rooms with Fast Ethernet and WiFi in every room, plus a couple of conference/meeting rooms (e.g. potentially more than a single /24 worth of all sorts of devices) on a couple of independent T1 and ADSL links is an acceptable practice. Yes, a T1 and an ADSL, with some kind of Layer 3 / 4 balancing! This is at a time when it would not be uncommon to travel with an Apple TV or a Roku. And then not only even YouTube and cbs.com don't work, but an average latency of above 500ms is not unusual in the evenings, and ssh is practically unusable. (Or sometimes they do the balancing wrong, and the ssh connections simply break every minute due to the broken balancer.) And this happens even with boutique hotels like the Joie de Vivre brand in the Silicon Valley (Wild Palms on El Camino Real in Sunnyvale has an absolutely horrible bandwidth even when it's half empty), or with brand-new properties like Hyatt Place in the hometown of a rather famous ILEC that has the whole town glassed up with fiber-optics (the place is less than 2 years old, and Google Maps still shows it as being constructed, yet independent T1 and ADSL links from two distinct ILECs is the only connectivity they have!). How should end-users deal with such broadband incompetence; why do local carriers allow businesses to abuse their connections and their own customers in such ways; why do the sub-contracted internet support companies design and support such broken-by-design setups? When you are staying at a 3* hotel, should you have no expectations that you'll be getting at least a 3Mbps pipe and at least an under 100ms average latency, and won't be getting a balancer that would be breaking up your ssh sessions? Best regards, Constantine. From mike.lyon at gmail.com Sun Feb 10 06:22:38 2013 From: mike.lyon at gmail.com (Mike Lyon) Date: Sat, 9 Feb 2013 22:22:38 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: References: Message-ID: <-4891392952970062557@unknownmsgid> "why do the sub-contracted internet support companies design and support such broken-by-design setups?" Because they don't know any better and lack the technical clue on how to implement a network that can support a hotel-full (or half-full) of people... But i'm sure they all have their MCSEs and CCNAs so they are qualified :) -mike Sent from my iPhone On Feb 9, 2013, at 19:57, "Constantine A. Murenin" wrote: > why do the sub-contracted internet support > companies design and support such broken-by-design setups? From kmedcalf at dessus.com Sun Feb 10 06:56:12 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 09 Feb 2013 23:56:12 -0700 Subject: Test: Please Delete Me Message-ID: <8a824fc193cb1a4280eca0ae3ce95eed@mail.dessus.com> If this gets delivered please delete me. Somehow I seem to have MX requests for nanog.org failing ... --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org From swmike at swm.pp.se Sun Feb 10 06:59:09 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 10 Feb 2013 07:59:09 +0100 (CET) Subject: 10 Mbit/s problem in your network In-Reply-To: References: Message-ID: On Sat, 9 Feb 2013, Constantine A. Murenin wrote: > When you are staying at a 3* hotel, should you have no expectations that > you'll be getting at least a 3Mbps pipe and at least an under 100ms > average latency, and won't be getting a balancer that would be breaking > up your ssh sessions? Not really. Best way to improve this would probably be to get the hotel booking sites to include a separate rating for the internet connectivity. Up until then, getting Internet connectivity into a hotel is either just cost (in case they offer it for free) or probably a badly performing profit center (because as soon as they try to charge their outrageous prices I imagine take up is abysmal). If a good performing hotel actually got better rating out of having bad connectivity, and a badly performing hotel got worse rating at rating sites, then I'd imagine that more emphasis would be put on this. *But* it also requires a standard test that people can run to understand if things are bad or good. For instance, my ISP guarantees to provide 50-100 megabit/s down and 7-10 up on my 100/10 home connection to a speed test site located on neutral ground here in Sweden. So if the hotels could market themselves with some kind of lowest speed guarantee according to some standard, I believe things would improve. Especially if hotels.com (and others) had a special search item for this, where you could do a search and it would only show results for hotels that guaranteed a certain speed. -- Mikael Abrahamsson email: swmike at swm.pp.se From mureninc at gmail.com Sun Feb 10 07:38:32 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Sat, 9 Feb 2013 23:38:32 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: References: Message-ID: On 9 February 2013 22:59, Mikael Abrahamsson wrote: > On Sat, 9 Feb 2013, Constantine A. Murenin wrote: > >> When you are staying at a 3* hotel, should you have no expectations that >> you'll be getting at least a 3Mbps pipe and at least an under 100ms average >> latency, and won't be getting a balancer that would be breaking up your ssh >> sessions? > > > Not really. Best way to improve this would probably be to get the hotel > booking sites to include a separate rating for the internet connectivity. > > Up until then, getting Internet connectivity into a hotel is either just > cost (in case they offer it for free) or probably a badly performing profit > center (because as soon as they try to charge their outrageous prices I > imagine take up is abysmal). > > If a good performing hotel actually got better rating out of having bad > connectivity, and a badly performing hotel got worse rating at rating sites, > then I'd imagine that more emphasis would be put on this. > > *But* it also requires a standard test that people can run to understand if > things are bad or good. For instance, my ISP guarantees to provide 50-100 > megabit/s down and 7-10 up on my 100/10 home connection to a speed test site > located on neutral ground here in Sweden. > > So if the hotels could market themselves with some kind of lowest speed > guarantee according to some standard, I believe things would improve. > Especially if hotels.com (and others) had a special search item for this, > where you could do a search and it would only show results for hotels that > guaranteed a certain speed. The problem here is that somehow someone at Hyatt decided that a regular low-end asymmetrical ~10Mbps/~1Mbps fibre-optic connection from SureWest could be shared (together with a lousy 1.5Mbps T1 from T) between 151 rooms, when almost every single person staying in the hotel has a connection at least twice as big back home, for their own unshared use! Isn't the logical reasoning simply unbelievable? I've tried calling their corporate office, but they, apparently, don't have any kind of a corporate standard for internet connectivity, saying that it's up to the individual hotels and the local conditions. How anyone could math out that an average single-digit Mbps asymmetrical connection can be shared with 151 rooms without any kind of service degradation or outright periodic halts is rather beyond me. Out of curiosity, I've tried going onto SureWestBusiness.com web-site to see what kind of offers they provide for businesses, only to find out that business FTTH connections max out at 10Mbps down and 1Mbps up! Yeap, in a major metro area, that's definitely an ILEC for you! Anyone from SureWest to comment how come residential fibre-optic connections can have 50Mbps/50Mbps, but businesses that share their connection with several hundred residents are limited to 10Mbps down and 1Mbps up max? Why do you even need to have fibre-optics for that kind of stone-age speeds? And I thought AT&T FTTU was slow! C. From mohta at necom830.hpcl.titech.ac.jp Sun Feb 10 08:09:41 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sun, 10 Feb 2013 17:09:41 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> <5114B90F.50002@necom830.hpcl.titech.ac.jp> <5114D927.10908@vaxination.ca> <51159BC3.4050709@necom830.hpcl.titech.ac.jp> <86r4kq7zhg.fsf@seastrom.com> <511635FC.1030402@necom830.hpcl.titech.ac.jp> <5116E61F.9060902@necom830.hpcl.titech.ac.jp> Message-ID: <511755C5.4090501@necom830.hpcl.titech.ac.jp> Jason Baugher wrote: >> You don't have to, as you are not seriously interested in the >> topic. > I'm shocked that you waste time trying to educate us. No, as I said, I'm not trying to educate someone who don't want to be educated. > You're the one making the assertion, it's not my job to help you make it. So, you don't have to be educated. >> Installing more lengthy drop cable, in addition to trunk cable, >> means more labor. >> >> Installing a bulky PON closure with splitter means more labor. > > Drops from a splitter vs drops from a splice case for your SS.... Not much > difference from what I've seen. Except for length, size and cost, there is not much difference. They all are to have drop cables. Masataka Ohta From fredan-nanog at fredan.se Sun Feb 10 12:08:04 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Sun, 10 Feb 2013 13:08:04 +0100 Subject: 10 Mbit/s problem in your network In-Reply-To: References: Message-ID: <51178DA4.9050309@fredan.se> > Others think that load-balancing 150+ rooms with Fast Ethernet and > WiFi in every room, plus a couple of conference/meeting rooms (e.g. > potentially more than a single /24 worth of all sorts of devices) on a > couple of independent T1 and ADSL links is an acceptable practice. > Yes, a T1 and an ADSL, with some kind of Layer 3 / 4 balancing! This Not to be pedantic, but The Last Mile Cache will actually help you to solve this problem, with a local cache server at the hotel. The hotel's ISP must participate in TLMC before they, the hotel, can have a cache server running. -- //fredan http://tlmc.fredan.se From mail at danrl.de Sun Feb 10 13:35:45 2013 From: mail at danrl.de (Dan Luedtke) Date: Sun, 10 Feb 2013 14:35:45 +0100 Subject: Multicast Ethernet frames not bridging between wired and wireless, Netgear CPE In-Reply-To: References: Message-ID: <20130210143545.5a1ad3f9@tunafish> On Sat, 9 Feb 2013 14:31:00 -0500 "Christopher J. Pilkington" wrote: > Further digging indicates > that RA and NS don't cross the bridge from wired to wireless. Are you using the Netgear device for wireless, or is there a wireless adapter/card/whatever in your linux box? If you have linux running on the wireless thingy, u might find the proxy_ndp options useful (/proc/sys/net/ipv6/...) I have a Netgear WG102 running as bridge and it worked without any further tweaking. But, I transport the data via tagged VLANs up to the Netgear who extracts them for each SSID individually. -- Dan L?dtke www.danrl.de From jpv at veldersjes.net Sun Feb 10 16:07:49 2013 From: jpv at veldersjes.net (JP Velders) Date: Sun, 10 Feb 2013 17:07:49 +0100 (CET) Subject: 10 Mbit/s problem in your network In-Reply-To: <51178DA4.9050309@fredan.se> References: <51178DA4.9050309@fredan.se> Message-ID: > Date: Sun, 10 Feb 2013 13:08:04 +0100 > From: fredrik danerklint > Subject: Re: 10 Mbit/s problem in your network > Not to be pedantic, but The Last Mile Cache will actually help you to > solve this problem, with a local cache server at the hotel. > The hotel's ISP must participate in TLMC before they, the hotel, can > have a cache server running. And as a business traveller I want to have the ISP or Hotel cache (aka be able to read and for others to be found!) my possibly very sensitive corporate documents exactly _why_ ? The TLMC concept only has possible applications in certain residential settings. And even then it's very debatable as to how it could actually improve instead of overcomplicate and deteriorate the entire service along the route. Kind regards, JP Velders From mansaxel at besserwisser.org Sun Feb 10 16:11:56 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Sun, 10 Feb 2013 17:11:56 +0100 Subject: 10 Mbit/s problem in your network In-Reply-To: References: <51178DA4.9050309@fredan.se> Message-ID: <20130210161155.GJ21612@besserwisser.org> Subject: Re: 10 Mbit/s problem in your network Date: Sun, Feb 10, 2013 at 05:07:49PM +0100 Quoting JP Velders (jpv at veldersjes.net): > > Not to be pedantic, but The Last Mile Cache will actually help you to > > solve this problem, with a local cache server at the hotel. > And as a business traveller I want to have the ISP or Hotel cache (aka > be able to read and for others to be found!) my possibly very > sensitive corporate documents exactly _why_ ? A VPN or SSH session (which is what most hotel guests traveling for work will do) won't cache at all well, so this is a very bad idea. Might improve some things, but not the really important ones. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Thousands of days of civilians ... have produced a ... feeling for the aesthetic modules -- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From fredan-nanog at fredan.se Sun Feb 10 16:33:04 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Sun, 10 Feb 2013 17:33:04 +0100 Subject: 10 Mbit/s problem in your network In-Reply-To: References: <51178DA4.9050309@fredan.se> Message-ID: <5117CBC0.3090501@fredan.se> >> Not to be pedantic, but The Last Mile Cache will actually help you to >> solve this problem, with a local cache server at the hotel. > >> The hotel's ISP must participate in TLMC before they, the hotel, can >> have a cache server running. > > And as a business traveller I want to have the ISP or Hotel cache (aka > be able to read and for others to be found!) my possibly very > sensitive corporate documents exactly _why_ ? Since when have you started to publish your sensitive corporate documents on public sites, cause that's what's needed for TLMC to cache your documents in the first place. Look, If a CSP (Content Service Provider - where you host your documents) does not want to have it's content cached, they don't need too. The cache server(s) at the ISP:s around the world will then _not_ be able to cache it. The traffic will in this case, will be loaded directly from the CSP. > The TLMC concept only > has possible applications in certain residential settings. No. It will help the ISP:s to distribute their loads in their network. > And even > then it's very debatable as to how it could actually improve instead > of overcomplicate and deteriorate the entire service along the route. How about those who have limited bandwidth to the Internet? Like ferries, trains, buses or satellite links... -- //fredan http://tlmc.fredan.se From jpv at veldersjes.net Sun Feb 10 18:35:14 2013 From: jpv at veldersjes.net (JP Velders) Date: Sun, 10 Feb 2013 19:35:14 +0100 (CET) Subject: 10 Mbit/s problem in your network In-Reply-To: <5117CBC0.3090501@fredan.se> References: <51178DA4.9050309@fredan.se> <5117CBC0.3090501@fredan.se> Message-ID: > Date: Sun, 10 Feb 2013 17:33:04 +0100 > From: fredrik danerklint > Subject: Re: 10 Mbit/s problem in your network > Since when have you started to publish your sensitive corporate > documents on public sites, cause that's what's needed for TLMC to > cache your documents in the first place. You seem to be mistaken that any bandwidth issue will be remedied by TLMC. A significant number (well over the 50% mark I'd wager) will not be remedied. This thread was started over such a subject. The Apple TV cited as an example was an example. Travellers, be they corporate or leisure, have significant networking needs that the TLMC cannot address. Just think of "The Cloud" (yes, I'll go and flog myself for bringing it into a discussion on NANOG), where people are storing their (semi-) private documents or files - in the end it's similar to connecting back to the office to access the fileserver. > How about those who have limited bandwidth to the Internet? Like > ferries, trains, buses or satellite links... And pray tell me, why should they all have TLMC's ? If the concepts and technologies underlying "The Internet" were invented to have the same ubiquitous speed for all, I think it would have a fairly different design. Now if you're a content provider, then yes I can imagine why you'd like everybody else to pay for better ways to deliver your content without having to pay for it yourself. The examples you cite are the prime examples where users either bring their own entertainment, or it is already provided. On a long airplane flight it is quite uncommon to not have some offering with movies or audio, free or paid is outside scope since TLMC's won't be free either. After all, when I sleep or travel on the road my bandwidth use is vastly different from when at home, work or at a hotel. Within this discussion we're talking about the actual last mile. A proxy or cache won't be of any use if the users can't get to it with sufficient bandwidth to make it work anyway. Kind regards, JP Velders From joelja at bogus.com Sun Feb 10 19:02:52 2013 From: joelja at bogus.com (joel jaeggli) Date: Sun, 10 Feb 2013 11:02:52 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: References: Message-ID: <5117EEDC.9030700@bogus.com> On 2/9/13 7:55 PM, Constantine A. Murenin wrote: > Dear NANOG@, > > In light of the recent discussion titled, "The 100 Gbit/s problem in > your network", I'd like to point out that smaller operators and > end-sites are currently very busy having and ignoring the 10 Mbit/s > problem in their networks. > > Hotels in major metro areas, for example. Some have great > connectivity (e.g. through high-capacity microwave links), and always > have a latency of between 5ms and 15ms to the nearest internet > exchange, and YouTube and Netflix just work, always, and nearly > flawlessly, and in full HD. > > Others think that load-balancing 150+ rooms with Fast Ethernet and > WiFi in every room, plus a couple of conference/meeting rooms (e.g. > potentially more than a single /24 worth of all sorts of devices) on a > couple of independent T1 and ADSL links is an acceptable practice. > Yes, a T1 and an ADSL, with some kind of Layer 3 / 4 balancing! This > is at a time when it would not be uncommon to travel with an Apple TV > or a Roku. And then not only even YouTube and cbs.com don't work, but > an average latency of above 500ms is not unusual in the evenings, and > ssh is practically unusable. (Or sometimes they do the balancing > wrong, and the ssh connections simply break every minute due to the > broken balancer.) > > And this happens even with boutique hotels like the Joie de Vivre > brand in the Silicon Valley (Wild Palms on El Camino Real in Sunnyvale > has an absolutely horrible bandwidth even when it's half empty), or > with brand-new properties like Hyatt Place in the hometown of a rather > famous ILEC that has the whole town glassed up with fiber-optics (the > place is less than 2 years old, and Google Maps still shows it as > being constructed, yet independent T1 and ADSL links from two distinct > ILECs is the only connectivity they have!). Network is rather far outside the core competency of most hotel manangement corporations and REITS assuming they have any at all. There's fairly abundant reasons reasons why they or their contractors might not be very good at it or be able to deliver a decent service at the pricepoint they have budgeted. When you consider the alternative is bringing your own (in the form of HSDPA/LTE) and that might in many cases be an order of magnitude faster, it's hard to imagine how most of them would address that in a fashion that generates in cost recovery on the service or pricing power on rooms. > How should end-users deal with such broadband incompetence; why do > local carriers allow businesses to abuse their connections and their > own customers in such ways; why do the sub-contracted internet support > companies design and support such broken-by-design setups? > > When you are staying at a 3* hotel, should you have no expectations > that you'll be getting at least a 3Mbps pipe and at least an under > 100ms average latency, and won't be getting a balancer that would be > breaking up your ssh sessions? > > Best regards, > Constantine. > From fredan-nanog at fredan.se Sun Feb 10 19:15:11 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Sun, 10 Feb 2013 20:15:11 +0100 Subject: 10 Mbit/s problem in your network In-Reply-To: References: <51178DA4.9050309@fredan.se> <5117CBC0.3090501@fredan.se> Message-ID: <5117F1BF.7080806@fredan.se> > You seem to be mistaken that any bandwidth issue will be remedied by > TLMC. A significant number (well over the 50% mark I'd wager) will not > be remedied. This thread was started over such a subject. And to save 1 - 5 Mbit/s of this bandwidth is wrong, how? > The Apple TV cited as an example was an example. If the TV Show/films/movies/etc.. is static content, then we should be able to cache it, at the hotel's cache server. > Travellers, be they > corporate or leisure, have significant networking needs that the TLMC > cannot address. Just think of "The Cloud" (yes, I'll go and flog > myself for bringing it into a discussion on NANOG), where people are > storing their (semi-) private documents or files - in the end it's > similar to connecting back to the office to access the fileserver. (We have 1 - 5 Mbit/s of more bandwidth for these services). What you are talking about here is dynamic content, which should not be cached at all and everyone knows this. >> How about those who have limited bandwidth to the Internet? Like >> ferries, trains, buses or satellite links... > > And pray tell me, why should they all have TLMC's ? I'm not saying that they should have a cache server. I'm saying that they could. > Now if you're a content provider, then yes I can > imagine why you'd like everybody else to pay for better ways to > deliver your content without having to pay for it yourself. It does matter how you are going to try to solve this, it is always the customer who is going to pay in the end. > Within this discussion we're talking about the actual last mile. I call it "The Last Mile Cache", TLMC > A proxy or cache won't be of any use if the users can't get to it with > sufficient bandwidth to make it work anyway. So, as long as a user does not have enough bandwidth, they should not have a cache server on their side, correct? -- //fredan http://tlmc.fredan.se From stephen at sprunk.org Sun Feb 10 19:24:28 2013 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 10 Feb 2013 13:24:28 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: <5110256F.6000009@vaxination.ca> References: <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> <5110256F.6000009@vaxination.ca> Message-ID: <5117F3EC.9090209@sprunk.org> On 04-Feb-13 15:17, Jean-Francois Mezei wrote: > On 13-02-04 16:04, Scott Helms wrote: >> Subscribers don't care if the hand off is at layer 1 or layer 2 so this is moot as well. > This is where one has to be carefull. The wholesale scenario in Canada leaves indepdendant ISPs having to explain to their customers that they can't fix certain problems and that they must call the telco/cableco to get it fixed. (in the case of a certain cable company, they can't even call them, it has to be done by email with response of at least 48 hours). This is not a show-stopper. In my state (TX), electric utilities have been strictly segregated into generation, distribution and retail. When I have a problem with my service, I call my retailer, who puts in a ticket with the distributor (i.e. grid operator). However, since the distributor has an equal relationship with _all_ retailers, rather than also having a retail arm itself (as in the telco model), there is no service problem. If anything, service is _better_ than when distribution and retailing were done by the same (monopoly) utility company because there are now formal SLAs and penalties. > Another aspect: customers espect to be able to switch seamlessly from one ISP to the next. But ISP-2 can't take over from ISP-1 until ISP-1 has relinquised control over the line to the end user. In a layer 1 scenario, it means ISP-1 has to physically go and deinstall their CPE and disconnect strand from their OLT, and then ISP-2 can do the reverse and reconnect evrything to provide services. Wrong. As soon as retailer 2 puts in the connect order, everything gets switched over within one business day. The distributor stops billing retailer 1 because they're no longer in the picture. Now, if different CPE is required (not an issue for electricity), then the customer would notice that the CPE from retailer 1 suddenly stops working. They would then unplug it and follow the directions that came in the box with the CPE from retailer 2. No truck roll needed, unless they paid extra for that. (In a slightly different space with similar costs, prices and volumes, one carrier said rolling a truck for installation would blow their profit margin for the entire year.) S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2381 bytes Desc: S/MIME Cryptographic Signature URL: From stephen at sprunk.org Sun Feb 10 20:08:24 2013 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 10 Feb 2013 14:08:24 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <69FC211B-12D8-40C6-9558-2C12F9F9DE6A@delong.com> <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> Message-ID: <5117FE38.9080603@sprunk.org> On 02-Feb-13 14:07, Scott Helms wrote: > A layer 1 architecture isn't going to be an economical option for the foreseeable future so opining on its value is a waste of time...its simple not feasible now or even 5 years from now because of costs. The optimal open access network (with current or near future technology) is well known. > Its called Ethernet and the methods to do triple play and open access are well documented not to mention already in wide spread use. Trying to enforce a layer 1 approach would be more expensive than the attempts to make this work with Packet Over SONET or even ATM. It would be more expensive in the short term, yes. But forcing the use of SONET, or ATM, or Ethernet, or any other random technology to save money in the short term will end up costing you more in the long term. You will end up locked into a merry-go-round of upgrades every time someone invents a "better" technology--or locked into an obsolete technology because (as is often the case with govt in the US) there is no funding to upgrade. You're focused on equipment, which has a 3-5 yr depreciation cycle, rather than the facilities, which have a 30-50 yr depreciation cycle. It's a totally different mindset. > What is about a normal Ethernet deployment that you see as a negative? Active equipment in the ONS, limited topology, forced uniformity rather than innovation, etc. > What problem are you tying to solve? The goal at hand is an OSP that will last 50+ years without any significant change. Considering the rapid evolution of technology over the last 10-20 years, the only safe bet is home run fiber. Let service providers decide what technology is best to light up said fiber in any given year. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2381 bytes Desc: S/MIME Cryptographic Signature URL: From stephen at sprunk.org Sun Feb 10 20:18:22 2013 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 10 Feb 2013 14:18:22 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <4DC886AD-60CC-4A34-B2BA-62253A8B0F8A@delong.com> <601BD202-A246-42C3-BB09-B5E9E65CA7B7@delong.com> <052E6BBF-5FA9-4E41-9CDC-7AFBAD0442E1@delong.com> <20130202004356.GA77024@ussenterprise.ufp.org> <20130202101955.GP6172@leitl.org> <6F46D069-60C3-48F7-893C-EF96C715FB4A@delong.com> <8C0B2891-33FC-4B47-9602-9B1F34853B84@delong.com> <0C545170-856A-4309-90E5-9D3676450EDD@delong.com> <847A54F7-4957-46E5-802D-43E05FE7B3AB@delong.com> Message-ID: <5118008E.9060808@sprunk.org> On 03-Feb-13 14:33, Scott Helms wrote: > On Sun, Feb 3, 2013 at 2:53 PM, Owen DeLong wrote: >> Is it more expensive to home-run every home than to put splitters in the neighborhood? Yes. Is it enough more expensive that the tradeoffs cannot be overcome? I remain unconvinced. > This completely depends on the area and the goals of the network. In most cases for muni networks back hauling everything is more expensive. Slightly more expensive in the short term, yes. In the long term, no, especially if you consider the opportunity costs of _not_ being able to deploy new technologies in the future--something only home run dark fiber can guarantee. > Handing out connections at layer 1 is both more expensive and less efficient. Its also extremely wasteful (which is why its more expensive) since your lowest unit you can sell is a fiber strand whether the end customer wants a 3 mbps connection or a gig its the same to the city. So what? How any particular fiber happens to be lit is irrelevant to the muni--and it doesn't change their cost structure one iota. Dark fiber is dark fiber. > I'm not saying you shouldn't sell dark fiber, I'm saying that in 99% of the cities you can't build a business model around doing just that unless your city doesn't want to break even on the build and maintenance. As a private operator, no, you probably can't build a business model around that. A muni has different economics, though. At the cost levels being thrown around here, it doesn't seem like there would be _any_ difficulty in breaking even, which is all a muni needs to do. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2381 bytes Desc: S/MIME Cryptographic Signature URL: From jra at baylink.com Sun Feb 10 22:18:13 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 10 Feb 2013 17:18:13 -0500 (EST) Subject: 10 Mbit/s problem in your network In-Reply-To: <5117F1BF.7080806@fredan.se> Message-ID: <17588312.5689.1360534693754.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "fredrik danerklint" > > The Apple TV cited as an example was an example. > > If the TV Show/films/movies/etc.. is static content, then we > should be able to cache it, at the hotel's cache server. Oh. *Now* I understand the problem. Do you really think that the content providers, and the delivery systems they purposefully choose for that, actually make that possible, much less practical? Even in your country, much less the countries of, um, North America? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From michal at krsek.cz Sun Feb 10 23:39:51 2013 From: michal at krsek.cz (Michal Krsek) Date: Mon, 11 Feb 2013 00:39:51 +0100 Subject: 10 Mbit/s problem in your network In-Reply-To: <5117F1BF.7080806@fredan.se> References: <51178DA4.9050309@fredan.se> <5117CBC0.3090501@fredan.se> <5117F1BF.7080806@fredan.se> Message-ID: <51182FC7.5010001@krsek.cz> Hello, > >> The Apple TV cited as an example was an example. > > If the TV Show/films/movies/etc.. is static content, then we > should be able to cache it, at the hotel's cache server. The question is "how much it helps". Everyone can easily find that caching Google logo is possible, also some pictures from big media companies webs. Also some program updates may help. I'm not sure what will be cache hit ratio from YouTube (because of very log tail) or facebook pictures. Number of hotel guests is really limited. > >>> How about those who have limited bandwidth to the Internet? Like >>> ferries, trains, buses or satellite links... >> >> And pray tell me, why should they all have TLMC's ? > > I'm not saying that they should have a cache server. I'm saying > that they could. The question is: Is investment for buying TLMC and operation costs for TLMC profitable for the hotel? Seems to me like question: Is investment and operation costs for high bandwidth connection profitable for the hotel? The discussion is really about the hotel business, the best way for the community is to provide a feedback for hotel managers what is expected (for free and for the money). And, eventually, provide a kind of metric. What is really annoying, is when you pay for broken connection. Regards Michal From jra at baylink.com Mon Feb 11 01:02:46 2013 From: jra at baylink.com (jra at baylink.com) Date: 10 Feb 2013 18:02:46 -0700 Subject: LA Daily News: Apartment evacuated after false report of Dorner Message-ID: <31513948.1360544065374.JavaMail.atgservice@atglive19.medianewsgroup.com> From jra at baylink.com Mon Feb 11 01:04:48 2013 From: jra at baylink.com (jra at baylink.com) Date: 10 Feb 2013 18:04:48 -0700 Subject: LA Daily News: Report: Cuba using undersea fiber-optic cable Message-ID: <15952515.1360544188149.JavaMail.atgservice@atglive19.medianewsgroup.com> From jra at baylink.com Mon Feb 11 01:06:40 2013 From: jra at baylink.com (jra at baylink.com) Date: 10 Feb 2013 18:06:40 -0700 Subject: LA Daily News: Google's ultrafast Internet draws startups to KC Message-ID: <32629737.1360544299441.JavaMail.atgservice@atglive19.medianewsgroup.com> From fredan-nanog at fredan.se Mon Feb 11 01:13:04 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Mon, 11 Feb 2013 02:13:04 +0100 Subject: 10 Mbit/s problem in your network In-Reply-To: <17588312.5689.1360534693754.JavaMail.root@benjamin.baylink.com> References: <17588312.5689.1360534693754.JavaMail.root@benjamin.baylink.com> Message-ID: <511845A0.4050808@fredan.se> > *Now* I understand the problem. > > Do you really think that the content providers, and the delivery systems > they purposefully choose for that, actually make that possible, much less > practical? (I'm not sure that I understand what you mean with that sentence). If you mean that a CSP already has an agreement with a CDN, why should they change it to something else since it works right now for them? If this is what you mean, yes the can add TLMC to their mix as well and continue with whatever they are using today for delivering their contents. > Even in your country, much less the countries of, um, North America? I think that has more to do with the CSP since they are actual needed in the first place. After that it is the ISP, which in turns adds the possibility for a end-user/customer/residence to set-up their own cache server at home. > > Cheers, > -- jra > -- //fredan http://tlmc.fredan.se From jared at puck.nether.net Mon Feb 11 01:25:54 2013 From: jared at puck.nether.net (Jared Mauch) Date: Sun, 10 Feb 2013 20:25:54 -0500 Subject: Multicast Ethernet frames not bridging between wired and wireless, Netgear CPE In-Reply-To: References: Message-ID: I've seen some Linux boxes in bridge mode do strange things with wireless and ipv6. Using wds mode resolved it. Is the wireless in wds mode? On Feb 9, 2013, at 2:31 PM, "Christopher J. Pilkington" wrote: > I've a Netgear 7550 B90 provided by Frontier. (Yes, it's my only choice > other than VSAT. Rural US. Yes, I am already looking into getting my own > CPE, but humor me.) > > Since Frontier doesn't support IPv6, I've linux box on the LAN building an > AYIYA tunnel, and doing the usual router thing on the wired Ethernet. > Everything on the wired side works splendid. > > Wireless clients didn't seem to want to play. Further digging indicates > that RA and NS don't cross the bridge from wired to wireless. Manually > assigning IPv6 address and nailing NDP entries allows ICMPv6 echo request > to work. > > Has anyone seen this class of device drop multicast between the wireless > radio and the wired ethernet switch? > > Or am I brain dead this morning and missing something obvious? Heck, I > even tried disabling WPA2 thinking it was some wonky encryption thing. > > Thanks, > -cjp From jra at baylink.com Mon Feb 11 01:43:28 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 10 Feb 2013 20:43:28 -0500 (EST) Subject: JoeJobbed, I think In-Reply-To: <19407826.5695.1360546806432.JavaMail.root@benjamin.baylink.com> Message-ID: <3686087.5697.1360547007995.JavaMail.root@benjamin.baylink.com> Here are the relevant headers as I saw them from the list: """ Received: from benjamin.baylink.com ([127.0.0.1]) by localhost (benjamin.baylink.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv7Ib4bfEtWx for ; Sun, 10 Feb 2013 19:55:34 -0500 (EST) Received: from sc1.nanog.org (sc1.nanog.org [50.31.151.68]) by benjamin.baylink.com (Postfix) with ESMTPS id 280D91F0012A for ; Sun, 10 Feb 2013 19:55:34 -0500 (EST) Received: from localhost ([::1] helo=sc1.nanog.org) by sc1.nanog.org with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1U4hg5-0007zX-6D; Mon, 11 Feb 2013 00:55:25 +0000 Received: from smtp.mnginteractive.com ([63.147.64.243]) by sc1.nanog.org with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1U4hfD-00074r-27 for nanog at nanog.org; Mon, 11 Feb 2013 00:54:31 +0000 Date: 10 Feb 2013 18:02:46 -0700 X-SBRS: None X-HAT: Message received through Sender Group RELAYLIST, Policy $RELAYED applied. Received: from atglive19.medianewsgroup.com ([10.148.16.99]) by smtp.mnginteractive.com with ESMTP; 10 Feb 2013 18:02:46 -0700 Message-ID: <31513948.1360544065374.JavaMail.atgservice at atglive19.medianewsgroup.com> """ Unless I'm very much mistaken, I believe that last Received before the date (combined with absence of the static IP of my mailserver) is evidence of an envelope-level forgery. If whomever is babysitting the list this quarter pings me direct, I'll give them that static (assuming they can't already see it themselves), and they can double check, but it doesn't look like it came through my server; no appearances of nanog.org in my lots between 1720 and 1855EDT. I note also that I can't see a message body either in the copies I got from the list, or the ones I was forwarded. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From Simon.Allard at team.orcon.net.nz Mon Feb 11 01:47:53 2013 From: Simon.Allard at team.orcon.net.nz (Simon Allard) Date: Mon, 11 Feb 2013 01:47:53 +0000 Subject: Level3 worldwide emergency upgrade? In-Reply-To: References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <2D0AF14BA6FB334988BC1F5D4FC38CB81E65E5D82C@EXCHMBX.hq.nac.net> <20130206131015.GE20536@hijacked.us> Message-ID: I think you might find its this issue. PSN-2013-01-823 "Junos: Crafted TCP packet can lead to kernel crash" -----Original Message----- From: Matthew Petach [mailto:mpetach at netflight.com] Sent: Thursday, 7 February 2013 7:23 a.m. To: Jonathan Towne Cc: nanog at nanog.org Subject: Re: Level3 worldwide emergency upgrade? On Wed, Feb 6, 2013 at 5:10 AM, Jonathan Towne wrote: > On Wed, Feb 06, 2013 at 07:57:06AM -0500, Alex Rubenstein scribbled: > # The question should be more along the lines of, "why aren't you multihomed in a way that would make a 30 minute outage (which is inevitable) irrelevant to you? > > The fun part of this emergency maintenance in the northeast USA was > that even folks who are multihomed felt it: Level3 managed to do this > in a way that kept BGP sessions up but killed the ability to actually > pass traffic. I'm not sure what they did that caused this, or whether > anyone but northeast folks were affected by it, but it sure was neat > to be effectively blackholed in and out of one of your provided circuits for a while. I recommend you grab http://kestrel3.netflight.com/2013.02.05-NANOG57-day2-afternoon-session.txt and search for PR8361907 Richard did a very good lightning talk about why Juniper boxes will bring up BGP but blackhole traffic for 30 minutes to over an hour, depending on number of BGP sessions it is handling. His recommendation--if you don't like it, go tell Juniper to fix that bug. Matt -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ Teach Email Guard if this mail (ID 09IV6SM1n) is spam: Spam: https://emailguard.orcon.net.nz/canit/b.php?i=09IV6SM1n&m=d5617dabf346&t=20130207&c=s Not spam: https://emailguard.orcon.net.nz/canit/b.php?i=09IV6SM1n&m=d5617dabf346&t=20130207&c=n Forget vote: https://emailguard.orcon.net.nz/canit/b.php?i=09IV6SM1n&m=d5617dabf346&t=20130207&c=f ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS From Simon.Allard at team.orcon.net.nz Mon Feb 11 01:58:40 2013 From: Simon.Allard at team.orcon.net.nz (Simon Allard) Date: Mon, 11 Feb 2013 01:58:40 +0000 Subject: Level3 worldwide emergency upgrade? In-Reply-To: References: <1BEAC5BC-55CB-4F36-8F01-D5BF73B38208@puck.nether.net> <2D0AF14BA6FB334988BC1F5D4FC38CB81E65E5D82C@EXCHMBX.hq.nac.net> <20130206131015.GE20536@hijacked.us> Message-ID: Sorry, should rephrase. The reason for the upgrade is PSN-2013-01-823 (PR 839412) The reason for the BGP blackhole, is as you point out PR8361907 -----Original Message----- From: Simon Allard [mailto:Simon.Allard at team.orcon.net.nz] Sent: Monday, 11 February 2013 2:48 p.m. To: Matthew Petach; Jonathan Towne Cc: nanog at nanog.org Subject: RE: Level3 worldwide emergency upgrade? I think you might find its this issue. PSN-2013-01-823 "Junos: Crafted TCP packet can lead to kernel crash" -----Original Message----- From: Matthew Petach [mailto:mpetach at netflight.com] Sent: Thursday, 7 February 2013 7:23 a.m. To: Jonathan Towne Cc: nanog at nanog.org Subject: Re: Level3 worldwide emergency upgrade? On Wed, Feb 6, 2013 at 5:10 AM, Jonathan Towne wrote: > On Wed, Feb 06, 2013 at 07:57:06AM -0500, Alex Rubenstein scribbled: > # The question should be more along the lines of, "why aren't you multihomed in a way that would make a 30 minute outage (which is inevitable) irrelevant to you? > > The fun part of this emergency maintenance in the northeast USA was > that even folks who are multihomed felt it: Level3 managed to do this > in a way that kept BGP sessions up but killed the ability to actually > pass traffic. I'm not sure what they did that caused this, or whether > anyone but northeast folks were affected by it, but it sure was neat > to be effectively blackholed in and out of one of your provided circuits for a while. I recommend you grab http://kestrel3.netflight.com/2013.02.05-NANOG57-day2-afternoon-session.txt and search for PR8361907 Richard did a very good lightning talk about why Juniper boxes will bring up BGP but blackhole traffic for 30 minutes to over an hour, depending on number of BGP sessions it is handling. His recommendation--if you don't like it, go tell Juniper to fix that bug. Matt -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ Teach Email Guard if this mail (ID 09IV6SM1n) is spam: Spam: https://emailguard.orcon.net.nz/canit/b.php?i=09IV6SM1n&m=d5617dabf346&t=20130207&c=s Not spam: https://emailguard.orcon.net.nz/canit/b.php?i=09IV6SM1n&m=d5617dabf346&t=20130207&c=n Forget vote: https://emailguard.orcon.net.nz/canit/b.php?i=09IV6SM1n&m=d5617dabf346&t=20130207&c=f ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS -- BEGIN-ANTISPAM-VOTING-LINKS ------------------------------------------------------ Teach Email Guard if this mail (ID 08IWO9iX8) is spam:Spam: https://emailguard.orcon.net.nz/canit/b.php?i=08IWO9iX8&m=e4a08b3bbde1&t=20130211&c=sNot spam: https://emailguard.orcon.net.nz/canit/b.php?i=08IWO9iX8&m=e4a08b3bbde1&t=20130211&c=nForget vote: https://emailguard.orcon.net.nz/canit/b.php?i=08IWO9iX8&m=e4a08b3bbde1&t=20130211&c=f ------------------------------------------------------ END-ANTISPAM-VOTING-LINKS From mureninc at gmail.com Mon Feb 11 02:57:35 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Sun, 10 Feb 2013 18:57:35 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: <5117EEDC.9030700@bogus.com> References: <5117EEDC.9030700@bogus.com> Message-ID: On 10 February 2013 11:02, joel jaeggli wrote: > On 2/9/13 7:55 PM, Constantine A. Murenin wrote: >> >> Dear NANOG@, >> >> In light of the recent discussion titled, "The 100 Gbit/s problem in >> your network", I'd like to point out that smaller operators and >> end-sites are currently very busy having and ignoring the 10 Mbit/s >> problem in their networks. >> >> Hotels in major metro areas, for example. Some have great >> connectivity (e.g. through high-capacity microwave links), and always >> have a latency of between 5ms and 15ms to the nearest internet >> exchange, and YouTube and Netflix just work, always, and nearly >> flawlessly, and in full HD. >> >> Others think that load-balancing 150+ rooms with Fast Ethernet and >> WiFi in every room, plus a couple of conference/meeting rooms (e.g. >> potentially more than a single /24 worth of all sorts of devices) on a >> couple of independent T1 and ADSL links is an acceptable practice. >> Yes, a T1 and an ADSL, with some kind of Layer 3 / 4 balancing! This >> is at a time when it would not be uncommon to travel with an Apple TV >> or a Roku. And then not only even YouTube and cbs.com don't work, but >> an average latency of above 500ms is not unusual in the evenings, and >> ssh is practically unusable. (Or sometimes they do the balancing >> wrong, and the ssh connections simply break every minute due to the >> broken balancer.) >> >> And this happens even with boutique hotels like the Joie de Vivre >> brand in the Silicon Valley (Wild Palms on El Camino Real in Sunnyvale >> has an absolutely horrible bandwidth even when it's half empty), or >> with brand-new properties like Hyatt Place in the hometown of a rather >> famous ILEC that has the whole town glassed up with fiber-optics (the >> place is less than 2 years old, and Google Maps still shows it as >> being constructed, yet independent T1 and ADSL links from two distinct >> ILECs is the only connectivity they have!). > > Network is rather far outside the core competency of most hotel manangement > corporations and REITS assuming they have any at all. > > There's fairly abundant reasons reasons why they or their contractors might > not be very good at it or be able to deliver a decent service at the > pricepoint they have budgeted. > > When you consider the alternative is bringing your own (in the form of > HSDPA/LTE) and that might in many cases be an order of magnitude faster, > it's hard to imagine how most of them would address that in a fashion that > generates in cost recovery on the service or pricing power on rooms. Well, let's do a thought experiment on cost comparison to put things into perspective. * How much do they pay for the actual pipe? * How much do they pay for the outsourced maintenance and the technical support contract? (Tech support is outsourced to New York.) * How much do they pay to an average in-house employee? * How much do they pay to receive and deliver the newspapers in the mornings to at least half the rooms? (Potentially more than 2000 copies a month at just half the rooms.) And: * How much do they charge per night per room? Then times 151, then times 31? Something along the lines of 200'000$/mo to 600'000$/mo? Unless my guesstimates are wrong, even 100$/mo for the actual pipe is completely and utterly nothing compared to all the other expenses (and the revenue), and I think their 10Mbps down / 1Mbps up fibre-optic (or ADSL?) connection from SureWest Business is even cheaper than that (although their AT&T T1 is probably not, but then it's still rather unclear why they even need to load-balance 151 rooms over a T1 in a brand-new building in a major metro area in California in 2013 anyways). Even at 500$/mo for the pipe it would still be SEVERAL TIMES cheaper than delivering the daily newspaper to every guest every morning alone. Even with just a couple of speed-related tech-support calls per month, it might still be cheaper to upgrade to a better pipe than to have the guests needing to call the support and being inconvenienced with even a very slight likelihood of not returning. Besides, why would leisure and business travellers need a complementary newspaper in the morning, but would be OK with 200ms average latency and 300ms std-dev / jitter, and not being able to watch YouTube, video conference or work remotely comfortably, is something that I'm yet to comprehend. Yet the local management of the hotel thinks that there's no problem. "Internet works." "It's been fixed." "We've fixed your internet, sir -- the system has been rebooted; please check again in a few minutes." "Yes, sir, some customers occasionally do complain that the video streaming doesn't work; but most people just check their email, and it works." "Sir, I personally do have a 30Mbps connection at home, but here at our hotel 10Mbps (+ 1.5Mbps) is shared between 151 suites; what's your problem again, sir?" I think it is honestly laughable that they must be spending about 3$/day (the price of coffee at some Starbucks locations) for their actual internet pipe for the whole hotel. Also, do people really think that a 10/1 connection is still a 10/1 "broadband" even when shared with hundreds of folks? Best regards, Constantine. > >> How should end-users deal with such broadband incompetence; why do >> local carriers allow businesses to abuse their connections and their >> own customers in such ways; why do the sub-contracted internet support >> companies design and support such broken-by-design setups? >> >> When you are staying at a 3* hotel, should you have no expectations >> that you'll be getting at least a 3Mbps pipe and at least an under >> 100ms average latency, and won't be getting a balancer that would be >> breaking up your ssh sessions? >> >> Best regards, >> Constantine. From rsk at gsp.org Mon Feb 11 03:23:59 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Sun, 10 Feb 2013 22:23:59 -0500 Subject: JoeJobbed, I think In-Reply-To: <3686087.5697.1360547007995.JavaMail.root@benjamin.baylink.com> References: <19407826.5695.1360546806432.JavaMail.root@benjamin.baylink.com> <3686087.5697.1360547007995.JavaMail.root@benjamin.baylink.com> Message-ID: <20130211032359.GA1900@gsp.org> On Sun, Feb 10, 2013 at 08:43:28PM -0500, Jay Ashworth wrote: > Unless I'm very much mistaken, I believe that last Received before the date > (combined with absence of the static IP of my mailserver) is evidence of an > envelope-level forgery. Concur -- it looks that way from here as well. What's not clear is whether it's deliberate or an artifact resulting from breakage. ---rsk From jason at thebaughers.com Mon Feb 11 05:13:59 2013 From: jason at thebaughers.com (Jason Baugher) Date: Sun, 10 Feb 2013 23:13:59 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: <511755C5.4090501@necom830.hpcl.titech.ac.jp> References: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> <5114B90F.50002@necom830.hpcl.titech.ac.jp> <5114D927.10908@vaxination.ca> <51159BC3.4050709@necom830.hpcl.titech.ac.jp> <86r4kq7zhg.fsf@seastrom.com> <511635FC.1030402@necom830.hpcl.titech.ac.jp> <5116E61F.9060902@necom830.hpcl.titech.ac.jp> <511755C5.4090501@necom830.hpcl.titech.ac.jp> Message-ID: On Sun, Feb 10, 2013 at 2:09 AM, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > Jason Baugher wrote: > > >> You don't have to, as you are not seriously interested in the > >> topic. > > > I'm shocked that you waste time trying to educate us. > > No, as I said, I'm not trying to educate someone who don't want > to be educated. > > You're not trying to educate anyone at all. You're just stomping your foot and insisting that you're right rather than have a meaningful discussion. > > You're the one making the assertion, it's not my job to help you make it. > > So, you don't have to be educated. > > >> Installing more lengthy drop cable, in addition to trunk cable, > >> means more labor. > >> > >> Installing a bulky PON closure with splitter means more labor. > > > > Drops from a splitter vs drops from a splice case for your SS.... Not > much > > difference from what I've seen. > > Except for length, size and cost, there is not much difference. > > They all are to have drop cables. > I did some research on what NTT has done on fiber deployment. From what I've seen, they split things up into feeder, distribution and drop cable, with the splitter between feeder and distribution. Amazingly enough, that's what we do as well. Feeder to splitter, then on down the street breaking off at strategic splice cases where drops go to houses. The only difference between that and our active infrastructure is the presence of the splitter. We also do single-stage 32:1 splits. If we ran each drop cable from the splitter all the way to the house, we would have extremely long drop cables, and lots of them all bundled together going down the street. We don't do that, we use mainline distribution cable like I described above. The last thing I feel that I need to point out is that what works in one type of area doesn't necessarily work in another. Fiber deployment in a large urban area is a completely different animal than in a 40-50K population town in the midwest USA. Masataka Ohta > > From malayter at gmail.com Mon Feb 11 05:46:01 2013 From: malayter at gmail.com (Ryan Malayter) Date: Sun, 10 Feb 2013 23:46:01 -0600 Subject: The 100 Gbit/s problem in your network In-Reply-To: <511644F6.6020900@fredan.se> References: <3940444.187.1360354551648.JavaMail.art@DQT6ZQ1> <511644F6.6020900@fredan.se> Message-ID: <025C9426-F6D2-4B5E-B29F-4814E8DFAF5A@gmail.com> On Feb 9, 2013, at 6:45 AM, fredrik danerklint wrote: > No. Streaming from services, like Netflix, HBO, etc..., is what's > coming. We need to prepare for the bandwidth they are going to be > using. Then work on your HTTP caching infrastructure. All these services already use a proprietary form of HTTP adaptive streaming, either MSFT, Adobe, or Apple. These technologies are being unified by DASH in the MPEG/ISO standards bodies. Adaptive HTTP chunk streaming gives you the best of multicast-like and cached VoD behavior, exploiting the temporal locality of popularity in content while not requiring multicast. As a content publisher, I must say it works wonders for us so far, even with just two bitrates. There is a huge HTTP caching infrastructure out there in businesses, schools, and other orgs that is unused by other video transports; even plain HTTP downloads usually overrun cache object size limits. The Olympic streaming in particular showed how well HTTP chunk video can scale; dozen of screens in my org showed the same content all day from local cache, with no noticeable spikes on our transit links. Is HTTP as efficient a protocol as possible for transporting video? No, but 1K of headers per 1M of content chunk puts it within 0.1% of netcat. And "working now with widely deployed infrastructure" beats "stuck in Internet Draft forever". From fmartin at linkedin.com Mon Feb 11 08:25:58 2013 From: fmartin at linkedin.com (Franck Martin) Date: Mon, 11 Feb 2013 08:25:58 +0000 Subject: 10 Mbit/s problem in your network In-Reply-To: Message-ID: When staying at Homestead a few years back, they would close my Internet connection, because I was downloading movies via peer to peer. It took me a while and escalating to a relatively competent network engineer to figure it out: "Mate, I don't have any p2p software installed, may be my computer is hacked, tell me what traffic you see that triggers your system, so I can investigate". I came down that they did not like my Skype trying to re-establish connections with contacts in Asia/Pacific (where I lived then), instead of the USA. I also organized conferences, and putting more than 20 people (with various OS/hacked machines) on the same access point, is not standard operations as in a company, you need some experience with that, something that some ISPs (who were sponsoring the Internet) failed to understand. On 2/9/13 7:55 PM, "Constantine A. Murenin" wrote: >Dear NANOG@, > >In light of the recent discussion titled, "The 100 Gbit/s problem in >your network", I'd like to point out that smaller operators and >end-sites are currently very busy having and ignoring the 10 Mbit/s >problem in their networks. > >Hotels in major metro areas, for example. Some have great >connectivity (e.g. through high-capacity microwave links), and always >have a latency of between 5ms and 15ms to the nearest internet >exchange, and YouTube and Netflix just work, always, and nearly >flawlessly, and in full HD. > >Others think that load-balancing 150+ rooms with Fast Ethernet and >WiFi in every room, plus a couple of conference/meeting rooms (e.g. >potentially more than a single /24 worth of all sorts of devices) on a >couple of independent T1 and ADSL links is an acceptable practice. >Yes, a T1 and an ADSL, with some kind of Layer 3 / 4 balancing! This >is at a time when it would not be uncommon to travel with an Apple TV >or a Roku. And then not only even YouTube and cbs.com don't work, but >an average latency of above 500ms is not unusual in the evenings, and >ssh is practically unusable. (Or sometimes they do the balancing >wrong, and the ssh connections simply break every minute due to the >broken balancer.) > >And this happens even with boutique hotels like the Joie de Vivre >brand in the Silicon Valley (Wild Palms on El Camino Real in Sunnyvale >has an absolutely horrible bandwidth even when it's half empty), or >with brand-new properties like Hyatt Place in the hometown of a rather >famous ILEC that has the whole town glassed up with fiber-optics (the >place is less than 2 years old, and Google Maps still shows it as >being constructed, yet independent T1 and ADSL links from two distinct >ILECs is the only connectivity they have!). > >How should end-users deal with such broadband incompetence; why do >local carriers allow businesses to abuse their connections and their >own customers in such ways; why do the sub-contracted internet support >companies design and support such broken-by-design setups? > >When you are staying at a 3* hotel, should you have no expectations >that you'll be getting at least a 3Mbps pipe and at least an under >100ms average latency, and won't be getting a balancer that would be >breaking up your ssh sessions? > >Best regards, >Constantine. > From mohta at necom830.hpcl.titech.ac.jp Mon Feb 11 09:23:17 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 11 Feb 2013 18:23:17 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <27176479.5313.1360262398753.JavaMail.root@benjamin.baylink.com> <5114B90F.50002@necom830.hpcl.titech.ac.jp> <5114D927.10908@vaxination.ca> <51159BC3.4050709@necom830.hpcl.titech.ac.jp> <86r4kq7zhg.fsf@seastrom.com> <511635FC.1030402@necom830.hpcl.titech.ac.jp> <5116E61F.9060902@necom830.hpcl.titech.ac.jp> <511755C5.4090501@necom830.hpcl.titech.ac.jp> Message-ID: <5118B885.7060509@necom830.hpcl.titech.ac.jp> Jason Baugher wrote: >> No, as I said, I'm not trying to educate someone who don't want >> to be educated. > You're not trying to educate anyone at all. You're just stomping > your foot and insisting that you're right rather than have a > meaningful discussion. So far, I have shown several figures derived from FTTH deployment in the real world to show that PON is more expensive than SS. If you can't accept it, feel free to try to educate us. But, do so with quantitative reasons. > I did some research on what NTT has done on fiber deployment. > From what I've seen, they split things up into feeder, > distribution and drop cable, with the splitter between > feeder and distribution. So? That is ordinary PON that you didn't have to do any research. > We also do single-stage 32:1 splits. NTT do not, well, with reasons. > If we ran each drop cable from the > splitter all the way to the house, we would have extremely long drop > cables, and lots of them all bundled together going down the street. We > don't do that, we use mainline distribution cable like I described above. Then, you need to have on the trunk cable, for 32 subscriebrs, a huge closure with a splitter and 32 (or less, if some are shared) small closures, which costs more than SS, because of extra material and labor for the huge closure. A political problem is that it becomes obvious that 32 (or less) closures required for SS is less expensive than 32 long drop cables with conventional PON. Worse, you have to have spare 31 fibers in the cable, which denies the theory that PON were better than SS because fibers were expensive. If a trunk cable covers 196 subscribers, which is typical, it is obviously a strange design to have only 6 trunk fibers, because fibers are so expensive, but to have other 31 drop fibers in the same cable. You can reduce the number of spare fibers if you give up 32:1 splitting at the first splitter and use the fibers in more complex way to use them in both directions. However, you need more spare fibers if the number of subscribers increase and some splitter overflows and no lengthy service interruption is allowed. That is, reusing some fibers in a trunk cable as intermediate drop is difficult to manage for future configuration changes. It becomes even worse for NTT, which claims that it is doing fair unbundling of its fibers, because NTT must prepare 124 spare fibers, if they allow three other competitors share its cable. So, there is no reason to simply have SS just with small closures, which can be trivially unbundled. Masataka Ohta From adam.vitkovsky at swan.sk Mon Feb 11 10:58:58 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Mon, 11 Feb 2013 11:58:58 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <21241255.5435.1360341368629.JavaMail.root@benjamin.baylink.com> References: <51152674.2050703@fredan.se> <21241255.5435.1360341368629.JavaMail.root@benjamin.baylink.com> Message-ID: <025f01ce0846$caaad7d0$60008770$@swan.sk> >The only time real-time per se matters is if you're playing the same content on multiple screens and *synchronization* matters. And there's the HFT where "real-time" really does matter :) adam From adam.vitkovsky at swan.sk Mon Feb 11 11:03:03 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Mon, 11 Feb 2013 12:03:03 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <20130208170208.GA28509@pob.ytti.fi> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> Message-ID: <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> I don't see a need for multicast to work in Internet scale, ever. adam -----Original Message----- From: Saku Ytti [mailto:saku at ytti.fi] Sent: Friday, February 08, 2013 6:02 PM To: nanog at nanog.org Subject: Re: The 100 Gbit/s problem in your network On (2013-02-08 14:15 +0000), Aled Morris wrote: > "Multicast" I don't see multicast working in Internet scale. Essentially multicast means core is flow-routing. So we'd need some way to decide who gets to send their content as multicast and who are forced to send unicast. It could create de-facto monopolies, as new entries to the market wont have their multicast carried, they cannot compete pricing wise with established players who are carried. -- ++ytti From mohta at necom830.hpcl.titech.ac.jp Mon Feb 11 11:31:04 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 11 Feb 2013 20:31:04 +0900 Subject: 10 Mbit/s problem in your network In-Reply-To: References: Message-ID: <5118D678.2000107@necom830.hpcl.titech.ac.jp> Constantine A. Murenin wrote: > The problem here is that somehow someone at Hyatt decided that a > regular low-end asymmetrical ~10Mbps/~1Mbps fibre-optic connection > from SureWest could be shared (together with a lousy 1.5Mbps T1 from > T) between 151 rooms, when almost every single person staying in the > hotel has a connection at least twice as big back home, for their own > unshared use! Isn't the logical reasoning simply unbelievable? > > I've tried calling their corporate office, but they, apparently, don't > have any kind of a corporate standard for internet connectivity, > saying that it's up to the individual hotels and the local conditions. Yes, that is reasonable. Just saying "Internet connectivity" is too broad for world wide hotel operators. It's up to the local conditions, of course!!! When I was at a resort in an isolated island in Pacific ocean three yeas ago, only connectivity of the resort was through satellite, shared by tens of rooms. There, of course, was no local 2G/3G/4G services. When I was at a hotel in Geneva about 10 years ago, the hotel advertised to be Internet-capable, even though the hotel only offered telephone connectivity to local and international dial-up ISPs. When I was at a resort in Africa more than 15 years ago, there was no telephone connectivity, except for one by private wireless relay maintained by the hotel for its reservation and other its own business purposes. Differentiating the "Internet connectivity" of hotels as: (No?) Internet connectivity (dial up) Internet connectivity (satellite) Internet connectivity (DSL) Internet connectivity (FTTH) could be meaningful, for which NANOG could act for or against it, but there can be no standard for "Internet connectivity" defined world wide, unless you accept 110bps dial up good enough. Masataka Ohta PS You can, of course, pay for private satellite connectivity at certain bps available world wide. From saku at ytti.fi Mon Feb 11 12:13:06 2013 From: saku at ytti.fi (Saku Ytti) Date: Mon, 11 Feb 2013 14:13:06 +0200 Subject: The 100 Gbit/s problem in your network In-Reply-To: <025f01ce0846$caaad7d0$60008770$@swan.sk> References: <51152674.2050703@fredan.se> <21241255.5435.1360341368629.JavaMail.root@benjamin.baylink.com> <025f01ce0846$caaad7d0$60008770$@swan.sk> Message-ID: <20130211121306.GA3660@pob.ytti.fi> On (2013-02-11 11:58 +0100), Adam Vitkovsky wrote: > >The only time real-time per se matters is if you're playing the same content on multiple screens and *synchronization* matters. > And there's the HFT where "real-time" really does matter :) I think most of HFT crowd are buying into low-latency more as 'why not' than as technical necessity. Reducing latency of your switch from comparable of 200m of fibre (quite high latency) to 20m (rather low latency) seems to be very big and important thing. Yet at the same time one of the most relevant exchanges of them all is replicating multicast on MX trio hardware, which means unpredictable/unfair, high delay replication, which will completely abstract out any switch-level micro-optimization you may have gained. -- ++ytti From aledm at qix.co.uk Mon Feb 11 12:16:17 2013 From: aledm at qix.co.uk (Aled Morris) Date: Mon, 11 Feb 2013 12:16:17 +0000 Subject: The 100 Gbit/s problem in your network In-Reply-To: <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> Message-ID: I don't see why, as an ISP, I should carry multiple, identical, payload packets for the same content. I'm more than happy to replicate them closer to my subscribers on behalf of the content publishers. How we do this is the question, i.e. what form the "multi"-"casting" takes. It would be nice if we could take advantage of an inherent design of IP and the hardware it runs on, to duplicate the actual packets in-flow as near as is required to the destination. Installing L7 content delivery boxes or caches is OK, but doesn't seem as efficient as an overall technical solution. Aled On 11 February 2013 11:03, Adam Vitkovsky wrote: > I don't see a need for multicast to work in Internet scale, ever. > > adam > -----Original Message----- > From: Saku Ytti [mailto:saku at ytti.fi] > Sent: Friday, February 08, 2013 6:02 PM > To: nanog at nanog.org > Subject: Re: The 100 Gbit/s problem in your network > > On (2013-02-08 14:15 +0000), Aled Morris wrote: > > > "Multicast" > > I don't see multicast working in Internet scale. > > Essentially multicast means core is flow-routing. So we'd need some way to > decide who gets to send their content as multicast and who are forced to > send unicast. > It could create de-facto monopolies, as new entries to the market wont have > their multicast carried, they cannot compete pricing wise with established > players who are carried. > > -- > ++ytti > > > > From saku at ytti.fi Mon Feb 11 12:23:16 2013 From: saku at ytti.fi (Saku Ytti) Date: Mon, 11 Feb 2013 14:23:16 +0200 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> Message-ID: <20130211122316.GA3686@pob.ytti.fi> On (2013-02-11 12:16 +0000), Aled Morris wrote: > I don't see why, as an ISP, I should carry multiple, identical, payload > packets for the same content. I'm more than happy to replicate them closer > to my subscribers on behalf of the content publishers. How we do this is > the question, i.e. what form the "multi"-"casting" takes. > > It would be nice if we could take advantage of an inherent design of IP and > the hardware it runs on, to duplicate the actual packets in-flow as near as > is required to the destination. > > Installing L7 content delivery boxes or caches is OK, but doesn't seem as > efficient as an overall technical solution. As an overall technical solution Internet scale multicast simply does not work today. If it did work, then our next hurdle would be, how to get tier1 to play ball, they get money on bits transported, it's not in their best interested to reduce that amount. Now maybe, if we really did want, we could do some N:1 compression of IP traffic, where N is something like 3<10. Far worse than multicast, but with this method, we might be able to device technical solution where IP core does not learn replication states at all. We could abuse long IPv6 addresses DADDR + SADDR + extension header to pack information about destination ASN who should receive this group, this could be handled without states in HW in core networks, only at ASN edge, you'd need to add classic multicast state intelligence. -- ++ytti From graham at airstripone.org.uk Mon Feb 11 12:51:11 2013 From: graham at airstripone.org.uk (Graham Donaldson) Date: Mon, 11 Feb 2013 12:51:11 +0000 Subject: 10 Mbit/s problem in your network In-Reply-To: References: Message-ID: <20130211125111.GA15626@airstripone.org.uk> On Sat, Feb 09, 2013 at 07:55:59PM -0800, Constantine A. Murenin wrote: > Dear NANOG@, > > In light of the recent discussion titled, "The 100 Gbit/s problem in > your network", I'd like to point out that smaller operators and > end-sites are currently very busy having and ignoring the 10 Mbit/s > problem in their networks. > > When you are staying at a 3* hotel, should you have no expectations > that you'll be getting at least a 3Mbps pipe and at least an under > 100ms average latency, and won't be getting a balancer that would be > breaking up your ssh sessions? If you don't like it, let them know, and stop providing them with your business. Money talks. They'll either decide they need to invest in good Internet, or they'll decide that for their customer demographic it just isn't worth it. I personally think you're being unreasonable on the bandwidth and latency expectations, Hotel Internet connections are there as a convenience rather than some kind of business grade connection. If you are expecting a top quality connection, expect to pay by the GB - so that greedy patrons watching Netflix HD pay for their bandwidth. Broken SSH connections would annoy me though. Graham. From cjp at 0x1.net Mon Feb 11 13:03:41 2013 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Mon, 11 Feb 2013 08:03:41 -0500 Subject: Multicast Ethernet frames not bridging between wired and wireless, Netgear CPE In-Reply-To: <20130210143545.5a1ad3f9@tunafish> References: <20130210143545.5a1ad3f9@tunafish> Message-ID: On Feb 10, 2013 8:35 AM, "Dan Luedtke" wrote: > Are you using the Netgear device for wireless, or is there a wireless > adapter/card/whatever in your linux box? Netgear was the wireless/wired/ADSL from the provider. Workaround was to make that an ADSL-Ethernet bridge and run PPPoE on another, unbroken, wireless router (WRT54G OpenWrt). Thanks, -cjp From nick at foobar.org Mon Feb 11 13:14:24 2013 From: nick at foobar.org (Nick Hilliard) Date: Mon, 11 Feb 2013 13:14:24 +0000 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> Message-ID: <5118EEB0.2090600@foobar.org> On 11/02/2013 12:16, Aled Morris wrote: > I don't see why, as an ISP, I should carry multiple, identical, payload > packets for the same content. I'm more than happy to replicate them closer > to my subscribers on behalf of the content publishers. How we do this is > the question, i.e. what form the "multi"-"casting" takes. > > It would be nice if we could take advantage of an inherent design of IP and > the hardware it runs on, to duplicate the actual packets in-flow as near as > is required to the destination. Multicast is fine when it works, which is generally only in systems where the operator has end-to-end control of the entire data path, where the number of streams isn't too large that the middleboxes have trouble handling all the state requirements, where the middleboxes all support multicast adequately without causing collateral problems, and where the end point talks the same version of multicast as the source, where you don't run into weird vendor multicast bugs and where you don't have packet loss on any intermediate systems. When it stops working, level 3 engineering will usually be able to get it fixed, given enough time, resources and support from vendors. If you're ok about having escalation level engineering dealing with front-line multicast support issues for customers paying a tenner a month, then I wish you well :-) Nick From jra at baylink.com Mon Feb 11 13:39:08 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Feb 2013 08:39:08 -0500 (EST) Subject: JoeJobbed, I think In-Reply-To: <20130211032359.GA1900@gsp.org> Message-ID: <15813919.5713.1360589948686.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Rich Kulawiec" > On Sun, Feb 10, 2013 at 08:43:28PM -0500, Jay Ashworth wrote: > > Unless I'm very much mistaken, I believe that last Received before > > the date > > (combined with absence of the static IP of my mailserver) is > > evidence of an > > envelope-level forgery. > > Concur -- it looks that way from here as well. What's not clear is > whether it's deliberate or an artifact resulting from breakage. Well, FWIW, I never use anyone's on-platform forwarding service to send article URLs to *anywhere*, much less a mailing list, though curiously I think I *did* put a URL about a Google KC article in a posting last week. Don't remember if it was LAT or not. Just the three postings, right, Rich? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From Sean.Pedersen at usairways.com Mon Feb 11 13:58:10 2013 From: Sean.Pedersen at usairways.com (Pedersen, Sean) Date: Mon, 11 Feb 2013 06:58:10 -0700 Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: <20130208223221.19138.qmail@joyce.lan> References: <20130208223221.19138.qmail@joyce.lan> Message-ID: <7EF4A8B03B0A3A44858C8B42E0DB236A012224CC6D26@PHX-52N-EXM04A.lcc.usairways.com> We used AudioCodes at my last gig - the MP202B, specifically. They were decent, from what I remember. It's been several years since I've worked on them, so don't take this as an endorsement. I'm just adding another possible vendor name/product to the pool. -----Original Message----- From: John Levine [mailto:johnl at iecc.com] Sent: Friday, February 08, 2013 3:32 PM To: nanog at nanog.org Subject: Re: Any experience with Grandstream VoIP equipment ? >I wouldn't use them unless you have a specific reason to. That seems to be the consensus. Lucky I didn't pay very much. Any ATAs that people acually like? -- Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From nathana at fsr.com Mon Feb 11 14:13:29 2013 From: nathana at fsr.com (Nathan Anderson) Date: Mon, 11 Feb 2013 06:13:29 -0800 Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: References: <20130208223221.19138.qmail@joyce.lan> Message-ID: On Saturday, February 09, 2013 1:34 PM, Benny Amorsen wrote: > They are not perfect, but they are pretty good. Have you played around with the T.38 support on the SPA-1XX line? Historically, it has been difficult to find a reasonably-priced, bare-bones (1 FXS, no built-in router) ATA that also happens to do T.38 well. PAP2T had no T.38 support at all. SPA-112 price looks good, so I'm wondering what the catch is. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From ml at kenweb.org Mon Feb 11 14:32:32 2013 From: ml at kenweb.org (ML) Date: Mon, 11 Feb 2013 09:32:32 -0500 Subject: The 100 Gbit/s problem in your network In-Reply-To: <20130211122316.GA3686@pob.ytti.fi> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> <20130211122316.GA3686@pob.ytti.fi> Message-ID: <51190100.8030105@kenweb.org> On 2/11/2013 7:23 AM, Saku Ytti wrote: > On (2013-02-11 12:16 +0000), Aled Morris wrote: > >> I don't see why, as an ISP, I should carry multiple, identical, payload >> packets for the same content. I'm more than happy to replicate them closer >> to my subscribers on behalf of the content publishers. How we do this is >> the question, i.e. what form the "multi"-"casting" takes. >> >> It would be nice if we could take advantage of an inherent design of IP and >> the hardware it runs on, to duplicate the actual packets in-flow as near as >> is required to the destination. >> >> Installing L7 content delivery boxes or caches is OK, but doesn't seem as >> efficient as an overall technical solution. > As an overall technical solution Internet scale multicast simply does not > work today. > If it did work, then our next hurdle would be, how to get tier1 to play > ball, they get money on bits transported, it's not in their best interested > to reduce that amount. Any eyeball network that wants to support multicast should peer with the content players(s) that support it. Simple! Just another reason to make the transit only networks even more irrelevant. From ikiris at gmail.com Mon Feb 11 14:38:05 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Mon, 11 Feb 2013 08:38:05 -0600 Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: References: <20130208223221.19138.qmail@joyce.lan> Message-ID: As another reference point, I really liked the sipura atas, they were my personal favorite as far as the gear we used. I don't know how well that translates to after the linksys takeover though, as I haven't done voice gear in a few years. -Blake On Mon, Feb 11, 2013 at 8:13 AM, Nathan Anderson wrote: > On Saturday, February 09, 2013 1:34 PM, Benny Amorsen benny+usenet at amorsen.dk> wrote: > > > They are not perfect, but they are pretty good. > > Have you played around with the T.38 support on the SPA-1XX line? > Historically, it has been difficult to find a reasonably-priced, > bare-bones (1 FXS, no built-in router) ATA that also happens to do T.38 > well. PAP2T had no T.38 support at all. > > SPA-112 price looks good, so I'm wondering what the catch is. > > -- > Nathan Anderson > First Step Internet, LLC > nathana at fsr.com > > From benny+usenet at amorsen.dk Mon Feb 11 14:55:04 2013 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Mon, 11 Feb 2013 15:55:04 +0100 Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: (Nathan Anderson's message of "Mon, 11 Feb 2013 06:13:29 -0800") References: <20130208223221.19138.qmail@joyce.lan> Message-ID: Nathan Anderson writes: > Have you played around with the T.38 support on the SPA-1XX line? > Historically, it has been difficult to find a reasonably-priced, > bare-bones (1 FXS, no built-in router) ATA that also happens to do > T.38 well. PAP2T had no T.38 support at all. T.38 support was the primary reason for choosing that model. Before the SPA-112, we used SPA-2102 which had the major disadvantage of being a router. It meant we had to log in to the box to enable provisioning on the WAN interface (and just hope that no one plugged a cable into the LAN). The SPA-112 is a much better solution. > SPA-112 price looks good, so I'm wondering what the catch is. So far only one bug found: Sudden 90% fax call failure rate in one specific setup with 4 ATAs, whereas all the ATAs used by other customers continued to work fine. Problem solved with firmware 1.3.1. /Benny From rsk at gsp.org Mon Feb 11 14:57:59 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 11 Feb 2013 09:57:59 -0500 Subject: JoeJobbed, I think In-Reply-To: <15813919.5713.1360589948686.JavaMail.root@benjamin.baylink.com> References: <20130211032359.GA1900@gsp.org> <15813919.5713.1360589948686.JavaMail.root@benjamin.baylink.com> Message-ID: <20130211145759.GA3447@gsp.org> On Mon, Feb 11, 2013 at 08:39:08AM -0500, Jay Ashworth wrote: > Well, FWIW, I never use anyone's on-platform forwarding service to send > article URLs to *anywhere*, much less a mailing list, though curiously > I think I *did* put a URL about a Google KC article in a posting last > week. Don't remember if it was LAT or not. Just the three postings, > right, Rich? Yes, just the three. Now that I'm more caffeinated, I noticed the presence of X-SBRS: and X-HAT: headers in all three of those. I wonder if those are there because somebody's Cisco Ironport got its hands on those messages and did something ill-advised with them. Perhaps if the list-owners are listening in, they could check to see if there are any NANOG subscribers from mnginteractive.com or medianewsgroup.com; that might shed some light on what's happened here. ---rsk From jra at baylink.com Mon Feb 11 15:48:05 2013 From: jra at baylink.com (jra at baylink.com) Date: Mon, 11 Feb 2013 10:48:05 -0500 Subject: jra@baylink.com has shared something with you Message-ID: <57414784.191289.1360597685530.JavaMail.brainiac@lpb01.clearspring.local> http://advanced-television.com/2013/02/11/eu-shuns-future-proof-broadband-says-ftth-council/#.URkStcZ9e0I.email --- This message was sent by jra at baylink.com via http://addthis.com. Please note that AddThis does not verify email addresses. To stop receiving any emails from AddThis, please visit: http://www.addthis.com/privacy/email-opt-out?e=q1HYPdgz0RzYPdgz0XLZLtE From karlinkonig at gmail.com Mon Feb 11 15:53:25 2013 From: karlinkonig at gmail.com (=?ISO-8859-1?Q?Karlin_K=F6nig?=) Date: Mon, 11 Feb 2013 12:53:25 -0300 Subject: jra@baylink.com has shared something with you In-Reply-To: <57414784.191289.1360597685530.JavaMail.brainiac@lpb01.clearspring.local> References: <57414784.191289.1360597685530.JavaMail.brainiac@lpb01.clearspring.local> Message-ID: 2013/2/11 > > > > > http://advanced-television.com/2013/02/11/eu-shuns-future-proof-broadband-says-ftth-council/#.URkStcZ9e0I.email > > --- > This message was sent by jra at baylink.com via http://addthis.com. Please > note that AddThis does not verify email addresses. > > To stop receiving any emails from AddThis, please visit: > http://www.addthis.com/privacy/email-opt-out?e=q1HYPdgz0RzYPdgz0XLZLtE > *click* [...] "Success! You will no longer receive emails from people using the AddThis Email service to share to the following address: nanog at nanog.org" now we can only hope it works :) -- -Karlin From johnl at iecc.com Mon Feb 11 16:12:57 2013 From: johnl at iecc.com (John Levine) Date: 11 Feb 2013 16:12:57 -0000 Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: Message-ID: <20130211161257.50239.qmail@joyce.lan> >As another reference point, I really liked the sipura atas, they were my >personal favorite as far as the gear we used. I don't know how well that >translates to after the linksys takeover though, as I haven't done voice >gear in a few years. Got a Sipura SPA-1001, can't get it to work, similar issues. I found that my router had SIP ALG turned on, turned it off, now the Grandstream mostly works. Sigh. Didn't help the Sipura, though. R's, John From jra at baylink.com Mon Feb 11 16:19:54 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Feb 2013 11:19:54 -0500 (EST) Subject: Ok: this is a targetted attack Message-ID: <27912468.5751.1360599594680.JavaMail.root@benjamin.baylink.com> Clearly, someone has decided to shoot at me specifically, since this latest spam supposedly from me: ===== Received: from lpb01.clearspring.com ([206.165.250.240] helo=lpb01-a.clearspring.local) by sc1.nanog.org with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1U4vc3-000Cq4-9q for nanog at nanog.org; Mon, 11 Feb 2013 15:48:11 +0000 Received: from lpb01.clearspring.local (localhost [127.0.0.1]) by lpb01-a.clearspring.local (8.14.4/8.14.4) with ESMTP id r1BFm5bG022255 for ; Mon, 11 Feb 2013 10:48:05 -0500 Date: Mon, 11 Feb 2013 10:48:05 -0500 From: jra at baylink.com To: nanog at nanog.org Message-ID: <57414784.191289.1360597685530.JavaMail.brainiac at lpb01.clearspring.local> ===== is also about FTTH. FOR THE RECORD: I don't ever use "send this link to someone", and especially not to a mailing list; this isn't even my tenth rodeo. Cheers, -- jr 'DoS attack? What's that?' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From l-nanog at iodi.se Mon Feb 11 16:24:11 2013 From: l-nanog at iodi.se (Joseph Chin) Date: Mon, 11 Feb 2013 16:24:11 -0000 Subject: PLDT contact and overseas submarine cables in southern Philippines Message-ID: <083401ce0874$3b02f080$b108d180$@iodi.se> Hi, Anyone from PLDT on this list? I am looking for information about the availability of overseas submarine cable connectivity from Cebu and southern Philippines in general. I am researching the feasibility of locating a DR operations (e.g. contact centre) in that region. From the submarine cable maps I have seen (e.g. http://asia-pacific-map-2012.telegeography.com/ ) all the overseas cables land in the northern Philippines islands. Thanks. Regards, Joe From pashdown at xmission.com Mon Feb 11 17:44:47 2013 From: pashdown at xmission.com (Pete Ashdown) Date: Mon, 11 Feb 2013 10:44:47 -0700 Subject: Looking for US East Coast KVM Swap Message-ID: <51192E0F.7070505@xmission.com> I'm looking for a KVM guest swap on the US eastern coast for a tertiary DNS server. Must have a minimum of 1GB RAM, 4 CPUs, and be IPv6 capable. I am willing to swap the same here in Salt Lake City, Utah. Thanks in advance! From mark at amplex.net Mon Feb 11 18:25:26 2013 From: mark at amplex.net (Mark Radabaugh) Date: Mon, 11 Feb 2013 13:25:26 -0500 Subject: The 100 Gbit/s problem in your network In-Reply-To: <51190100.8030105@kenweb.org> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> <20130211122316.GA3686@pob.ytti.fi> <51190100.8030105@kenweb.org> Message-ID: <51193796.3030604@amplex.net> On 2/11/13 9:32 AM, ML wrote: > On 2/11/2013 7:23 AM, Saku Ytti wrote: >> On (2013-02-11 12:16 +0000), Aled Morris wrote: >> >>> I don't see why, as an ISP, I should carry multiple, identical, payload >>> packets for the same content. I'm more than happy to replicate them >>> closer >>> to my subscribers on behalf of the content publishers. How we do >>> this is >>> the question, i.e. what form the "multi"-"casting" takes. >>> >>> It would be nice if we could take advantage of an inherent design of >>> IP and >>> the hardware it runs on, to duplicate the actual packets in-flow as >>> near as >>> is required to the destination. >>> >>> Installing L7 content delivery boxes or caches is OK, but doesn't >>> seem as >>> efficient as an overall technical solution. >> As an overall technical solution Internet scale multicast simply does >> not >> work today. >> If it did work, then our next hurdle would be, how to get tier1 to play >> ball, they get money on bits transported, it's not in their best >> interested >> to reduce that amount. > > Any eyeball network that wants to support multicast should peer with > the content players(s) that support it. Simple! > > Just another reason to make the transit only networks even more > irrelevant. The big issue is that the customers don't want to watch simulcast content. The odds of having two customers in a reasonably sized multicast domain watching the same netflix movie at exactly the same time frame in the movie is slim. Customers want to watch on time frames of their own choosing. I don't see multicast helping at all in dealing with the situation. Mark -- Mark Radabaugh Amplex mark at amplex.net 419.837.5015 From davidpeahi at gmail.com Mon Feb 11 18:34:57 2013 From: davidpeahi at gmail.com (david peahi) Date: Mon, 11 Feb 2013 10:34:57 -0800 Subject: Micro Trenching for Fiber Optic Deployment Message-ID: Does anyone have experience in running fiber optic cable with micro-trenching techniques in areas where there is no existing asphalt or concrete roadway, just packed earth and rock? Environmental limitations do not allow for constructing an aerial power pole alignment, or underground ductbank. The distance is about 10 kM. David From jof at thejof.com Mon Feb 11 18:45:01 2013 From: jof at thejof.com (Jonathan Lassoff) Date: Mon, 11 Feb 2013 10:45:01 -0800 Subject: Micro Trenching for Fiber Optic Deployment In-Reply-To: References: Message-ID: I would think that in such a deployment scenario, microtrenching might not be the best bet. Part of the appeal (IMO) of microtrenching in existing pavement is that once filled, the pavement slab provides for some protection and rigidity. If making a small trench into packed dirt, you're much more susceptible to accidental cuts and erosion. I would suggest a Ditch Witch or similar trencher and laying some ABS/PVC conduit could give some protection from small nicks and cuts, and allow for future strands to be pulled along your path. Cheers, jof On Mon, Feb 11, 2013 at 10:34 AM, david peahi wrote: > Does anyone have experience in running fiber optic cable with > micro-trenching techniques in areas where there is no existing asphalt or > concrete roadway, just packed earth and rock? Environmental limitations do > not allow for constructing an aerial power pole alignment, or underground > ductbank. The distance is about 10 kM. > > David From me at anuragbhatia.com Mon Feb 11 18:56:50 2013 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 12 Feb 2013 00:26:50 +0530 Subject: AS 58400 announcing 118.0.0.0/8 Message-ID: <-387423935063807894@unknownmsgid> Seems like AS 58400 is announcing 118.0.0.0/8. Seems like HE's bgp.he.net is getting it in their collected data http://bgp.he.net/net/118.0.0.0/8#_bogon Overall it's just being ignored everywhere but for some strange reason my ISP in India picked less specific announcement for sometime and few sites in one of its /24 chuck for net4india went down. 118.67.249.0/24 is allocated prefix to Net4 by APNIC and they are announcing it at IXP as well as upstream transit. Anyone saw issues with this prefix ever? I hope I am not missing some test or so with prefix at University in this case. Also, as per HE's collected data, the AS path is AS28289 AS53131 AS10429 AS12956 AS701 AS6762 AS7713 AS58400 So is AS6762 Telecom Itlia not filtering their Indonesian customer ? -- (Sent from my iPad) Anurag Bhatia http://anuragbhatia.com Twitter: @anurag_bhatia Skype: anuragbhatia.com From stephen at sprunk.org Mon Feb 11 18:54:08 2013 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 11 Feb 2013 12:54:08 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <24791995.4964.1360081830800.JavaMail.root@benjamin.baylink.com> Message-ID: <51193E50.2010807@sprunk.org> On 05-Feb-13 11:37, Scott Helms wrote: > On Tue, Feb 5, 2013 at 11:30 AM, Jay Ashworth wrote: >> ----- Original Message ----- >>> From: "Scott Helms" >>>> Yes it does... It locks you into whatever is supported on the ring. >>> I don't know how I can explain this more plainly, I can (more accurately have) taken a fiber build that was created as a ring & spoke SONET system and with the same fiber plant overlaid that with GigE and ATM (further back in time) to backhaul for PON, DSL, VOIP, and direct Active Ethernet. >> "Overlaid"? Could you clarify that? > Sure, ring, hub & spoke, home run, star these are all descriptions of the physical architecture and many layer 2 technologies will happily use them all including Ethernet. To use a specific example an existing SONET ring (OC-3 to be precise) had be in service with an ILEC for more than a decade. This physical topology was a common one with a physical ring of fiber (32 strands, yes this was built back in the day) connected to Add/Drop > Multiplexers (Fujitsu IIRC) along the ring as needed to deliver 25,000 or shorter copper loops either directly from the same cabinet that ADM was in or from a subtended Digital Loop Carrier off of a spur (collapsed ring) of the ring. Now, SONET connections work off a pair of fibers, one for transmit and one for receive. To run Ethernet (initially 100mbps but now 10G) we simply lit 2 of the remaining 30 strands to overlay an Ethernet ring on top of the SONET ring. We then placed switches in the same remote cabinets we had the ADMs and DLCs and started trenching the fiber drops. ... but now you are dictating what technology is used, via the active aggregation equipment (i.e. ADMs) you installed at your nodes on the ring. Also, the fiber provider now has to maintain and upgrade that active aggregation equipment, as opposed to just patching fiber from one port to another. The point of this exercise is to design and implement a fiber plant that can support _any_ technology, including ones that haven't even been invented yet. >> Owen's assertion (and mine) is that a loop architecture *requires* active equipment, suited to the phy layer protocol, at each node. And while those loop fibers are running SONET, they can't be running anything else at the same time. > You're confounding the physical layer topology with the layer 2 protocol. You can't run SONET and Ethernet on the same physical fiber at the same time (unless you use WDM but that's confusing the discussion) but you'd never build a ring of fiber with only two strands. If you're going to dictate SONET ADMs, with a fixed set of downstream connection types, why _not_ build your ring with one pair of fiber? Hint: the fiber itself is a tiny fraction of the total cost. You're optimizing the wrong variable as a result of assuming you can predict what technology will be used 50+ years in the future. >>> This wasn't always true because we've only had 40G and 100G Ethernet for carrier networks for a few years. In the past we were limited by how big of an etherchannel network we could use for the ring. I'd also point out that the ring architecture is optimal for redundancy since you have fewer fiber bundles to get cut in the field and any cut to your ring gets routed around the ring by ERPS (http://en.wikipedia.org/wiki/ERPS) in less than 50 milliseconds. >> I infer from that continuation of your thought that you mean the second: active optical muxes out in the plant. >> >> I'm sure I've made clear why that design limits me in ways I don't want to be limited when building a fiber plant for a 50 year lifetime, but let's address your responses below. > The only limitation you have is a limited supply of total fibers (hint, this is a big reason why its cheaper to build and run). Exactly! Lay enough fiber that you don't _need_ aggregation at the local level, i.e. enough that you can patch _every_ customer connection directly to their destination of choice without any active aggregation equipment at all. Every pair of fiber can be running whatever technology the customer desires, whether that is SONET, Ethernet, or something else that hasn't even been invented yet. >> The vast majority of businesses don't want [dark fiber] at the price >> they have to pay for it now -- or more to the point, the consultants >> who do their IT don't. You have no real way, I should think, to >> extrapolate whether that will continue as prices drop, especially if >> sharply. > The vast majority of businesses don't know and don't care about HOW > their connectivity is delivered and wouldn't know the difference > between Layer 1 and Layer 2 if it punched them in the face. Almost all > businesses want INTERNET connectivity at the highest quality & speed > at the lowest cost and that's it. There are a small percentage, mainly > larger businesses, that do have special requirements, but those > special requirements very seldom include a L1 anything. Most customers will buy from a service provider, who lights the fiber. The point of dark fiber is that the service provider gets to decide how to light the fiber to said customers, allowing competition based on innovation. If the fiber owner puts active aggregation equipment in the path, though, that means the technologies available are dictated by that equipment's capabilities--and you have introduced another point of failure into the system. Sure, almost nobody asks for dark fiber today because they know it costs several orders of magnitude more than a T1 or whatever. However, if the price for dark fiber were the same (or lower), latent demand would materialize. Why would I pay through the nose for a T1 when I can light the fiber myself with 10GE for $20/mo? > If your customer base is primarily residential with a few businesses > (hospitals and schools also count here) then you'll be lucky to sell a > handful of L1 connections and some of the people who will be > interested will want it for very low bit rate (means low price too) > uses like RS-232 over fiber for managing SCADA nodes or other > telemetry pieces. Why should the fiber owner care what they use it for? It's just dark fiber, patched from one place to another, so the rental price is the same whether they light it at 10Mb/s or 10x100Gb/s. What you're missing is that in this model, _every_ connection is L1 from the fiber owner's perspective. Let service providers worry about L2 and above. > The problem I see is that you seem to think that by building the L1 > piece you're going to have ISPs that are eager to serve your > customers. If your demographics are like most small towns in the US > that just isn't very likely. Any ISP partner is going to have to build > and maintain a lot of infrastructure before they can serve the first > end user and your "no upfront engineering" is simply not true unless > you're going to configure and run MetroE and/or GPON shelves for them. > In any sharing scenario (L1, L2, or L3) the ISP is going to have to > connect to you with enough bandwidth to serve those end users as well. > How many service providers have expressed interest? Have you talked > pricing for the loops and colo space yet? Why would the ISP "have to build and maintain a lot of infrastructure"? All they need is a fiber-capable Ethernet switch in a colo to turn up their first customer. That's a lot simpler than trying to turn up their first customer via an ILEC's DSLAM, for instance. There's nothing wrong with the muni operating a L2 (or even L3) carrier of last resort, just to ensure that _some_ useful service is available to residents. However, it should (a) be priced high enough to attract competitors and (b) be a distinct entity, treated by the fiber arm as no different from any other L1 customer. None of the shenanigans like the ILECs play, where the wholesale rate to competitors is higher than the retail rate for the ILEC's own service. > Its an admirable goal, but you're never going to have CCIEs (probably > not even CCNAs) doing installs. Installation is, has been, and will in > all likelihood continue to be done by people with limited skill sets. > You building your own fiber plant and making it easier for ISPs to > connect isn't going to change that. You're missing the simplicity of dark fiber. The carrier orders a L1 circuit from a customer to their facility. The L1 provider just patches one fiber pair to another fiber pair, which can be done by a trained monkey. Then the carrier connects their own equipment to the fiber at their own facility and at the customer site, everything lights up and the spice^Wdata flows. Again, that can be done by a trained monkey. You don't need a CCIE or even a CCNA to do this. Heck, it's even simpler than what's required today for DSL, cable or satellite installers. (Note that inside wiring is a completely separate issue, and carriers _will_ have to train techs on how to do that since few are familiar with fiber, but that is an optional service they can charge extra for. The L1 provider's responsibility ends at the NIU on an outside wall, same as an ILEC's, so it's not their problem in the first place.) S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2381 bytes Desc: S/MIME Cryptographic Signature URL: From choprboy at dakotacom.net Mon Feb 11 19:01:16 2013 From: choprboy at dakotacom.net (Adrian) Date: Mon, 11 Feb 2013 12:01:16 -0700 Subject: Micro Trenching for Fiber Optic Deployment In-Reply-To: References: Message-ID: <201302111201.16632.choprboy@dakotacom.net> On Monday 11 February 2013 11:34, david peahi wrote: > Does anyone have experience in running fiber optic cable with > micro-trenching techniques in areas where there is no existing asphalt or > concrete roadway, just packed earth and rock? Environmental limitations do > not allow for constructing an aerial power pole alignment, or underground > ductbank. The distance is about 10 kM. > My best guess is that you would want to use directional boring in that case. A small hole every couple hundred meters, horizontal bore and duct pullback between holes. No personal experience here other than watching it being done for new pulls into existing developments. No need for digging up yards/sidewalks/parking lots, just a bunch of potholes at the new junction box locations and a single horizontal bore down the property line from the street, intercepting each of the potholes. Adrian From james at freedomnet.co.nz Mon Feb 11 19:06:15 2013 From: james at freedomnet.co.nz (james jones) Date: Mon, 11 Feb 2013 14:06:15 -0500 Subject: Micro Trenching for Fiber Optic Deployment In-Reply-To: References: Message-ID: In New Zealand we used a tool behind a tractor that was normally used for laying PVC pipe. So if you were using an armored cable you might be able to get with doing something similar. Here is a video. Note the exact method but you can get the idea. http://www.youtube.com/watch?v=AI0vfIIgJBM On Mon, Feb 11, 2013 at 1:34 PM, david peahi wrote: > Does anyone have experience in running fiber optic cable with > micro-trenching techniques in areas where there is no existing asphalt or > concrete roadway, just packed earth and rock? Environmental limitations do > not allow for constructing an aerial power pole alignment, or underground > ductbank. The distance is about 10 kM. > > David > From stephen at sprunk.org Mon Feb 11 19:11:29 2013 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 11 Feb 2013 13:11:29 -0600 Subject: The 100 Gbit/s problem in your network In-Reply-To: <51193796.3030604@amplex.net> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> <20130211122316.GA3686@pob.ytti.fi> <51190100.8030105@kenweb.org> <51193796.3030604@amplex.net> Message-ID: <51194261.5080702@sprunk.org> On 11-Feb-13 12:25, Mark Radabaugh wrote: > On 2/11/13 9:32 AM, ML wrote: >> Any eyeball network that wants to support multicast should peer with >> the content players(s) that support it. Simple! >> >> Just another reason to make the transit only networks even more >> irrelevant. > > The big issue is that the customers don't want to watch simulcast > content. The odds of having two customers in a reasonably sized > multicast domain watching the same netflix movie at exactly the same > time frame in the movie is slim. Customers want to watch on time > frames of their own choosing. I don't see multicast helping at all > in dealing with the situation. Multicast _is_ useful for filling the millions of DVRs out there with broadcast programs and for live events (eg. sports). A smart VOD system would have my DVR download the entire program from a local cache--and then play it locally as with anything else I watch. Those caches could be populated by multicast as well, at least for popular content. The long tail would still require some level of unicast distribution, but that is _by definition_ a tiny fraction of total demand. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2381 bytes Desc: S/MIME Cryptographic Signature URL: From jra at baylink.com Mon Feb 11 19:13:41 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Feb 2013 14:13:41 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: <51193E50.2010807@sprunk.org> Message-ID: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Stephen Sprunk" > Sure, almost nobody asks for dark fiber today because they know it costs > several orders of magnitude more than a T1 or whatever. However, if the > price for dark fiber were the same (or lower), latent demand would > materialize. Why would I pay through the nose for a T1 when I can light > the fiber myself with 10GE for $20/mo? This was part of my argument, yes. h And it even occurred to me over the weekend that this will reduce the engineering charges to get me onto the already-built backbone loops: They don't need to build to my *CO*, just to a splice at the edge of my city, and *I* can backhaul the uplinks in myself. > What you're missing is that in this model, _every_ connection is L1 from > the fiber owner's perspective. Let service providers worry about L2 and > above. In fairness to Scott, he didn't *miss* it, he simply has his "feasible" slider set to a different place than I/we do. > Why would the ISP "have to build and maintain a lot of > infrastructure"? > All they need is a fiber-capable Ethernet switch in a colo to turn up > their first customer. That's a lot simpler than trying to turn up > their first customer via an ILEC's DSLAM, for instance. Well, that means *they have to build out in my city*; I can't aggregate L1 and backhaul it to them. > There's nothing wrong with the muni operating a L2 (or even L3) carrier > of last resort, just to ensure that _some_ useful service is available > to residents. However, it should (a) be priced high enough to attract > competitors and (b) be a distinct entity, treated by the fiber arm as > no different from any other L1 customer. None of the shenanigans like the > ILECs play, where the wholesale rate to competitors is higher than the > retail rate for the ILEC's own service. That's true at L3, but at L2, my goal is to encourage *much smaller* ISPs (like the one I used to engineer in 1996, Centurion Technologies; we were profitable with about 400 dialup customers into a 40 and a 20 modem dialup bank backhauled by 512kb/s *and I would come to your house and make it work if I had to*. :-). By having the city run L2 over our L1, we can accomplish that; unlike L3, I don't believe it actually needs to be a separate company; I expect most ISP business to be at L2; L1 is mostly an accomodation to potential larger ISPs who want to do it all themselves. Or FiOS. :-) > You're missing the simplicity of dark fiber. The carrier orders a L1 > circuit from a customer to their facility. The L1 provider just patches > one fiber pair to another fiber pair, which can be done by a trained > monkey. Then the carrier connects their own equipment to the fiber at > their own facility and at the customer site, everything lights up and > the spice^Wdata flows. Again, that can be done by a trained monkey. > You don't need a CCIE or even a CCNA to do this. Heck, it's even > simpler than what's required today for DSL, cable or satellite > installers. Scott asserts that it's not that easy In The Real World; it remains to be seen whether he's right. > (Note that inside wiring is a completely separate issue, and carriers > _will_ have to train techs on how to do that since few are familiar with > fiber, but that is an optional service they can charge extra for. The > L1 provider's responsibility ends at the NIU on an outside wall, same > as an ILEC's, so it's not their problem in the first place.) The L2 might end there, too, if I decide on outside ONTs, rather than an optical jackblock inside. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From fredrik at i2b.se Mon Feb 11 19:26:42 2013 From: fredrik at i2b.se (Fredrik Holmqvist / I2B) Date: Mon, 11 Feb 2013 18:26:42 -0100 Subject: Micro Trenching for Fiber Optic Deployment In-Reply-To: References: Message-ID: Hi. You are thinking to small, you need to have space for the future: http://www.youtube.com/watch?v=10BKCsVxuIM Seriously, go with a vibrator plow or a chain trencher: Maybe a little small for a 10 km run: http://ditchwitch.com/trenchers-plows/walk-behind-vibratory-plow/410sx-vibratory-plow/ This should be good: http://ditchwitch.com/trenchers-plows/ride-on/RT45-trencher/ On 2013-02-11 18:06, james jones wrote: > In New Zealand we used a tool behind a tractor that was normally used > for > laying PVC pipe. So if you were using an armored cable you might be > able to > get with doing something similar. > > Here is a video. Note the exact method but you can get the idea. > http://www.youtube.com/watch?v=AI0vfIIgJBM > > > > > On Mon, Feb 11, 2013 at 1:34 PM, david peahi > wrote: > >> Does anyone have experience in running fiber optic cable with >> micro-trenching techniques in areas where there is no existing >> asphalt or >> concrete roadway, just packed earth and rock? Environmental >> limitations do >> not allow for constructing an aerial power pole alignment, or >> underground >> ductbank. The distance is about 10 kM. >> >> David >> -- Fredrik Holmqvist I2B (Internet 2 Business) 070-740 5033 From khelms at zcorum.com Mon Feb 11 19:49:55 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 11 Feb 2013 14:49:55 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <51193E50.2010807@sprunk.org> References: <24791995.4964.1360081830800.JavaMail.root@benjamin.baylink.com> <51193E50.2010807@sprunk.org> Message-ID: > ... but now you are dictating what technology is used, via the active > aggregation equipment (i.e. ADMs) you installed at your nodes on the > ring. Also, the fiber provider now has to maintain and upgrade that > active aggregation equipment, as opposed to just patching fiber from one > port to another. > > The point of this exercise is to design and implement a fiber plant that > can support _any_ technology, including ones that haven't even been > invented yet. > Active devices are a requirement, the only question is where they live in the CO or in the plant. Putting them in the plant is the lower cost choice in many/most deployments both in the short AND the long term. Active devices of some type will continue to be a requirement, again the only difference is where they are deployed. Swapping out one active device for another happens every day. > If you're going to dictate SONET ADMs, with a fixed set of downstream > connection types, why _not_ build your ring with one pair of fiber? > Hint: the fiber itself is a tiny fraction of the total cost. > I'm not dictating anything, especially NOT SONET. > > You're optimizing the wrong variable as a result of assuming you can > predict what technology will be used 50+ years in the future. > Designing for a fundamental change sounds like a really nice idea, except predicting the requirements for a fundamental change is impossible. Its entirely possible that in 50 years the fiber we're talking about burying isn't the current standard, fiber is no longer the access method of choice, that putting active electronics in the field becomes a requirement, or something else equally unpredictable happens. > > >>> This wasn't always true because we've only had 40G and 100G Ethernet > for carrier networks for a few years. In the past we were limited by how > big of an etherchannel network we could use for the ring. I'd also point > out that the ring architecture is optimal for redundancy since you have > fewer fiber bundles to get cut in the field and any cut to your ring gets > routed around the ring by ERPS (http://en.wikipedia.org/wiki/ERPS) in > less than 50 milliseconds. > >> I infer from that continuation of your thought that you mean the > second: active optical muxes out in the plant. > >> > >> I'm sure I've made clear why that design limits me in ways I don't want > to be limited when building a fiber plant for a 50 year lifetime, but let's > address your responses below. > > The only limitation you have is a limited supply of total fibers (hint, > this is a big reason why its cheaper to build and run). > > Exactly! Lay enough fiber that you don't _need_ aggregation at the > local level, i.e. enough that you can patch _every_ customer connection > directly to their destination of choice without any active aggregation > equipment at all. Every pair of fiber can be running whatever > technology the customer desires, whether that is SONET, Ethernet, or > something else that hasn't even been invented yet. > But that's wasteful in many/most deployments and is more expensive in the short AND the long run. Basically you're betting on a need that doesn't exist at the current rate of bandwidth growth for much more than 50 years and that's assuming that we don't get higher rates of Ethernet or that we can't run CWDM (which we already can). > > > Most customers will buy from a service provider, who lights the fiber. > The point of dark fiber is that the service provider gets to decide how > to light the fiber to said customers, allowing competition based on > innovation. If the fiber owner puts active aggregation equipment in the > path, though, that means the technologies available are dictated by that > equipment's capabilities--and you have introduced another point of > failure into the system. > The statement on reliability is false, that system WILL be there, its just a question of where it is and who owns. I'd argue that sharing at layer 1 reduces reliability because a given set of plant personnel have to deal with many more technologies. I'd also say it leads to MORE service provider lock in since not only does the business have to potentially change IP's but they may have to change (and pay for) the access device. Doing aggregation at layer 2 does limit the technology choices to businesses, but again what business is choosing something other than Ethernet today? What other technologies can you not encapsulate in a VLAN or VPLS? > > > Why should the fiber owner care what they use it for? It's just dark > fiber, patched from one place to another, so the rental price is the > same whether they light it at 10Mb/s or 10x100Gb/s. > > What you're missing is that in this model, _every_ connection is L1 from > the fiber owner's perspective. Let service providers worry about L2 and > above. > Because the plant owner ends up supporting a ton of technologies they don't know. This isn't a unsolvable problem, its simply not an economical way to run a system for most muni operators. > > > Why would the ISP "have to build and maintain a lot of infrastructure"? > All they need is a fiber-capable Ethernet switch in a colo to turn up > their first customer. That's a lot simpler than trying to turn up their > first customer via an ILEC's DSLAM, for instance. > > There's nothing wrong with the muni operating a L2 (or even L3) carrier > of last resort, just to ensure that _some_ useful service is available > to residents. However, it should (a) be priced high enough to attract > competitors and (b) be a distinct entity, treated by the fiber arm as no > different from any other L1 customer. None of the shenanigans like the > ILECs play, where the wholesale rate to competitors is higher than the > retail rate for the ILEC's own service. > The reality is simply different than this. Most muni operators struggle to work support their own systems and if you, as the muni, tell ISP A that the problem is on their side what do you think the response will be? If everything is Ethernet that becomes better, but what happens when someone runs something more exotic? PON is pretty common, but the testers for it cost several thousand dollars. What about the next technology? Who buys the testers? Who pays for tech training at the muni operator? > > > Its an admirable goal, but you're never going to have CCIEs (probably > > not even CCNAs) doing installs. Installation is, has been, and will in > > all likelihood continue to be done by people with limited skill sets. > > You building your own fiber plant and making it easier for ISPs to > > connect isn't going to change that. > > You're missing the simplicity of dark fiber. The carrier orders a L1 > circuit from a customer to their facility. The L1 provider just patches > one fiber pair to another fiber pair, which can be done by a trained > monkey. Then the carrier connects their own equipment to the fiber at > their own facility and at the customer site, everything lights up and > the spice^Wdata flows. Again, that can be done by a trained monkey. > You don't need a CCIE or even a CCNA to do this. Heck, it's even > simpler than what's required today for DSL, cable or satellite installers. > I hate to say it but if you think its this easy I have a bridge I'd like to sell you...the reality is that fiber installs, especially using multiple technologies, are hard. In many ways they're harder than reusing the existing coax or twisted pair since most homes and businesses today don't have fiber pulled to their NID much less inside the home. > > (Note that inside wiring is a completely separate issue, and carriers > _will_ have to train techs on how to do that since few are familiar with > fiber, but that is an optional service they can charge extra for. The > L1 provider's responsibility ends at the NIU on an outside wall, same as > an ILEC's, so it's not their problem in the first place.) > > If it doesn't work do you really think the muni won't get pulled in? > S > > -- > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Mon Feb 11 20:01:21 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 11 Feb 2013 15:01:21 -0500 Subject: The 100 Gbit/s problem in your network In-Reply-To: <51194261.5080702@sprunk.org> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> <20130211122316.GA3686@pob.ytti.fi> <51190100.8030105@kenweb.org> <51193796.3030604@amplex.net> <51194261.5080702@sprunk.org> Message-ID: > Multicast _is_ useful for filling the millions of DVRs out there with > broadcast programs and for live events (eg. sports). A smart VOD system > would have my DVR download the entire program from a local cache--and > then play it locally as with anything else I watch. Those caches could > be populated by multicast as well, at least for popular content. The > long tail would still require some level of unicast distribution, but > that is _by definition_ a tiny fraction of total demand. > This is true but you should probably define your network size. I don't see many/any independents doing this because of the cost of the boxes and dealing with the content providers. If you're a large MSO (say top 15) then I can see it with today's technology, but even those guys seem to be moving in other directions to get out of the provider controlled set top box model. > > S > > -- > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jra at baylink.com Mon Feb 11 20:27:27 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Feb 2013 15:27:27 -0500 (EST) Subject: The 100 Gbit/s problem in your network In-Reply-To: <51194261.5080702@sprunk.org> Message-ID: <14779190.5803.1360614447991.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Stephen Sprunk" > Multicast _is_ useful for filling the millions of DVRs out there with > broadcast programs and for live events (eg. sports). A smart VOD system > would have my DVR download the entire program from a local cache--and > then play it locally as with anything else I watch. Those caches could > be populated by multicast as well, at least for popular content. The > long tail would still require some level of unicast distribution, but > that is _by definition_ a tiny fraction of total demand. The problem with that, Steve, is that that is over the cold, dead bodies of the program producers, and by extension, their transport agents; the... I think we're calling it the Comcast decision -- the one that said that centralized Big Ass DVRs didn't violate copyright law -- made them unhappy enough about where the content was. In the final analysis, program producers are simply going to have to get over themselves, and stop thinking they can charge people multiple times for multiple formats and resolutions, frex. The *minute* a legal multicast pre-charge facility becomes available, I'm sure someone will write a module for MythTV, and that's a couple million homes, right there. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From morrowc.lists at gmail.com Mon Feb 11 20:50:50 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 11 Feb 2013 15:50:50 -0500 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> <20130211122316.GA3686@pob.ytti.fi> <51190100.8030105@kenweb.org> <51193796.3030604@amplex.net> <51194261.5080702@sprunk.org> Message-ID: On Mon, Feb 11, 2013 at 3:01 PM, Scott Helms wrote: > If you're a large MSO (say top 15) > then I can see it with today's technology, but even those guys seem to be > moving in other directions to get out of the provider controlled set top > box model. really? verizon still wants to sell the hell out of their crappy box to me... despite the fact that I say: "No, I have a tivo, it works better...." same, btw, for comcast... They all seem to want to push their own box on users :( to the extent that they tread the line on legality of pushing away 'cablecard' users :( From fredan-nanog at fredan.se Mon Feb 11 20:58:10 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Mon, 11 Feb 2013 21:58:10 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: <025C9426-F6D2-4B5E-B29F-4814E8DFAF5A@gmail.com> References: <3940444.187.1360354551648.JavaMail.art@DQT6ZQ1> <511644F6.6020900@fredan.se> <025C9426-F6D2-4B5E-B29F-4814E8DFAF5A@gmail.com> Message-ID: <51195B62.3060601@fredan.se> > These technologies are being unified by DASH in the MPEG/ISO standards bodies. Then we have to hope that we will see this implemented in Traffic Server, Squid, Varnish, so that everybody can benefit from this. -- //fredan The Last Mile Cache - http://tlmc.fredan.se From khelms at zcorum.com Mon Feb 11 20:59:28 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 11 Feb 2013 15:59:28 -0500 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> <20130211122316.GA3686@pob.ytti.fi> <51190100.8030105@kenweb.org> <51193796.3030604@amplex.net> <51194261.5080702@sprunk.org> Message-ID: Lol, I didn't say all of them were doing that yet. On Feb 11, 2013 3:50 PM, "Christopher Morrow" wrote: > On Mon, Feb 11, 2013 at 3:01 PM, Scott Helms wrote: > > If you're a large MSO (say top 15) > > then I can see it with today's technology, but even those guys seem to be > > moving in other directions to get out of the provider controlled set top > > box model. > > really? verizon still wants to sell the hell out of their crappy box > to me... despite the fact that I say: "No, I have a tivo, it works > better...." > > same, btw, for comcast... > > They all seem to want to push their own box on users :( to the extent > that they tread the line on legality of pushing away 'cablecard' users > :( > From stephen at sprunk.org Mon Feb 11 21:10:48 2013 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 11 Feb 2013 15:10:48 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> Message-ID: <51195E58.20800@sprunk.org> On 11-Feb-13 13:13, Jay Ashworth wrote: > From: "Stephen Sprunk" >> Sure, almost nobody asks for dark fiber today because they know it costs several orders of magnitude more than a T1 or whatever. However, if the price for dark fiber were the same (or lower), latent demand would materialize. Why would I pay through the nose for a T1 when I can light the fiber myself with 10GE for $20/mo? > This was part of my argument, yes. > h > And it even occurred to me over the weekend that this will reduce the engineering charges to get me onto the already-built backbone loops: > > They don't need to build to my *CO*, just to a splice at the edge of my city, and *I* can backhaul the uplinks in myself. Good point. I missed that since I was applying the same general model to the (suburban) municipality where I live, which already has no shortage of fiber _to the CO_. In the rural case originally described, reducing the "middle mile" problem helps too. >> What you're missing is that in this model, _every_ connection is L1 from the fiber owner's perspective. Let service providers worry about L2 and above. > In fairness to Scott, he didn't *miss* it, he simply has his "feasible" slider set to a different place than I/we do. I disagree; he is obsessing over how to reduce the amount of fiber, which is a tiny fraction of the total cost, and that leads him to invite all sorts of L2 problems into the picture that, for a purely L1 provider, simply would not apply. >> Why would the ISP "have to build and maintain a lot of >> infrastructure"? All they need is a fiber-capable Ethernet switch in a colo to turn up their first customer. That's a lot simpler than trying to turn up their first customer via an ILEC's DSLAM, for instance. > Well, that means *they have to build out in my city*; I can't aggregate L1 and backhaul it to them. As the saying goes, you "must be present to win." If there's _any_ fiber available to the CO, there shouldn't be much trouble getting an ISP to show up when they have ridiculously cheap access to your customer base. >> There's nothing wrong with the muni operating a L2 (or even L3) carrier of last resort, just to ensure that _some_ useful service is available to residents. However, it should (a) be priced high enough to attract competitors and (b) be a distinct entity, treated by the fiber arm as no different from any other L1 customer. None of the shenanigans like the ILECs play, where the wholesale rate to competitors is higher than the retail rate for the ILEC's own service. > That's true at L3, but at L2, my goal is to encourage *much smaller* ISPs (like the one I used to engineer in 1996, Centurion Technologies; we were profitable with about 400 dialup customers into a 40 and a 20 modem dialup bank backhauled by 512kb/s *and I would come to your house and make it work if I had to*. :-). > > By having the city run L2 over our L1, we can accomplish that; unlike L3, I don't believe it actually needs to be a separate company; I expect most ISP business to be at L2; L1 is mostly an accomodation to potential larger ISPs who want to do it all themselves. > > Or FiOS. :-) We have a philosophical disagreement here. I fully support public ownership of public ownership of "natural" monopolies, and the fiber plant itself (L1) certainly qualifies. However, running L2 (or L3) over that fiber is _not_ a natural monopoly, so I do _not_ support public ownership. At most, I could stomach a "provider of last resort" to guarantee resident access to useful services, in the IMHO unlikely event that only one (or zero) private players showed up, or a compelling need to provide some residents (eg. the elderly or indigent, schools, other public agencies, etc.) with below-cost services. >> (Note that inside wiring is a completely separate issue, and carriers _will_ have to train techs on how to do that since few are familiar with fiber, but that is an optional service they can charge extra for. The L1 provider's responsibility ends at the NIU on an outside wall, same as an ILEC's, so it's not their problem in the first place.) > The L2 might end there, too, if I decide on outside ONTs, rather than an optical jackblock inside. I think the ILECs got this part right: provide a passive NIU on the outside wall, which forms a natural demarc that the fiber owner can test to. If an L2 operator has active equipment, put it inside--and it would be part of the customer-purchased (or -leased) equipment when they turn up service. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2381 bytes Desc: S/MIME Cryptographic Signature URL: From bofh at terranova.net Mon Feb 11 21:22:41 2013 From: bofh at terranova.net (Travis Mikalson) Date: Mon, 11 Feb 2013 16:22:41 -0500 Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: <20130211161257.50239.qmail@joyce.lan> References: <20130211161257.50239.qmail@joyce.lan> Message-ID: <51196121.5080002@terranova.net> John Levine wrote: >> As another reference point, I really liked the sipura atas, they were my >> personal favorite as far as the gear we used. I don't know how well that >> translates to after the linksys takeover though, as I haven't done voice >> gear in a few years. > > Got a Sipura SPA-1001, can't get it to work, similar issues. > > I found that my router had SIP ALG turned on, turned it off, > now the Grandstream mostly works. Sigh. Didn't help the > Sipura, though. If behind NAT: On the sipura/linksys ATA, admin login, switch to advanced view, SIP tab. Ensure the following "NAT Support Parameters" are enabled. Handle VIA received, Handle VIA report, Insert VIA received, Insert VIA rport, Substitute VIA Addr, Send Resp To Src Port. I never use a STUN server, I've found it causes too much delay in answering a call. It might be in a slightly different place than described above on the newer SPA-1001/112, but the options are the same. From jimb at jsbc.cc Mon Feb 11 21:24:21 2013 From: jimb at jsbc.cc (Jim Burwell) Date: Mon, 11 Feb 2013 13:24:21 -0800 Subject: Problems for route to 92.43.96.0/21 for Comcast? Message-ID: <51196185.3050109@jsbc.cc> Can't seem to get to 92.43.96.0/21 (specifically 92.43.96.130 ... in Salzburg Austria) from Comcast Business in the Bay Area (traceroute stops close to provider edge). Works from Verizon FiOS down in LA, and a HE.net host in Fremont. Comcast folks may want to look at this. :-) - Jim From jra at baylink.com Mon Feb 11 21:24:49 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Feb 2013 16:24:49 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: <51195E58.20800@sprunk.org> Message-ID: <21944158.5821.1360617889635.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Stephen Sprunk" > > By having the city run L2 over our L1, we can accomplish that; > > unlike L3, I don't believe it actually needs to be a separate > > company; I expect most ISP business to be at L2; L1 is mostly an > > accomodation to potential larger ISPs who want to do it all > > themselves. > > > > Or FiOS. :-) > > We have a philosophical disagreement here. I fully support public > ownership of public ownership of "natural" monopolies, and the fiber > plant itself (L1) certainly qualifies. > > However, running L2 (or L3) over that fiber is _not_ a natural monopoly, > so I do _not_ support public ownership. At most, I could stomach a > "provider of last resort" to guarantee resident access to useful > services, in the IMHO unlikely event that only one (or zero) private > players showed up, or a compelling need to provide some residents (eg. > the elderly or indigent, schools, other public agencies, etc.) with > below-cost services. I dunno; I tend to buy the arguments that there is a difference; as long as the L2 access is itself sold to comers at cost, including the internal accounting between the fiber and L2 sides of the house. I don't even plan to offer quantity discounts. :-) > >> (Note that inside wiring is a completely separate issue, and > >> carriers _will_ have to train techs on how to do that since few are > >> familiar with fiber, but that is an optional service they can > >> charge extra for. The L1 provider's responsibility ends at the NIU > >> on an outside wall, same as an ILEC's, so it's not their problem in > >> the first place.) > > > The L2 might end there, too, if I decide on outside ONTs, rather > > than an optical jackblock inside. > > I think the ILECs got this part right: provide a passive NIU on the > outside wall, which forms a natural demarc that the fiber owner can test > to. If an L2 operator has active equipment, put it inside--and it would > be part of the customer-purchased (or -leased) equipment when they turn > up service. Yes, but that means the ISP has to drill holes in walls *and push fiber jumpers through them*; I'm not at all happy with that idea. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From knife at toaster.net Mon Feb 11 21:39:18 2013 From: knife at toaster.net (Sean Lazar) Date: Mon, 11 Feb 2013 13:39:18 -0800 Subject: Ok: this is a targetted attack In-Reply-To: <27912468.5751.1360599594680.JavaMail.root@benjamin.baylink.com> References: <27912468.5751.1360599594680.JavaMail.root@benjamin.baylink.com> Message-ID: <51196506.8010909@toaster.net> Jay, you need to have SPF records for your domain. This will prevent the spoofing you are seeing. http://en.wikipedia.org/wiki/Sender_Policy_Framework $ dig @8.8.8.8 baylink.com TXT ; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 baylink.com TXT ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11443 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;baylink.com. IN TXT ;; AUTHORITY SECTION: baylink.com. 194 IN SOA localhost. jra.baylink.com. 2011032901 28800 14400 86400 600 ;; Query time: 39 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Mon Feb 11 13:36:33 2013 ;; MSG SIZE rcvd: 78 Sean On 2/11/13 8:19 AM, Jay Ashworth wrote: > Clearly, someone has decided to shoot at me specifically, since this > latest spam supposedly from me: > > ===== > Received: from lpb01.clearspring.com ([206.165.250.240] > helo=lpb01-a.clearspring.local) > by sc1.nanog.org with esmtp (Exim 4.80 (FreeBSD)) > (envelope-from ) id 1U4vc3-000Cq4-9q > for nanog at nanog.org; Mon, 11 Feb 2013 15:48:11 +0000 > Received: from lpb01.clearspring.local (localhost [127.0.0.1]) > by lpb01-a.clearspring.local (8.14.4/8.14.4) with ESMTP id r1BFm5bG022255 > for ; Mon, 11 Feb 2013 10:48:05 -0500 > Date: Mon, 11 Feb 2013 10:48:05 -0500 > From: jra at baylink.com > To: nanog at nanog.org > Message-ID: <57414784.191289.1360597685530.JavaMail.brainiac at lpb01.clearspring.local> > ===== > > is also about FTTH. > > FOR THE RECORD: I don't ever use "send this link to someone", and especially > not to a mailing list; this isn't even my tenth rodeo. > > Cheers, > -- jr 'DoS attack? What's that?' a From jra at baylink.com Mon Feb 11 21:50:32 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Feb 2013 16:50:32 -0500 (EST) Subject: Ok: this is a targetted attack In-Reply-To: <51196506.8010909@toaster.net> Message-ID: <27889061.5833.1360619432354.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Sean Lazar" > Jay, you need to have SPF records for your domain. This will prevent > the spoofing you are seeing. I should in fact. But am I incorrect in thinking that since the envelope address *was not actually forged*, they wouldn't help here unless *Mailman* also processed them? (And alas, that article is itself complicated enough to tell me that I need to do actual research on the issue, so it won't happen tonight. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From rob at invaluement.com Mon Feb 11 21:51:56 2013 From: rob at invaluement.com (Rob McEwen) Date: Mon, 11 Feb 2013 16:51:56 -0500 Subject: Ok: this is a targetted attack In-Reply-To: <51196506.8010909@toaster.net> References: <27912468.5751.1360599594680.JavaMail.root@benjamin.baylink.com> <51196506.8010909@toaster.net> Message-ID: <511967FC.20700@invaluement.com> On 2/11/2013 4:39 PM, Sean Lazar wrote: > Jay, you need to have SPF records for your domain. This will prevent the > spoofing you are seeing. yep, while the purpose and effectiveness of SPF records are generally VERY overrated... yet for a situation like this, an SPF record is VERY valuable and it would be advised that you set this to a rather strict record for a period of time. (just try to account for all the various 3rd party sending scenarios your users do, like sending from a blackberry server, or e-mail forwarding, for any other situation where a legit 3rd party IP would be legitimately sending mail with a "from" address using your domain, etc.) Then again, if this is "spear phishing" or very personalized harassment, then the value of an SPF record would be somewhat uncharted territory (at least for me)... it would be interesting to see if that improves things. But, at the least, it would likely help some. -- Rob McEwen http://dnsbl.invaluement.com/ rob at invaluement.com +1 (478) 475-9032 From jneiberger at gmail.com Mon Feb 11 22:09:57 2013 From: jneiberger at gmail.com (John Neiberger) Date: Mon, 11 Feb 2013 15:09:57 -0700 Subject: Problems for route to 92.43.96.0/21 for Comcast? In-Reply-To: <51196185.3050109@jsbc.cc> References: <51196185.3050109@jsbc.cc> Message-ID: Can you provide a traceroute showing the failure? I just traced to it from my desktop inside Comcast and the trace died eleven hops after leaving our network. If your trace dies inside our network, I'll get that info to the right group to deal with it. Thanks, John On Mon, Feb 11, 2013 at 2:24 PM, Jim Burwell wrote: > Can't seem to get to 92.43.96.0/21 (specifically 92.43.96.130 ... in > Salzburg Austria) from Comcast Business in the Bay Area (traceroute > stops close to provider edge). > > Works from Verizon FiOS down in LA, and a HE.net host in Fremont. > > Comcast folks may want to look at this. :-) > > - Jim > > > From courtneysmith at comcast.net Mon Feb 11 22:30:02 2013 From: courtneysmith at comcast.net (Courtney Smith) Date: Mon, 11 Feb 2013 17:30:02 -0500 Subject: Problems for route to 92.43.96.0/21 for Comcast? In-Reply-To: References: Message-ID: <35CFC04A-5742-48FD-9BB6-CDF04AE0405B@comcast.net> On Feb 11, 2013, at 4:52 PM, nanog-request at nanog.org wrote: > ------------------------------ > > Message: 4 > Date: Mon, 11 Feb 2013 13:24:21 -0800 > From: Jim Burwell > To: nanog at nanog.org > Subject: Problems for route to 92.43.96.0/21 for Comcast? > Message-ID: <51196185.3050109 at jsbc.cc> > Content-Type: text/plain; charset=ISO-8859-1 > > Can't seem to get to 92.43.96.0/21 (specifically 92.43.96.130 ... in > Salzburg Austria) from Comcast Business in the Bay Area (traceroute > stops close to provider edge). > > Works from Verizon FiOS down in LA, and a HE.net host in Fremont. > > Comcast folks may want to look at this. :-) > > - Jim > > > Comcast has a route server at route-server.newyork.ny.ibone.comcast.net. From the view there, it appears 92.43.96.130 has been black holed. The IP holder and/or folks at AS49322 may want to contact Comcast Security folks. http://xfinity.comcast.net/constantguard/Support/Contacts route-server.newyork.ny.ibone>show ip bgp 92.43.96.130 BGP routing table entry for 92.43.96.130/32, version 1613615116 Paths: (8 available, best #7, table Default-IP-Routing-Table, not advertised to EBGP peer) Advertised to update-groups: 2 64650, (received & used) 68.86.80.11 (metric 80255) from 68.86.80.11 (68.86.1.11) Origin incomplete, metric 0, localpref 100, valid, internal Community: 64650:50001 no-export 64650, (received & used) 68.86.80.13 (metric 73765) from 68.86.80.13 (68.86.1.13) Origin incomplete, metric 0, localpref 100, valid, internal Community: 64650:50001 no-export 64650, (received & used) 68.86.80.10 (metric 79700) from 68.86.80.10 (68.86.1.10) Origin incomplete, metric 0, localpref 100, valid, internal Community: 64650:50001 no-export 64650, (received & used) 68.86.80.7 (metric 74330) from 68.86.80.7 (68.86.1.7) Origin incomplete, metric 0, localpref 100, valid, internal Community: 64650:50001 no-export 64650, (received & used) 68.86.80.12 (metric 69700) from 68.86.80.12 (68.86.1.12) Origin incomplete, metric 0, localpref 100, valid, internal Community: 64650:50001 no-export 64650, (received & used) 68.86.1.5 (metric 69635) from 68.86.80.6 (68.86.1.6) Origin incomplete, metric 0, localpref 100, valid, internal Community: 64650:50001 no-export Originator: 68.86.1.5, Cluster list: 68.86.1.6 64650, (received & used) 68.86.80.2 (metric 65535) from 68.86.80.2 (68.86.1.2) Origin incomplete, metric 0, localpref 100, valid, internal, best Community: 64650:50001 no-export 64650, (received & used) 68.86.80.0 (metric 66795) from 68.86.80.0 (68.86.1.0) Origin incomplete, metric 0, localpref 100, valid, internal Community: 64650:50001 no-export route-server.newyork.ny.ibone> route-server.newyork.ny.ibone>show ip bgp 92.43.96.131 BGP routing table entry for 92.43.96.0/21, version 1594928908 Paths: (8 available, best #2, table Default-IP-Routing-Table) Advertised to update-groups: 2 1257 8437 3248 49322, (received & used) 68.86.1.42 (metric 66845) from 68.86.80.12 (68.86.1.12) Origin IGP, metric 0, localpref 250, valid, internal Community: 7922:42 7922:3000 Originator: 68.86.1.42, Cluster list: 68.86.1.12, 68.86.1.0 1257 8437 3248 49322, (received & used) 68.86.1.46 (metric 65585) from 68.86.80.2 (68.86.1.2) Origin IGP, metric 0, localpref 250, valid, internal, best Community: 7922:46 7922:3000 Originator: 68.86.1.46, Cluster list: 68.86.1.2 1257 8437 3248 49322, (received & used) 68.86.1.42 (metric 66845) from 68.86.80.11 (68.86.1.11) Origin IGP, metric 0, localpref 250, valid, internal Community: 7922:42 7922:3000 Originator: 68.86.1.42, Cluster list: 68.86.1.11, 68.86.1.0 1257 8437 3248 49322, (received & used) 68.86.1.42 (metric 66845) from 68.86.80.13 (68.86.1.13) Origin IGP, metric 0, localpref 250, valid, internal Community: 7922:42 7922:3000 Originator: 68.86.1.42, Cluster list: 68.86.1.13, 68.86.1.0 1257 8437 3248 49322, (received & used) 68.86.1.46 (metric 65585) from 68.86.80.6 (68.86.1.6) Origin IGP, metric 0, localpref 250, valid, internal Community: 7922:46 7922:3000 Originator: 68.86.1.46, Cluster list: 68.86.1.6, 68.86.1.2 1257 8437 3248 49322, (received & used) 68.86.1.46 (metric 65585) from 68.86.80.10 (68.86.1.10) Origin IGP, metric 0, localpref 250, valid, internal Community: 7922:46 7922:3000 Originator: 68.86.1.46, Cluster list: 68.86.1.10, 68.86.1.2 1257 8437 3248 49322, (received & used) 68.86.1.42 (metric 66845) from 68.86.80.0 (68.86.1.0) Origin IGP, metric 0, localpref 250, valid, internal Community: 7922:42 7922:3000 Originator: 68.86.1.42, Cluster list: 68.86.1.0 1257 8437 3248 49322, (received & used) 68.86.1.46 (metric 65585) from 68.86.80.7 (68.86.1.7) Origin IGP, metric 0, localpref 250, valid, internal Community: 7922:46 7922:3000 Originator: 68.86.1.46, Cluster list: 68.86.1.7, 68.86.1.2 route-server.newyork.ny.ibone> () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From khelms at zcorum.com Mon Feb 11 22:37:24 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 11 Feb 2013 17:37:24 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <51195E58.20800@sprunk.org> References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> Message-ID: > > I disagree; he is obsessing over how to reduce the amount of fiber, > which is a tiny fraction of the total cost, and that leads him to invite > all sorts of L2 problems into the picture that, for a purely L1 > provider, simply would not apply. > Not at all, I've obsessing about all of the costs. IMO if you can't pay for the initial build quickly and run it efficiently then your chances of long term success are very low. L1, at scale, sharing is simply impractical for all of its philosophical benefits for more municipal network operators. That's not to say there aren't exceptions, but I can point to lots of successful muni operators who are the layer 3 provider. I can point to several that offer open access at layer 2 successfully but I don't know of any doing L1 sharing that would call it a success. Do you know of some that do? > > > We have a philosophical disagreement here. I fully support public > ownership of public ownership of "natural" monopolies, and the fiber > plant itself (L1) certainly qualifies. > > However, running L2 (or L3) over that fiber is _not_ a natural monopoly, > so I do _not_ support public ownership. At most, I could stomach a > "provider of last resort" to guarantee resident access to useful > services, in the IMHO unlikely event that only one (or zero) private > players showed up, or a compelling need to provide some residents (eg. > the elderly or indigent, schools, other public agencies, etc.) with > below-cost services. > Too many places have either no or very poor services being provided from the market for me to take this stance. I have observed that muni networks are more likely to fail than investor or privately owned operators but I don't know what causes that. I suspect that some is because in many cases the city doesn't manage it effectively but in other cases the major factor may be that the area is simply hard to run a broadband business in and even break even, which may be why no normal operator set up shop there. I think the ILECs got this part right: provide a passive NIU on the > outside wall, which forms a natural demarc that the fiber owner can test > to. If an L2 operator has active equipment, put it inside--and it would > be part of the customer-purchased (or -leased) equipment when they turn > up service. > > What ILEC is offering L1 fiber access at all? > S > > -- > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From paul4004 at gmail.com Mon Feb 11 22:41:57 2013 From: paul4004 at gmail.com (PC) Date: Mon, 11 Feb 2013 15:41:57 -0700 Subject: Ok: this is a targetted attack In-Reply-To: <511967FC.20700@invaluement.com> References: <27912468.5751.1360599594680.JavaMail.root@benjamin.baylink.com> <51196506.8010909@toaster.net> <511967FC.20700@invaluement.com> Message-ID: An SPF record will probably only add value if the receiving mail server for the nanog list uses them to restrict allowed senders for the domain. On Mon, Feb 11, 2013 at 2:51 PM, Rob McEwen wrote: > On 2/11/2013 4:39 PM, Sean Lazar wrote: > > Jay, you need to have SPF records for your domain. This will prevent the > > spoofing you are seeing. > > yep, while the purpose and effectiveness of SPF records are generally > VERY overrated... yet for a situation like this, an SPF record is VERY > valuable and it would be advised that you set this to a rather strict > record for a period of time. (just try to account for all the various > 3rd party sending scenarios your users do, like sending from a > blackberry server, or e-mail forwarding, for any other situation where a > legit 3rd party IP would be legitimately sending mail with a "from" > address using your domain, etc.) > > Then again, if this is "spear phishing" or very personalized harassment, > then the value of an SPF record would be somewhat uncharted territory > (at least for me)... it would be interesting to see if that improves > things. But, at the least, it would likely help some. > > -- > Rob McEwen > http://dnsbl.invaluement.com/ > rob at invaluement.com > +1 (478) 475-9032 > > > From khelms at zcorum.com Mon Feb 11 22:42:03 2013 From: khelms at zcorum.com (Scott Helms) Date: Mon, 11 Feb 2013 17:42:03 -0500 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> <20130211122316.GA3686@pob.ytti.fi> <51190100.8030105@kenweb.org> <51193796.3030604@amplex.net> <51194261.5080702@sprunk.org> Message-ID: I meant to add in more info, but my mobile Gmail client betrayed me. On Mon, Feb 11, 2013 at 3:59 PM, Scott Helms wrote: > Lol, I didn't say all of them were doing that yet. > On Feb 11, 2013 3:50 PM, "Christopher Morrow" > wrote: > >> On Mon, Feb 11, 2013 at 3:01 PM, Scott Helms wrote: >> > If you're a large MSO (say top 15) >> > then I can see it with today's technology, but even those guys seem to >> be >> > moving in other directions to get out of the provider controlled set top >> > box model. >> >> really? verizon still wants to sell the hell out of their crappy box >> to me... despite the fact that I say: "No, I have a tivo, it works >> better...." >> > Verizon's infrastructure is all RFoG and not IPTV so a cache wouldn't be useful. > >> same, btw, for comcast... >> >> They all seem to want to push their own box on users :( to the extent >> that they tread the line on legality of pushing away 'cablecard' users >> :( >> > Time Warner is taking a different approach: http://www.dslreports.com/shownews/Roku-and-Time-Warner-Cable-Hook-Up-122690 Also, on Comcast their new STB platform is built around IP http://xfinity.comcast.net/x1/ and while its still their box they are trying to build a development ecosystem. -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From rsk at gsp.org Mon Feb 11 23:19:43 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 11 Feb 2013 18:19:43 -0500 Subject: Ok: this is a targetted attack In-Reply-To: <51196506.8010909@toaster.net> References: <27912468.5751.1360599594680.JavaMail.root@benjamin.baylink.com> <51196506.8010909@toaster.net> Message-ID: <20130211231943.GA9323@gsp.org> On Mon, Feb 11, 2013 at 01:39:18PM -0800, Sean Lazar wrote: > Jay, you need to have SPF records for your domain. This will prevent the > spoofing you are seeing. (a) SPF is just about entirely worthless and (b) if someone really has it in for Jay and has at least minimal competence, it won't stop them -- minor variations in their tactics would suffice. ---rsk From john at nsnoc.com Mon Feb 11 23:36:52 2013 From: john at nsnoc.com (John Lyons) Date: Mon, 11 Feb 2013 23:36:52 +0000 Subject: Micro Trenching for Fiber Optic Deployment In-Reply-To: <201302111201.16632.choprboy@dakotacom.net> References: <201302111201.16632.choprboy@dakotacom.net> Message-ID: <51198094.4040305@nsnoc.com> >> concrete roadway, just packed earth and rock? Environmental limitations do >> > > My best guess is that you would want to use directional boring in that case. A > small hole every couple hundred meters, horizontal bore and duct pullback You'll struggle to get a directional drill through material that includes rock. It's two days work for this kit http://www.youtube.com/watch?v=acTBl8UKNaQ John From patrick at ianai.net Mon Feb 11 23:52:58 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 11 Feb 2013 18:52:58 -0500 Subject: The 100 Gbit/s problem in your network In-Reply-To: <51194261.5080702@sprunk.org> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> <20130211122316.GA3686@pob.ytti.fi> <51190100.8030105@kenweb.org> <51193796.3030604@amplex.net> <51194261.5080702@sprunk.org> Message-ID: On Feb 11, 2013, at 14:11 , Stephen Sprunk wrote: > On 11-Feb-13 12:25, Mark Radabaugh wrote: >> On 2/11/13 9:32 AM, ML wrote: >>> Any eyeball network that wants to support multicast should peer with >>> the content players(s) that support it. Simple! >>> >>> Just another reason to make the transit only networks even more >>> irrelevant. >> >> The big issue is that the customers don't want to watch simulcast >> content. The odds of having two customers in a reasonably sized >> multicast domain watching the same netflix movie at exactly the same >> time frame in the movie is slim. Customers want to watch on time >> frames of their own choosing. I don't see multicast helping at all >> in dealing with the situation. > > Multicast _is_ useful for filling the millions of DVRs out there with > broadcast programs and for live events (eg. sports). A smart VOD system > would have my DVR download the entire program from a local cache--and > then play it locally as with anything else I watch. Those caches could > be populated by multicast as well, at least for popular content. The > long tail would still require some level of unicast distribution, but > that is _by definition_ a tiny fraction of total demand. One of us has a different dictionary than everyone else. Assume I have 10 million movies in my library, and 10 million active users. Further assume there are 10 movies being watched by 100K users each, and 9,999,990 movies which are being watched by 1 user each. Which has more total demand, the 10 popular movies or the long tail? This doesn't mean Netflix or Hulu or iTunes or whatever has the aforementioned demand curve. But it does mean my "definition" & yours do not match. Either way, I challenge you to prove the long tail on one of the serious streaming services is a "tiny fraction" of total demand. -- TTFN, patrick From patrick at ianai.net Mon Feb 11 23:55:45 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 11 Feb 2013 18:55:45 -0500 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> <20130211122316.GA3686@pob.ytti.fi> <51190100.8030105@kenweb.org> <51193796.3030604@amplex.net> <51194261.5080702@sprunk.org> Message-ID: <28AD72EB-8E0B-4607-903D-7038BC39C782@ianai.net> On Feb 11, 2013, at 18:52 , "Patrick W. Gilmore" wrote: > On Feb 11, 2013, at 14:11 , Stephen Sprunk wrote: >> Multicast _is_ useful for filling the millions of DVRs out there with >> broadcast programs and for live events (eg. sports). A smart VOD system >> would have my DVR download the entire program from a local cache--and >> then play it locally as with anything else I watch. Those caches could >> be populated by multicast as well, at least for popular content. The >> long tail would still require some level of unicast distribution, but >> that is _by definition_ a tiny fraction of total demand. > > One of us has a different dictionary than everyone else. > > Assume I have 10 million movies in my library, and 10 million active users. Further assume there are 10 movies being watched by 100K users each, and 9,999,990 movies which are being watched by 1 user each. Obvious typo, supposed to be 8,999,990. Or you can say I have 11 million users. Whichever floats your boat. Hopefully the point is still clear, even in a crowd as pedantic as this. -- TTFN, patrick > Which has more total demand, the 10 popular movies or the long tail? > > This doesn't mean Netflix or Hulu or iTunes or whatever has the aforementioned demand curve. But it does mean my "definition" & yours do not match. > > Either way, I challenge you to prove the long tail on one of the serious streaming services is a "tiny fraction" of total demand. > > -- > TTFN, > patrick > From owen at delong.com Tue Feb 12 00:03:11 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Feb 2013 16:03:11 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: <21944158.5821.1360617889635.JavaMail.root@benjamin.baylink.com> References: <21944158.5821.1360617889635.JavaMail.root@benjamin.baylink.com> Message-ID: <8D03C627-7531-4F64-BC44-D6F018A6AD4E@delong.com> >> >> I think the ILECs got this part right: provide a passive NIU on the >> outside wall, which forms a natural demarc that the fiber owner can test >> to. If an L2 operator has active equipment, put it inside--and it would >> be part of the customer-purchased (or -leased) equipment when they turn >> up service. > > Yes, but that means the ISP has to drill holes in walls *and push fiber > jumpers through them*; I'm not at all happy with that idea. Why not? Someone will have to. Owen From stephen at sprunk.org Tue Feb 12 00:14:52 2013 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 11 Feb 2013 18:14:52 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> Message-ID: <5119897C.4010007@sprunk.org> On 11-Feb-13 16:37, Scott Helms wrote: > > I disagree; he is obsessing over how to reduce the amount of > fiber, which is a tiny fraction of the total cost, and that leads > him to invite all sorts of L2 problems into the picture that, for > a purely L1 provider, simply would not apply. > > > Not at all, I've obsessing about all of the costs. IMO if you can't > pay for the initial build quickly and run it efficiently then your > chances of long term success are very low. The fiber plant would presumably be paid for with 30-year bonds, same as any other municipal infrastructure (eg. water and sewer lines--the real "pipes"), for which interest rates are currently running around the rate of inflation. There is no need to pay them off quickly. Heck, some forward-thinking folks might even see the fiber as paying for itself through increased property values (and therefore tax revenues) and not demand that it pay back its bonds through access fees at all, just the (minimal) operating costs. L2 and above, though, is another story due to the (relatively) short depreciation cycle and higher operational costs--yet another reason they should be separated. > L1, at scale, sharing is simply impractical for all of its > philosophical benefits for more municipal network operators. That's > not to say there aren't exceptions, but I can point to lots of > successful muni operators who are the layer 3 provider. I can point > to several that offer open access at layer 2 successfully but I don't > know of any doing L1 sharing that would call it a success. Do you > know of some that do? There have been several examples cited in this thread, but I don't know how many (if any) meet both your criteria, i.e. muni _and_ open at L1. > We have a philosophical disagreement here. I fully support public > ownership of public ownership of "natural" monopolies, and the > fiber plant itself (L1) certainly qualifies. > > However, running L2 (or L3) over that fiber is _not_ a natural > monopoly, so I do _not_ support public ownership. At most, I > could stomach a "provider of last resort" to guarantee resident > access to useful services, in the IMHO unlikely event that only > one (or zero) private players showed up, or a compelling need to > provide some residents (eg. the elderly or indigent, schools, > other public agencies, etc.) with below-cost services. > > > Too many places have either no or very poor services being provided > from the market for me to take this stance. ... hence my reluctant acceptance of having a publicly-owned "provider of last resort" for L2 and L3 services. I would hate to see all that fiber go unused just because no private players showed up to the party. OTOH, it is still fundamentally different from L1. (Note that I also endorse this same model in urban and suburban markets, where there is no shortage of folks wanting to offer service--but few players with access to enough capital to put the necessary fiber in place, none of whom are interested in open access.) > I think the ILECs got this part right: provide a passive NIU on > the outside wall, which forms a natural demarc that the fiber > owner can test to. If an L2 operator has active equipment, put it > inside--and it would be part of the customer-purchased (or > -leased) equipment when they turn up service. > > > What ILEC is offering L1 fiber access at all? Think copper. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2381 bytes Desc: S/MIME Cryptographic Signature URL: From mohta at necom830.hpcl.titech.ac.jp Tue Feb 12 00:16:40 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 12 Feb 2013 09:16:40 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> Message-ID: <511989E8.1050105@necom830.hpcl.titech.ac.jp> Scott Helms wrote: > IMO if you can't pay > for the initial build quickly and run it efficiently then your chances of > long term success are very low. That is not a business model for infrastructure such as gas, electricity, CATV, water and fiber network, all of which need long term planning and investments. Anyway, as SS is less expensive than PON, there is no reason to insist on PON. Masataka Ohta From wbailey at satelliteintelligencegroup.com Tue Feb 12 00:23:52 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 12 Feb 2013 00:23:52 +0000 Subject: Muni fiber: L1 or L2? In-Reply-To: <511989E8.1050105@necom830.hpcl.titech.ac.jp> Message-ID: Nearly all of the industries you mentioned below receive some type of local or federal/government funding. If I was going to build some kind of access network, I would be banging on the .gov door asking for grants and low interest loans to help roll out broadband to remote areas. My former employer was given a TON of money (upwards of 80MM) to run Fiber across a body of water and into a microwave ring for distribution to some of the most remote customers in the world. I think that if this type of project gained any amount of traction, you would be given a check from a giant and told to enjoy your life on the beach. Just my .02 though. On 2/11/13 4:16 PM, "Masataka Ohta" wrote: >Scott Helms wrote: > >> IMO if you can't pay >> for the initial build quickly and run it efficiently then your chances >>of >> long term success are very low. > >That is not a business model for infrastructure such as gas, >electricity, CATV, water and fiber network, all of which >need long term planning and investments. > >Anyway, as SS is less expensive than PON, there is no reason to >insist on PON. > > Masataka Ohta > > From stephen at sprunk.org Tue Feb 12 00:28:33 2013 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 11 Feb 2013 18:28:33 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: <21944158.5821.1360617889635.JavaMail.root@benjamin.baylink.com> References: <21944158.5821.1360617889635.JavaMail.root@benjamin.baylink.com> Message-ID: <51198CB1.2010106@sprunk.org> On 11-Feb-13 15:24, Jay Ashworth wrote: > From: "Stephen Sprunk" >>> By having the city run L2 over our L1, we can accomplish that; unlike L3, I don't believe it actually needs to be a separate company; I expect most ISP business to be at L2; L1 is mostly an accomodation to potential larger ISPs who want to do it all themselves. >> We have a philosophical disagreement here. I fully support public ownership of public ownership of "natural" monopolies, and the fiber plant itself (L1) certainly qualifies. >> >> However, running L2 (or L3) over that fiber is _not_ a natural monopoly, so I do _not_ support public ownership. At most, I could stomach a "provider of last resort" to guarantee resident access to useful services, in the IMHO unlikely event that only one (or zero) private players showed up, or a compelling need to provide some residents (eg. the elderly or indigent, schools, other public agencies, etc.) with below-cost services. > I dunno; I tend to buy the arguments that there is a difference; as long as the L2 access is itself sold to comers at cost, including the internal accounting between the fiber and L2 sides of the house. I don't see much of a difference in that respect between L2 and L3 services. OTOH, I see a clear difference between L1 and L2/L3, as above. > I don't even plan to offer quantity discounts. :-) Good. That's one of the ways that big carriers claim to be playing by the same rules as everyone else yet get away with substantially lower costs than smaller competitors. See also: the ARIN fee schedule. >>> The L2 might end there, too, if I decide on outside ONTs, rather than an optical jackblock inside. >> I think the ILECs got this part right: provide a passive NIU on the outside wall, which forms a natural demarc that the fiber owner can test to. If an L2 operator has active equipment, put it inside--and it would be part of the customer-purchased (or -leased) equipment when they turn up service. > Yes, but that means the ISP has to drill holes in walls *and push fiber jumpers through them*; I'm not at all happy with that idea. You mean their contract installers, who do the same thing today with POTS, DSL, cable and satellite lines. It'll probably be the same people, even. OTOH, an external NIU means the fiber company can install with zero cooperation from any given property owner since no entry is required. Customers are going to need internal wiring done anyway to get it from the demarc to wherever they want their "fiber modem" installed, so you can penetrate the exterior wall at the same time--when they're in a more cooperative mood because they're going to get an immediate tangible benefit. An exterior demarc has clear troubleshooting/maintenance benefits to the fiber owner. Let the L2/L3 provider deal with inside wiring problems. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2381 bytes Desc: S/MIME Cryptographic Signature URL: From stephen at sprunk.org Tue Feb 12 00:36:13 2013 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 11 Feb 2013 18:36:13 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: References: Message-ID: <51198E7D.8050602@sprunk.org> On 11-Feb-13 18:23, Warren Bailey wrote: > On 2/11/13 4:16 PM, "Masataka Ohta" wrote: >> Scott Helms wrote: >>> IMO if you can't pay for the initial build quickly and run it efficiently then your chances of long term success are very low. >> That is not a business model for infrastructure such as gas, electricity, CATV, water and fiber network, all of which need long term planning and investments. > Nearly all of the industries you mentioned below receive some type of local or federal/government funding. If I was going to build some kind of access network, I would be banging on the .gov door asking for grants and low interest loans to help roll out broadband to remote areas. I followed the link in a recent email here to the details on the Maine Fiber Co, and their web site indicates they got started with $7M in private funding--and a $25M grant from the feds for improving service to rural areas. That radically changes the economics, just as I'm sure it did for other utilities. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2381 bytes Desc: S/MIME Cryptographic Signature URL: From wbailey at satelliteintelligencegroup.com Tue Feb 12 00:42:50 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 12 Feb 2013 00:42:50 +0000 Subject: Muni fiber: L1 or L2? In-Reply-To: <51198E7D.8050602@sprunk.org> References: , <51198E7D.8050602@sprunk.org> Message-ID: Check out GCI's Terranet project. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Stephen Sprunk Date: 02/11/2013 4:37 PM (GMT-08:00) To: nanog at nanog.org Subject: Re: Muni fiber: L1 or L2? On 11-Feb-13 18:23, Warren Bailey wrote: > On 2/11/13 4:16 PM, "Masataka Ohta" wrote: >> Scott Helms wrote: >>> IMO if you can't pay for the initial build quickly and run it efficiently then your chances of long term success are very low. >> That is not a business model for infrastructure such as gas, electricity, CATV, water and fiber network, all of which need long term planning and investments. > Nearly all of the industries you mentioned below receive some type of local or federal/government funding. If I was going to build some kind of access network, I would be banging on the .gov door asking for grants and low interest loans to help roll out broadband to remote areas. I followed the link in a recent email here to the details on the Maine Fiber Co, and their web site indicates they got started with $7M in private funding--and a $25M grant from the feds for improving service to rural areas. That radically changes the economics, just as I'm sure it did for other utilities. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From mohta at necom830.hpcl.titech.ac.jp Tue Feb 12 00:42:57 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 12 Feb 2013 09:42:57 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: <5119897C.4010007@sprunk.org> References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> Message-ID: <51199011.7050903@necom830.hpcl.titech.ac.jp> Stephen Sprunk wrote: > The fiber plant would presumably be paid for with 30-year bonds, same as > any other municipal infrastructure (eg. water and sewer lines--the real > "pipes"), for which interest rates are currently running around the rate > of inflation. There is no need to pay them off quickly. In addition, as PON is even less efficient initially when subscriber density is low and there are few subscribers to share a field splitter (unless extremely lengthy drop cables are used, which costs a lot), PON is slower to pay them off. Masataka Ohta From wbailey at satelliteintelligencegroup.com Tue Feb 12 00:47:56 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 12 Feb 2013 00:47:56 +0000 Subject: Muni fiber: L1 or L2? In-Reply-To: References: , <51198E7D.8050602@sprunk.org>, Message-ID: Though I should note that GCI was my former employer and a well respected MSO and fiber infrastructure owner/operator. They are the smartest major player I've come across, and an all around good bunch of people. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Warren Bailey Date: 02/11/2013 4:44 PM (GMT-08:00) To: Stephen Sprunk ,nanog at nanog.org Subject: Re: Muni fiber: L1 or L2? Check out GCI's Terranet project. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Stephen Sprunk Date: 02/11/2013 4:37 PM (GMT-08:00) To: nanog at nanog.org Subject: Re: Muni fiber: L1 or L2? On 11-Feb-13 18:23, Warren Bailey wrote: > On 2/11/13 4:16 PM, "Masataka Ohta" wrote: >> Scott Helms wrote: >>> IMO if you can't pay for the initial build quickly and run it efficiently then your chances of long term success are very low. >> That is not a business model for infrastructure such as gas, electricity, CATV, water and fiber network, all of which need long term planning and investments. > Nearly all of the industries you mentioned below receive some type of local or federal/government funding. If I was going to build some kind of access network, I would be banging on the .gov door asking for grants and low interest loans to help roll out broadband to remote areas. I followed the link in a recent email here to the details on the Maine Fiber Co, and their web site indicates they got started with $7M in private funding--and a $25M grant from the feds for improving service to rural areas. That radically changes the economics, just as I'm sure it did for other utilities. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From choprboy at dakotacom.net Tue Feb 12 00:57:08 2013 From: choprboy at dakotacom.net (Adrian) Date: Mon, 11 Feb 2013 17:57:08 -0700 Subject: Micro Trenching for Fiber Optic Deployment In-Reply-To: <51198094.4040305@nsnoc.com> References: <201302111201.16632.choprboy@dakotacom.net> <51198094.4040305@nsnoc.com> Message-ID: <201302111757.08786.choprboy@dakotacom.net> On Monday 11 February 2013 16:36, John Lyons wrote: > >> concrete roadway, just packed earth and rock? Environmental limitations > >> do > > > > My best guess is that you would want to use directional boring in that > > case. A small hole every couple hundred meters, horizontal bore and duct > > pullback > > You'll struggle to get a directional drill through material that > includes rock. > > It's two days work for this kit > Depends on the material, thru hard and broken rock is definitely do-able with a horizontal bore and pneumatic impact head: http://www.youtube.com/watch?v=Sbn7rgUvFuI http://www.youtube.com/watch?v=hbksxTJLgCc Horizontal boring can be done with/without drilling fluid and with/without active drilling heads, depending on the conditions. The op was rather vague on the actual requirements, so we are all left guessing... I took "packed earth and rock? Environmental limitations do not allow... underground ductbank" to mean mixed earth and no open trenching or methods that would potentially cut aquifer plains allowed. I.e. running this theoretical fiber thru a national forest, trenching 6ft down with a wheel or cable plow and cutting all the tree roots in the path would be bad... Adrian From jra at baylink.com Tue Feb 12 01:04:44 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Feb 2013 20:04:44 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: <51199011.7050903@necom830.hpcl.titech.ac.jp> Message-ID: <1824703.5857.1360631084100.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Masataka Ohta" > In addition, as PON is even less efficient initially when > subscriber density is low and there are few subscribers to > share a field splitter (unless extremely lengthy drop cables > are used, which costs a lot), PON is slower to pay them off. In case you missed it, I was the OP, and you don't have to convince *me* not to use PON; I already didn't want to. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jgreco at ns.sol.net Tue Feb 12 01:11:26 2013 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 11 Feb 2013 19:11:26 -0600 (CST) Subject: The 100 Gbit/s problem in your network In-Reply-To: Message-ID: <201302120111.r1C1BQGr090576@aurora.sol.net> > > Multicast _is_ useful for filling the millions of DVRs out there with > > broadcast programs and for live events (eg. sports). A smart VOD = > system > > would have my DVR download the entire program from a local cache--and > > then play it locally as with anything else I watch. Those caches = > could > > be populated by multicast as well, at least for popular content. The > > long tail would still require some level of unicast distribution, but > > that is _by definition_ a tiny fraction of total demand. > > One of us has a different dictionary than everyone else. > > Assume I have 10 million movies in my library, and 10 million active = > users. Further assume there are 10 movies being watched by 100K users = > each, and 9,999,990 movies which are being watched by 1 user each. > > Which has more total demand, the 10 popular movies or the long tail? > > This doesn't mean Netflix or Hulu or iTunes or whatever has the = > aforementioned demand curve. But it does mean my "definition" & yours = > do not match. > > Either way, I challenge you to prove the long tail on one of the serious = > streaming services is a "tiny fraction" of total demand. Think I have to agree with Patrick here, even if the facts were not to support him at this time. The real question is: how will video evolve? Multicast is ideally suited for small numbers of streams being delivered to wide numbers of viewers. The broadcast television distribution model worked well when only a large conglomerate could afford to produce video. Around thirty years ago, improvements in technology made it possible and reasonable for municipal cable TV systems to generate local programs. About fifteen(?) years ago, TiVo made waves with DVR's, which introduced a disruptive concept to the existing paradigm. Then ten years ago, video cameras and computer editing made it vaguely possible for a service like YouTube to evolve to serve low quality video over the low speed broadband of the day. Now? I can shoot 1080p 30fps video on my phone, edit it on a modest computer, and post it on the Internet easily. With relatively cheap hardware. But a lot of people still watch network or cable TV. And the thing I have to think is, there's going to be a battle between Big Content, who would prefer to be able to produce shows watched by lots of people (and which works for multicast), and smaller specialty content producers who will be enabled by the ease of inexpensive Internet distribution. This battle has been fought in the shadows until now, because there are not any totally awesome ways for video to be distributed to end users. Someone will invent something like InterneTiVo, which will do for Internet video what TiVo did for OTA/cable/satellite - make it easy to find the things you'd like to watch, and handle the details of getting them for you. But here's the thing. There's a growing number of people who are taking the new generation of Smart TV's and/or the smart little boxes like AppleTV, and optionally combining it with the cheap and readily available storage options (or just relying on the speed of broadband) to be able to download and watch what they want, when they want. For our household, the computation came out to: do we continue to pay DirecTV $80/month plus the $3(?) annual rate increase they had done every single year? We were happy when we started with them at $30/mo and would probably have been willing to pay that forever. But at $80, that's $960/year, and with 21 series that we watched on a semi-regular basis, which we could purchase and own for an average of less than $40 per season, that's only $840 per year, assuming that all the series put out one season per year (a false assumption these days anyways). I've talked about this to a number of people who were startled to discover that their own TV economics did not make sense. The big thing that prevents many people from doing this is just that it's so "different." Broadband providers here in the US have been reluctant to keep up with providing contemporary, industry-leading speeds, which is the other big thing to wrestle with. As network speeds increase, the value of multicast will decrease. So my point is this: to me, it really seems like worrying about video loads on networks (in terms of multicast vs unicast) is going to be a diminishing returns sort of thing: broadband networks are going to be getting faster eventually, the potential number of video sources is going to continue to grow, the diversity of what people wish to view is going to continue to grow, the number of types of video devices is going to increase, and the difficulty of causing any sort of standard implemented on a massive installed base is going to make adoption of multicast for the purpose largely irrelevant. In the long run, it's probable that nothing will change that. There will continue to be a large amount of content that could be multicast (movies, live sports, etc) but I really expect to see CDN's take on that load instead of introducing multicast to the mix... and in the meantime I hope someone invents InterneTiVo to find all the other great content. Multicast would be great, if someone would have figured out a good way to deploy it early on... but at this late point, the horse is out of the barn. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From rdobbins at arbor.net Tue Feb 12 02:36:00 2013 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 12 Feb 2013 02:36:00 +0000 Subject: The 100 Gbit/s problem in your network In-Reply-To: <201302120111.r1C1BQGr090576@aurora.sol.net> References: <201302120111.r1C1BQGr090576@aurora.sol.net> Message-ID: <87D50B4A-EE3C-425B-A2F6-0A65782AB8F6@arbor.net> On Feb 12, 2013, at 8:11 AM, Joe Greco wrote: > The real question is: how will video evolve? My guess is that most of it will become synthetic, generated programmatically from local primitives via algorithmic instructions, much in the way that multiplayer 3D FPS games handle such things today. There'll be a significant round of standards wars and development of capture systems (e.g., 'cameras', postproduction software, and so forth) which will need to happen, but I think it's inevitable. Telepresence-type systems will probably be the first to implement this sort of thing. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From tdurack at gmail.com Tue Feb 12 04:05:49 2013 From: tdurack at gmail.com (Tim Durack) Date: Mon, 11 Feb 2013 23:05:49 -0500 Subject: The 100 Gbit/s problem in your network In-Reply-To: <201302120111.r1C1BQGr090576@aurora.sol.net> References: <201302120111.r1C1BQGr090576@aurora.sol.net> Message-ID: On Mon, Feb 11, 2013 at 8:11 PM, Joe Greco wrote: > > > Multicast _is_ useful for filling the millions of DVRs out there with > > > broadcast programs and for live events (eg. sports). A smart VOD = > > system > > > would have my DVR download the entire program from a local cache--and > > > then play it locally as with anything else I watch. Those caches = > > could > > > be populated by multicast as well, at least for popular content. The > > > long tail would still require some level of unicast distribution, but > > > that is _by definition_ a tiny fraction of total demand. > > > > One of us has a different dictionary than everyone else. > > > > Assume I have 10 million movies in my library, and 10 million active = > > users. Further assume there are 10 movies being watched by 100K users = > > each, and 9,999,990 movies which are being watched by 1 user each. > > > > Which has more total demand, the 10 popular movies or the long tail? > > > > This doesn't mean Netflix or Hulu or iTunes or whatever has the = > > aforementioned demand curve. But it does mean my "definition" & yours = > > do not match. > > > > Either way, I challenge you to prove the long tail on one of the serious > = > > streaming services is a "tiny fraction" of total demand. > > Think I have to agree with Patrick here, even if the facts were not to > support him at this time. > > The real question is: how will video evolve? > > Good question. I suspect it's going to look a lot like the evolution of audio: Pandora, Grooveshark, Spotify etc. All unicast. CDN. Live sports: how was the Olympics coverage handled? Unicast. CDN. Multicast is dead. Feel free to disagree. :-) Tim:> From bross at pobox.com Tue Feb 12 04:23:33 2013 From: bross at pobox.com (Brandon Ross) Date: Mon, 11 Feb 2013 23:23:33 -0500 (EST) Subject: IPv6 support by wifi systems Message-ID: Like so many things IPv6, many of the wifi vendors seem to lack decent support for IPv6 clients. I'm not sure why I thought the situation was better than it seems to be, I guess I'm just an optimist. Anyway, what wifi vendors provide the best support for IPv6? I don't really care too much about management, but to deploy wifi in a service provider environment with IPv6, it would seem that you'd want at least: RA Guard DHCPv6 Shield (unless you just do SLAAC, I guess) IPv6 Source Address Guard Am I missing anything critical? -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From jra at baylink.com Tue Feb 12 04:33:03 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 11 Feb 2013 23:33:03 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: <7FE7FF96-2A06-4CD7-806A-785DB6DA7C54@delong.com> Message-ID: <200375.5875.1360643582960.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > On Feb 11, 2013, at 19:24 , Frank Bulk wrote: > > > Not if the ONT is mounted on the outside of the home, and just > > copper services brought into the home. > Who cares whether it's copper or fiber you push through the > penetration. What I care about is not that it's optical -- it's that *it's a patchcord*. If the ONT is per ISP, and the patchpoint is an *external* jackbox, then that thru-wall cable has to be a patchcord, not drop cable -- and the ISP field tech will have to work it. *This* *will* cause the installation reliability problems that Scott is scared of. No, either the ONT goes on the outside wall and we poke cat 6, or the drop cable goes inside to a jack box for an interior ONT. > I see no reason not to have the residential install tech that normally > extends the demarc and/or installs whatever required IW (IF?) solution > shouldn't do this. Hopefully that explains my concern. > As others have pointed out, I see good reason for the muni to operate the > L1 plant as a natural monopoly. Time and time again, we've seen that an > L1 plant requires very high density or nearly 100% market share to be > economically viable. Even in the case of very high density you still usually > only get a minute number of L1 providers and almost never more than 2 > per media type (rarely even more than 1). I honestly don't actually expect any L1 providers. But that doesn't mean I'm willing to foreclose the possibility. > However, when it comes to inside wiring (or fiber), I see no benefit to not > leaving that to the first service provider to install each residence and > possibly even being redone for every install. Some providers may use > ONTs, others may not. (ONT is, after all AE/PON specific and there's no > reason a provider couldn't drop a 24 port Gig-E switch in the colo with > a 10G uplink (or a stack of them) and sell Gig connections on regular > 1000baseFX (or LX or SX or whatever) service. Sure. > I'm not saying that's necessarily a good business model, but, I'm saying > that the muni really should avoid encumbering its L1 offering with > any additional technologies anywhere. Yup; I've been saying that right along. That's why I'd prefer to do the install as optical patch/interior, if I can sell it. Doesn't mean I don't understand why that might be troublesome. That, in turn doesn't mean I can't coil the tail in a box, and poke it through on order. > If they want to run L2 or L3 service of last resort, I have no problem with > that, but, it should be completely separate from their L1 offering and should > avoid any blurring of the lines. I believe, Owen, that that's the first time I've heard you extend that opinion to L2; everyone had me pretty much convinced that my plan to offer L2 was not likely to cause competitive pressure in the way the L3 service would. Had I misunderstood you? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jeff-kell at utc.edu Tue Feb 12 04:33:41 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Mon, 11 Feb 2013 23:33:41 -0500 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <201302120111.r1C1BQGr090576@aurora.sol.net> Message-ID: <5119C625.2000005@utc.edu> On 2/11/2013 11:05 PM, Tim Durack wrote: > Multicast is dead. Feel free to disagree. :-) Tim:> Multicast is a vendor selling point, as you essentially need a coherent end-to-end solution to get it to work PROPERLY. Of course if it does not work PROPERLY, it will still largely work, albeit inefficiently, in most cases other than routed multicast. So personally I'd love to see the multicast environment die as well :) It's so... well... decades old stuff. For cable / IPTV it may fly and scale, but there is a decided move to the on-demand model. And even with live broadcast, there's the growing DVR selling point of "pause and resume" which is buffering and unicast, just localized to the set top box. It is also the opposite of "on demand" as multicast only works on a synchronized timeline. Few if any people will demand a specific item "on demand" at the same time, or even within a reasonable time window for a buffered/staged multicast (..."this channel should be available shortly..."). You could multicast to cache boxes, but that is prone to cache hit randomization, and only useful to "pre-populate" an incident. Multicast still works for live broadcast. And can be convoluted to work in odd/mixed topologies (e.g., Octoshape... hideous thing). But working multicast requires tweaking (PIM, IGMP snooping, CGMP/etc vendor-specific L2 pruning) that makes it ugly. We had enough headaches just trying to route multicast computer imaging traffic (Ghost, SCOM, etc) that I couldn't imagine trying to extend that out into userland without some serious forklift upgrades to insure it would work at the hardware level. Locally, knock y'erself out with fingers crossed, you'll only nuke your broadcast domain, but routing it? Jeff From malayter at gmail.com Tue Feb 12 04:46:56 2013 From: malayter at gmail.com (Ryan Malayter) Date: Mon, 11 Feb 2013 22:46:56 -0600 Subject: The 100 Gbit/s problem in your network In-Reply-To: <51195B62.3060601@fredan.se> References: <3940444.187.1360354551648.JavaMail.art@DQT6ZQ1> <511644F6.6020900@fredan.se> <025C9426-F6D2-4B5E-B29F-4814E8DFAF5A@gmail.com> <51195B62.3060601@fredan.se> Message-ID: You're missing the entire point: all web caches *already* work with DASH and the proprietary HTTP chunking flavors. It's just HTTP request/response data. My employer's statistics show this to be true; we do video for compliance training and we see massive benefit from local caches in our customer's networks. We send a cache-enabled customer site each video chunk just about once on average, and their cache takes care of distribution to up to thousands of internal viewers. HTTP chunk streaming works today with Silverlight/Flash/Quicktime plugins, and there is a working prototype of the standardized DASH that use only an modern web browser and JavaScript with no plug-ins: http://dash-mse-test.appspot.com/dash-player.html From owen at delong.com Tue Feb 12 05:07:12 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Feb 2013 21:07:12 -0800 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <3940444.187.1360354551648.JavaMail.art@DQT6ZQ1> <511644F6.6020900@fredan.se> <025C9426-F6D2-4B5E-B29F-4814E8DFAF5A@gmail.com> <51195B62.3060601@fredan.se> Message-ID: <60BAC973-912D-46A8-8A9F-15BF772D0C55@delong.com> That's not the general case, however. That's a set of specialized videos where you know you will have a large number of consumers at each site viewing the same video content. Owen On Feb 11, 2013, at 20:46 , Ryan Malayter wrote: > You're missing the entire point: all web caches *already* work with > DASH and the proprietary HTTP chunking flavors. It's just HTTP request/response > data. > > My employer's statistics show this to be true; we do video for > compliance training > and we see massive benefit from local caches in our customer's > networks. We send a cache-enabled customer site each video chunk just > about once on average, and their cache takes care of distribution to > up to thousands of internal viewers. > > HTTP chunk streaming works today with Silverlight/Flash/Quicktime > plugins, and there is a working prototype of the standardized DASH > that use only an modern web browser and JavaScript with no plug-ins: > http://dash-mse-test.appspot.com/dash-player.html From owen at delong.com Tue Feb 12 05:05:07 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Feb 2013 21:05:07 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: <200375.5875.1360643582960.JavaMail.root@benjamin.baylink.com> References: <200375.5875.1360643582960.JavaMail.root@benjamin.baylink.com> Message-ID: On Feb 11, 2013, at 20:33 , Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> On Feb 11, 2013, at 19:24 , Frank Bulk wrote: >> >>> Not if the ONT is mounted on the outside of the home, and just >>> copper services brought into the home. > >> Who cares whether it's copper or fiber you push through the >> penetration. > > What I care about is not that it's optical -- it's that *it's a patchcord*. > Why? Why can't it be drop cable, or, require the technician to place the patch cord in appropriate innerduct to protect it? > If the ONT is per ISP, and the patchpoint is an *external* jackbox, then > that thru-wall cable has to be a patchcord, not drop cable -- and the > ISP field tech will have to work it. I disagree. It could be either a connectorized drop cable or a patch cord. If it's a patch cord, you could require appropriate innerduct from the external jackbox to the interior termination point. > *This* *will* cause the installation reliability problems that Scott > is scared of. So you're afraid of installers handling fiber patch cords, or, you're afraid of the patch cords not holding up after installed, or what? > No, either the ONT goes on the outside wall and we poke cat 6, or the > drop cable goes inside to a jack box for an interior ONT. Given that set of requirements, I would opt for the interior jack box. The muni should not be providing ONTs as part of it's L1 service and their L1 service should be the same product for everyone, whether it's Muni L2, Muni L3+L2, or any other service provider or set of providers doing the L2, L3, etc. There should be no active components in the muni L1 product. > >> I see no reason not to have the residential install tech that normally >> extends the demarc and/or installs whatever required IW (IF?) solution >> shouldn't do this. > > Hopefully that explains my concern. > I think I understand your concern. I'm not sure I agree with it. >> As others have pointed out, I see good reason for the muni to operate the >> L1 plant as a natural monopoly. Time and time again, we've seen that an >> L1 plant requires very high density or nearly 100% market share to be >> economically viable. Even in the case of very high density you still usually >> only get a minute number of L1 providers and almost never more than 2 >> per media type (rarely even more than 1). > > I honestly don't actually expect any L1 providers. > > But that doesn't mean I'm willing to foreclose the possibility. > You should absolutely expect L1 providers. The L2 and/or L3 services should be operated strictly as the back-up provider of last resort and/or to keep the other providers honest. >> However, when it comes to inside wiring (or fiber), I see no benefit to not >> leaving that to the first service provider to install each residence and >> possibly even being redone for every install. Some providers may use >> ONTs, others may not. (ONT is, after all AE/PON specific and there's no >> reason a provider couldn't drop a 24 port Gig-E switch in the colo with >> a 10G uplink (or a stack of them) and sell Gig connections on regular >> 1000baseFX (or LX or SX or whatever) service. > > Sure. > In case I wasn't clear... Everything beyond the jack box counts as IW (IF?) from my perspective. >> I'm not saying that's necessarily a good business model, but, I'm saying >> that the muni really should avoid encumbering its L1 offering with >> any additional technologies anywhere. > > Yup; I've been saying that right along. That's why I'd prefer to do the > install as optical patch/interior, if I can sell it. > Sure, I can understand that. The problem is when you get into the business of doing interior terminations on customer premises that aren't actually ordering service at this time, you open yourself up to a host of installation difficulties and increased costs. That's why I think the better solution is an exterior patch box with a requirement that all patches into the box be brought out inside innerduct. > Doesn't mean I don't understand why that might be troublesome. > > That, in turn doesn't mean I can't coil the tail in a box, and poke it > through on order. How do you propose to do your validation tests against fiber coiled in a box? > >> If they want to run L2 or L3 service of last resort, I have no problem with >> that, but, it should be completely separate from their L1 offering and should >> avoid any blurring of the lines. > > I believe, Owen, that that's the first time I've heard you extend that > opinion to L2; everyone had me pretty much convinced that my plan to > offer L2 was not likely to cause competitive pressure in the way the L3 > service would. I'm not sure whether offering L2 would cause competitive pressure the way L3 would, but, I do think that there is a lot of benefit and I'm becoming more convinced by some of the other arguments that clean layer separation at L1 is well worth while. > > Had I misunderstood you? > My opinion is evolving with the discussion. I was wishy washy about L2 before. I'm becoming more convinced that even if you offer it, it should have clean separation. In part because I'm realizing that it is literally viable to plonk a 6509 into the colo, get a 10G uplink and pump out a bunch of 1000base?X connections (or even 100base?X) to customers at a fairly low price per port. In this case, there wouldn't be any active L2 termination at the customer other than a media converter or router with an appropriate SFP. Owen From johnl at iecc.com Tue Feb 12 05:32:58 2013 From: johnl at iecc.com (John R. Levine) Date: 12 Feb 2013 00:32:58 -0500 Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: <51196121.5080002@terranova.net> References: <20130211161257.50239.qmail@joyce.lan> <51196121.5080002@terranova.net> Message-ID: Man is this strange: when I set my DHCP server to assign the Sipura box a fixed IP address, the VoIP box didn't work. When I let it assign an address out of the pool, it did work. Same device, same LAN, same /24 subnet, same ISC DHCP server. The Sipura has a web server, so I could confirm that in both cases the IP, subnet mask, DNS, and gateway were what the DHCP server assigned. I also have a more modern Linksys 2102 configured by a VoIP provider, same DHCP strangeness. Beats me. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly On Mon, 11 Feb 2013, Travis Mikalson wrote: > John Levine wrote: >>> As another reference point, I really liked the sipura atas, they were my >>> personal favorite as far as the gear we used. I don't know how well that >>> translates to after the linksys takeover though, as I haven't done voice >>> gear in a few years. >> >> Got a Sipura SPA-1001, can't get it to work, similar issues. >> >> I found that my router had SIP ALG turned on, turned it off, >> now the Grandstream mostly works. Sigh. Didn't help the >> Sipura, though. > > If behind NAT: On the sipura/linksys ATA, admin login, switch to > advanced view, SIP tab. Ensure the following "NAT Support Parameters" > are enabled. > Handle VIA received, Handle VIA report, Insert VIA received, Insert VIA > rport, Substitute VIA Addr, Send Resp To Src Port. I never use a STUN > server, I've found it causes too much delay in answering a call. > > It might be in a slightly different place than described above on the > newer SPA-1001/112, but the options are the same. > Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From nathana at fsr.com Tue Feb 12 05:55:38 2013 From: nathana at fsr.com (Nathan Anderson) Date: Mon, 11 Feb 2013 21:55:38 -0800 Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: References: <20130211161257.50239.qmail@joyce.lan> <51196121.5080002@terranova.net> Message-ID: On Monday, February 11, 2013 9:33 PM, John R. Levine wrote: > Man is this strange: when I set my DHCP server to assign the Sipura box a > fixed IP address, the VoIP box didn't work. When I let it assign an > address out of the pool, it did work. So what happens if you now configure the DHCP server so that the (working) IP is removed from the pool, and have the DHCP server explicitly assign it to the device instead? Does it still work? What if you turn the DHCP client off in the ATA, and try to manually assign the ATA both the fixed IP that didn't work, and the IP that does? There has to be a difference somewhere, whether it is in the DHCP payload, the way a router or NAT engine upstream is treating that IP, or *something*. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From dougb at dougbarton.us Tue Feb 12 06:06:07 2013 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 11 Feb 2013 22:06:07 -0800 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> <20130211122316.GA3686@pob.ytti.fi> <51190100.8030105@kenweb.org> <51193796.3030604@amplex.net> <51194261.5080702@sprunk.org> Message-ID: <5119DBCF.2070904@dougbarton.us> On 02/11/2013 03:52 PM, Patrick W. Gilmore wrote: > One of us has a different dictionary than everyone else. I'm not sure it's different dictionaries, I think you're talking past each other. Video on demand and broadcast are 2 totally different animals. For VOD, multicast is not a good fit, clearly. But for broadcast, it has a lot of potential. Most of the issues with people wanting to pause, rewind, etc. are already handled by modern DVRs, even with live programming. What I haven't seen yet in this discussion (and sorry if I've missed it) is the fact that every evening every broadcast network sends out hour after hour of what are essentially "live" broadcasts, in the sense that they were not available "on demand" before they were aired "on TV" that night. In addition to live broadcasts, this nightly programming is ideal for multicast, especially since nowadays most of that programming is viewed off the DVR at another time anyway. So filling up that DVR (or even watching it live) could happen over multicast just as well as it could happen over unicast. But more importantly, what's missing from this conversation is that the broadcast networks, the existing cable/satellite/etc. providers, and everyone else who has a multi-billion dollar vested interest in the way that the business is structured now would fight this tooth and nail. So we can engineer all the awesome solutions we want, they are overwhelmingly unlikely to actually happen. Doug From johnl at iecc.com Tue Feb 12 06:41:37 2013 From: johnl at iecc.com (John R. Levine) Date: 12 Feb 2013 01:41:37 -0500 Subject: Any experience with Grandstream VoIP equipment ? In-Reply-To: References: <20130211161257.50239.qmail@joyce.lan> <51196121.5080002@terranova.net> Message-ID: >> Man is this strange: when I set my DHCP server to assign the Sipura box a >> fixed IP address, the VoIP box didn't work. When I let it assign an >> address out of the pool, it did work. > > So what happens if you now configure the DHCP server so that the (working) IP is removed from the pool, and have the DHCP server explicitly assign it to the device instead? Does it still work? What if you turn the DHCP client off in the ATA, and try to manually assign the ATA both the fixed IP that didn't work, and the IP that does? Seems to work for the moment. > There has to be a difference somewhere, whether it is in the DHCP > payload, the way a router or NAT engine upstream is treating that IP, or > *something*. Most likely the DHCP payload, the NAT engine in the router isn't likely to treat one IP differently from another. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From stephen at sprunk.org Tue Feb 12 06:57:45 2013 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 12 Feb 2013 00:57:45 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: <200375.5875.1360643582960.JavaMail.root@benjamin.baylink.com> References: <200375.5875.1360643582960.JavaMail.root@benjamin.baylink.com> Message-ID: <5119E7E9.9000903@sprunk.org> On 11-Feb-13 22:33, Jay Ashworth wrote: > What I care about is not that it's optical -- it's that *it's a > patchcord*. If the ONT is per ISP, and the patchpoint is an *external* > jackbox, then that thru-wall cable has to be a patchcord, not drop > cable -- and the ISP field tech will have to work it. *This* *will* > cause the installation reliability problems that Scott is scared of. OTOH, that will be the L2+ providers' problem, and the _level_ of problems will be inversely proportional to how well they train/pay their field staff/contractors. IOW, the incentives are properly aligned with the desired behavior. If the L1 provider's responsibility ends at the jack on the outside NIU, as an ILEC's does today with copper, then you have clean separation and easy access for both initial installation and for later troubleshooting--clear benefits that help mitigate nearly all the problems Scott refers to, at least from the L1 provider's perspective. > No, either the ONT goes on the outside wall and we poke cat 6, or the > drop cable goes inside to a jack box for an interior ONT. IMHO, both of those options are unacceptable, for different reasons. > That, in turn doesn't mean I can't coil the tail in a box, and poke it > through on order. Once the tail is "poked through", though, you no longer have an exterior test point that is easily accessed. If the L2 and L1 providers are arguing over whose fault a problem is, they not only have to both show up at the same time, they also have to arrange for the property owner (or their agent) to be present as well to let them inside to continue their testing and bickering. That won't end well for either party. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2381 bytes Desc: S/MIME Cryptographic Signature URL: From jgreco at ns.sol.net Tue Feb 12 11:52:54 2013 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 12 Feb 2013 05:52:54 -0600 (CST) Subject: The 100 Gbit/s problem in your network In-Reply-To: <60BAC973-912D-46A8-8A9F-15BF772D0C55@delong.com> Message-ID: <201302121152.r1CBqslH000600@aurora.sol.net> > That's not the general case, however. That's a set of specialized videos = > where > you know you will have a large number of consumers at each site viewing = > the > same video content. Kind of like the special cases you need in order for multicast to work out, hey? So it looks like the Internet noticed we had broken its multicast and found a way to work around that damage. ;-) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From cfriacas at fccn.pt Tue Feb 12 12:01:13 2013 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 12 Feb 2013 12:01:13 +0000 (WET) Subject: Reachability problem with AS8388 [194.63.246.0/23] Message-ID: Hello, Does anyone has reachability issues with AS8388? It seems i'm unable to get packets back from 194.63.246.0/23, but only if the source is my 193.136.0.0/15 block, at AS1930. It works well from my other netblocks. I'm basically performing a (non-recursive) DNS query to DNS servers within 194.63.246.0/23. I've been trying to involve upstream providers to take a deeper look at this problem, but i haven't had any luck so far. I can't even get a traceroute back to my network from anyone at AS8388. Any suggestions? Best Regards, Carlos Fria?as From smutt at depht.com Tue Feb 12 12:09:36 2013 From: smutt at depht.com (Andrew McConachie) Date: Tue, 12 Feb 2013 13:09:36 +0100 Subject: switch 10G standalone TOR, core to DC In-Reply-To: <51139646.3030105@foobar.org> References: <5107B226.4020700@interia.pl> <5107B956.3080004@foobar.org> <51139646.3030105@foobar.org> Message-ID: On Thu, Feb 7, 2013 at 12:55 PM, Nick Hilliard wrote: > On 29/01/2013 11:58, Nick Hilliard wrote: > > None of them will do trill. The Extreme X670 and Juniper EX4550 will > both > > do VPLS, though. The X670 won't do BGP. > > this is incorrect: the ex4550 will do l2vpn/l3vpn but not vpls. The X480 > does vpls, but not the X670. > > Nick > > I normally just lurk but I thought I would post to clear up the confusion. Full disclosure, I am an Extreme Networks TAC engineer. The x450 does not support any VPLS/H-VPLS/MPLS and is discontinued. It was replaced with the x460 which does support VPLS/H-VPLS/VPWS. The x480 and x670 both support VPLS/H-VPLS/VPWS. The x460, x480 and x670 all support BGP. However, only the x480 can hold the BGP full-view in hardware. So while you can run BGP on the x460 or x670 they are really only suitable for iBGP. All switches require a Core license to run BGP and an MPLS license to run VPLS/H-VPLS/VPWS. Andrew From nick at foobar.org Tue Feb 12 12:15:25 2013 From: nick at foobar.org (Nick Hilliard) Date: Tue, 12 Feb 2013 12:15:25 +0000 Subject: switch 10G standalone TOR, core to DC In-Reply-To: References: <5107B226.4020700@interia.pl> <5107B956.3080004@foobar.org> <51139646.3030105@foobar.org> Message-ID: <511A325D.300@foobar.org> On 12/02/2013 12:09, Andrew McConachie wrote: > I normally just lurk but I thought I would post to clear up the confusion. > Full disclosure, I am an Extreme Networks TAC engineer. > > The x450 does not support any VPLS/H-VPLS/MPLS and is discontinued. It was > replaced with the x460 which does support VPLS/H-VPLS/VPWS. The x480 and > x670 both support VPLS/H-VPLS/VPWS. Thanks for the clarification on this. The data sheet on the x670 doesn't actually mention vpls: www.extremenetworks.com/libraries/products/DSSumX670_1777.pdf ... just that there is an mpls feature set license, but with no details of what it contains. Normally vendors can't tell enough about useful features like this, so in the absence of mentioning it I had assumed incorrectly that it wasn't supported on this platform. Maybe you could get the documentation updated to include this information, because this is an important feature? Nick From jgreco at ns.sol.net Tue Feb 12 13:51:31 2013 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 12 Feb 2013 07:51:31 -0600 (CST) Subject: The 100 Gbit/s problem in your network In-Reply-To: <5119DBCF.2070904@dougbarton.us> Message-ID: <201302121351.r1CDpVAQ002027@aurora.sol.net> > On 02/11/2013 03:52 PM, Patrick W. Gilmore wrote: > > One of us has a different dictionary than everyone else. > > I'm not sure it's different dictionaries, I think you're talking past > each other. > > Video on demand and broadcast are 2 totally different animals. For VOD, > multicast is not a good fit, clearly. But for broadcast, it has a lot of > potential. Most of the issues with people wanting to pause, rewind, etc. > are already handled by modern DVRs, even with live programming. > > What I haven't seen yet in this discussion (and sorry if I've missed it) > is the fact that every evening every broadcast network sends out hour > after hour of what are essentially "live" broadcasts, in the sense that > they were not available "on demand" before they were aired "on TV" that > night. In addition to live broadcasts, this nightly programming is ideal > for multicast, especially since nowadays most of that programming is > viewed off the DVR at another time anyway. So filling up that DVR (or > even watching it live) could happen over multicast just as well as it > could happen over unicast. Yes, but this basically assumes that we don't/won't see a change in their video distribution model, which is actually an unknown, rather than a given. > But more importantly, what's missing from this conversation is that the > broadcast networks, the existing cable/satellite/etc. providers, and > everyone else who has a multi-billion dollar vested interest in the way > that the business is structured now would fight this tooth and nail. So > we can engineer all the awesome solutions we want, they are > overwhelmingly unlikely to actually happen. If Big Content can figure out a way to extract money from the end user without involving middlemen like cable and satellite providers, then we'll see a shift. There is no guarantee of an ongoing business model just because that's the way it worked. Look at what's happened to Blockbuster Video, which has gone from being a multi-billion dollar company to being well on its way to irrelevance. What you're actually likely to see is a fight "tooth and nail" to ignore the signs of the coming storm, but that's not going to stop the storm, is it. It will just open the door for more visionary businesses. So, boiling everything down, the two Big Questions I see are: 1) Will throwing more bandwidth at the problem effectively allow the problem to be solved more easily than getting all the technical requirements (CPE, networks, etc.) for multicast to work? I keep having this flashback to the early days of DSL and VoIP when I would hear statements like "VoIP over the public Internet will never work" over what are essentially that day's versions of these concerns. 2) Whether or not we'll have broadcast networks sufficiently large to make it worth the investment to solve the mcast hurdles, or if maybe their entire distribution model just undergoes a tectonic shift... which is hardly unprecedented, consider the sort of shift dialtone is experiencing w.r.t. Ma Bell's POTS plant. In the meantime, the amount of non-broadcast video available as VOD continues to grow at a staggering pace. The answer appears to be that multicast would be great if everything were to remain as-is, but that seems a poor assumption. We're still in a period where multicast would be an awesome thing to have, but we do not have it, and people are successfully moving away from the "broadcast TV channel" model of video distribution, to a VOD model where they can watch what they want, when they want, without being limited to the 60 hours that their DVR happens to have queued up ("how quaint" in this age of the mighty cloud!) If you graph that all out, the picture you get shows a declining RoI for multicast. Any businessman would look at that and advise against any significant investment in solving a problem that is already on a path to self-resolution. We know how to solve 1) by throwing bandwidth at it even if we cringe at the requisite numbers today; throwing bandwidth at it is a brute force solution that makes your C and J salespeople smile. Products like the AppleTV/iPad/etc have managed to make somewhat uncomfortable marriages out of day-after-broadcast video and VOD(*). We have clever ideas about how to solve 1) with multicast, but no real world implementations that actually work at any sort of scale, and that's such a huge impediment to implementation when compared to just scaling known bandwidth and unicast delivery technologies... We also have seen, from the advent of cable TV, that the availability of new transmission opportunities leads to decreased viewership of the OTA broadcast networks, and a growing pool of alternative video to watch. But now here's the killer. The networks that could most benefit from multicast, the existing TV networks, what's the incentive for them to develop multicast technologies, something which I expect that their distribution partners would see as a further unwelcome jab at eventually cutting out the middleman? I think it has been a hard enough sell for them to support buying shows (iTunes, Amazon, whatever) but they're likely to get a lot of pushback from existing dist partners as to why another broadcast technology would be needed, when cable/satellite already have "solved" this problem and have a huge investment. (*) I would note that legacy TV, with its requirement that you be available to watch it when broadcast, or have a device handy to spool it for later viewing, is an uncomfortable marriage of content and viewer. FWIW. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From smutt at depht.com Tue Feb 12 14:07:27 2013 From: smutt at depht.com (Andrew McConachie) Date: Tue, 12 Feb 2013 15:07:27 +0100 Subject: switch 10G standalone TOR, core to DC In-Reply-To: <511A325D.300@foobar.org> References: <5107B226.4020700@interia.pl> <5107B956.3080004@foobar.org> <51139646.3030105@foobar.org> <511A325D.300@foobar.org> Message-ID: On Tue, Feb 12, 2013 at 1:15 PM, Nick Hilliard wrote: > On 12/02/2013 12:09, Andrew McConachie wrote: > > I normally just lurk but I thought I would post to clear up the > confusion. > > Full disclosure, I am an Extreme Networks TAC engineer. > > > > The x450 does not support any VPLS/H-VPLS/MPLS and is discontinued. It > was > > replaced with the x460 which does support VPLS/H-VPLS/VPWS. The x480 and > > x670 both support VPLS/H-VPLS/VPWS. > > Thanks for the clarification on this. The data sheet on the x670 doesn't > actually mention vpls: > > www.extremenetworks.com/libraries/products/DSSumX670_1777.pdf > > ... just that there is an mpls feature set license, but with no details of > what it contains. > > Normally vendors can't tell enough about useful features like this, so in > the absence of mentioning it I had assumed incorrectly that it wasn't > supported on this platform. Maybe you could get the documentation updated > to include this information, because this is an important feature? > > Nick > > > Thanks for pointing that out. Documentation folks have been alerted. For a quick comparison of all switches I like the Comparison Guide the best. http://www.extremenetworks.com/libraries/products/MSComparisonChart_1636.pdf --Andrew From fredan-nanog at fredan.se Tue Feb 12 14:14:07 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Tue, 12 Feb 2013 15:14:07 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> <20130211122316.GA3686@pob.ytti.fi> <51190100.8030105@kenweb.org> <51193796.3030604@amplex.net> <51194261.5080702@sprunk.org> Message-ID: <511A4E2F.7050901@fredan.se> Just to clarify, Patrick is right here. Assumptions: All the movies is 120 minuters long. Each movie has an average bitrate of 50 Mbit/s. (50 Mbit/s / 8 (bits) * 7 200 (2 hours) / 1000 (MB) = 45 GB). That means that the storage capacity for the movies is going to be: 10 000 000 * 45 (GB) / 1000 (TB) / 1000 (PB) = 450 PB of storage. Some of you might want to raise your hand to say that this quality of the movie is to good. Ok, so we make it 10 times smaller to 5 Mbit/s in average: 450 PB / 10 = 45 PB or 45 000 TB. If we are using 800 GB SSD drives: 45 000 TB / 0,8 TB = 56 250 SSD drives! (And we don't have any kind of backup of the content here. That need more SSD drives as well. And don't forget the power consumption). So over to the streaming part. 10 000 000 Customers watching, each with a bandwidth of 5 Mbit/s = 50 000 000 Mbit/s / 1000 (Gbit/s) = 50 000 Gbit/s. We only need 500 * 100 Gbit/s connections to solve this kind of demand. For each ISP around the world with 10 000 000 Millions of customers. Will TLMC be able to solve the 100k users watching 10 different movies? Yes. Will TLMC be able to solve the other 10 Million watching 10 Million movies. No, since your network can not handle this kind of load in the first place. > One of us has a different dictionary than everyone else. > > Assume I have 10 million movies in my library, and 10 million active users. Further assume there are 10 movies being watched by 100K users each, and 9,999,990 movies which are being watched by 1 user each. > > Which has more total demand, the 10 popular movies or the long tail? > > This doesn't mean Netflix or Hulu or iTunes or whatever has the aforementioned demand curve. But it does mean my "definition" & yours do not match. > > Either way, I challenge you to prove the long tail on one of the serious streaming services is a "tiny fraction" of total demand. > -- //fredan The Last Mile Cache - http://tlmc.fredan.se From piotr.1234 at interia.pl Tue Feb 12 14:23:43 2013 From: piotr.1234 at interia.pl (Piotr) Date: Tue, 12 Feb 2013 15:23:43 +0100 Subject: switch 10G standalone TOR, core to DC In-Reply-To: References: <5107B226.4020700@interia.pl>, , <5108F643.80504@interia.pl> <51090B30.6070504@xip.at>, <51090F6F.1050601@interia.pl>, <5113E0D6.7050108@gmx.com> Message-ID: <511A506F.2050603@interia.pl> W dniu 2013-02-07 22:54, Sergey Marunich pisze: > Hi Peter, > http://www.aristanetworks.com/media/system/pdf/Datasheets/7050S_Datasheet.pdf > Arista 7050S-64 48 x 10GE + 4 x 40 GE, price around 25k$ in gpl. > Large buffers, supports MLAG, DCB, wire-speed L2/L3 (OSPF,BGP), but doesn't have any kind of TRILL implementation. from documentation: shared 9 MB packet buffer pool that is allocated dynamically to ports that are congested 9MB is a standard size of port buffers.. regards, Piotr From ikiris at gmail.com Tue Feb 12 15:02:57 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 12 Feb 2013 09:02:57 -0600 Subject: The 100 Gbit/s problem in your network In-Reply-To: <511A4E2F.7050901@fredan.se> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> <20130211122316.GA3686@pob.ytti.fi> <51190100.8030105@kenweb.org> <51193796.3030604@amplex.net> <51194261.5080702@sprunk.org> <511A4E2F.7050901@fredan.se> Message-ID: You could make far more connecting your awesome prediction software to the stock market, than using it to figure out what specific content people are going to watch to cache before they decide to watch it... And if you don't have said awesome software, then how do you propose to limit the bandwidth need for the cache so you aren't burning more bandwidth than your hit rate, which is what everyone is trying to ask you (or more accurately, explain to you)? And if you're just being a plain local cache at the house/mdf, then what exactly makes it better than any other cache that doesn't get enough hit rate to be worth it to begin with at said house/mdf? -Blake On Tue, Feb 12, 2013 at 8:14 AM, fredrik danerklint wrote: > Just to clarify, Patrick is right here. > > > Assumptions: > > All the movies is 120 minuters long. Each movie has an average bitrate of > 50 Mbit/s. > > (50 Mbit/s / 8 (bits) * 7 200 (2 hours) / 1000 (MB) = 45 GB). > > > That means that the storage capacity for the movies is going to be: > > 10 000 000 * 45 (GB) / 1000 (TB) / 1000 (PB) = 450 PB of storage. > > > Some of you might want to raise your hand to say that this quality of > the movie is to good. Ok, so we make it 10 times smaller to 5 Mbit/s > in average: > > 450 PB / 10 = 45 PB or 45 000 TB. > > > If we are using 800 GB SSD drives: > > 45 000 TB / 0,8 TB = 56 250 SSD drives! > > (And we don't have any kind of backup of the content here. That need > more SSD drives as well. And don't forget the power consumption). > > > So over to the streaming part. > > 10 000 000 Customers watching, each with a bandwidth of 5 Mbit/s = > 50 000 000 Mbit/s / 1000 (Gbit/s) = 50 000 Gbit/s. > > > We only need 500 * 100 Gbit/s connections to solve this kind of > demand. For each ISP around the world with 10 000 000 Millions > of customers. > > > Will TLMC be able to solve the 100k users watching 10 different > movies? Yes. > > Will TLMC be able to solve the other 10 Million watching 10 Million > movies. No, since your network can not handle this kind of load in > the first place. > > > > > > > One of us has a different dictionary than everyone else. >> >> Assume I have 10 million movies in my library, and 10 million active >> users. Further assume there are 10 movies being watched by 100K users >> each, and 9,999,990 movies which are being watched by 1 user each. >> >> Which has more total demand, the 10 popular movies or the long tail? >> >> This doesn't mean Netflix or Hulu or iTunes or whatever has the >> aforementioned demand curve. But it does mean my "definition" & yours do >> not match. >> >> Either way, I challenge you to prove the long tail on one of the serious >> streaming services is a "tiny fraction" of total demand. >> >> > > -- > //fredan > > The Last Mile Cache - http://tlmc.fredan.se > > From neil at tonal.clara.co.uk Tue Feb 12 15:32:11 2013 From: neil at tonal.clara.co.uk (Neil Harris) Date: Tue, 12 Feb 2013 15:32:11 +0000 Subject: The 100 Gbit/s problem in your network In-Reply-To: <511A4E2F.7050901@fredan.se> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> <20130211122316.GA3686@pob.ytti.fi> <51190100.8030105@kenweb.org> <51193796.3030604@amplex.net> <51194261.5080702@sprunk.org> <511A4E2F.7050901@fredan.se> Message-ID: <511A607B.8040007@tonal.clara.co.uk> On 12/02/13 14:14, fredrik danerklint wrote: > Just to clarify, Patrick is right here. > > > Assumptions: > > All the movies is 120 minuters long. Each movie has an average bitrate > of 50 Mbit/s. > > (50 Mbit/s / 8 (bits) * 7 200 (2 hours) / 1000 (MB) = 45 GB). > > > That means that the storage capacity for the movies is going to be: > > 10 000 000 * 45 (GB) / 1000 (TB) / 1000 (PB) = 450 PB of storage. > > > Some of you might want to raise your hand to say that this quality of > the movie is to good. Ok, so we make it 10 times smaller to 5 Mbit/s > in average: > > 450 PB / 10 = 45 PB or 45 000 TB. > > > If we are using 800 GB SSD drives: > > 45 000 TB / 0,8 TB = 56 250 SSD drives! > > (And we don't have any kind of backup of the content here. That need > more SSD drives as well. And don't forget the power consumption). > > > So over to the streaming part. > > 10 000 000 Customers watching, each with a bandwidth of 5 Mbit/s = > 50 000 000 Mbit/s / 1000 (Gbit/s) = 50 000 Gbit/s. > > > We only need 500 * 100 Gbit/s connections to solve this kind of > demand. For each ISP around the world with 10 000 000 Millions > of customers. > > > Will TLMC be able to solve the 100k users watching 10 different > movies? Yes. > > Will TLMC be able to solve the other 10 Million watching 10 Million > movies. No, since your network can not handle this kind of load in > the first place. > > Fortunately, we have some fascinating recent research on exactly this: http://www.land.ufrj.br/~classes/coppe-redes-2012/trabalho/youtube_imc07.pdf -- N. From shortdudey123 at gmail.com Tue Feb 12 15:36:47 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Tue, 12 Feb 2013 09:36:47 -0600 Subject: Reachability problem with AS8388 [194.63.246.0/23] In-Reply-To: References: Message-ID: Can you provide the traceroute? -Grant On Tue, Feb 12, 2013 at 6:01 AM, Carlos Friacas wrote: > > Hello, > > Does anyone has reachability issues with AS8388? > > It seems i'm unable to get packets back from 194.63.246.0/23, but only if > the source is my 193.136.0.0/15 block, at AS1930. It works well from my > other netblocks. I'm basically performing a (non-recursive) DNS query to > DNS servers within 194.63.246.0/23. > > I've been trying to involve upstream providers to take a deeper look at > this problem, but i haven't had any luck so far. I can't even get a > traceroute back to my network from anyone at AS8388. > > Any suggestions? > > > Best Regards, > Carlos Fria?as > From nick at foobar.org Tue Feb 12 15:45:25 2013 From: nick at foobar.org (Nick Hilliard) Date: Tue, 12 Feb 2013 15:45:25 +0000 Subject: switch 10G standalone TOR, core to DC In-Reply-To: <511A506F.2050603@interia.pl> References: <5107B226.4020700@interia.pl>, , <5108F643.80504@interia.pl> <51090B30.6070504@xip.at>, <51090F6F.1050601@interia.pl>, <5113E0D6.7050108@gmx.com> <511A506F.2050603@interia.pl> Message-ID: <511A6395.1060507@foobar.org> On 12/02/2013 14:23, Piotr wrote: > shared 9 MB packet buffer > pool that is allocated dynamically to ports that are congested > > 9MB is a standard size of port buffers.. That's pretty standard for a cut-thru ToR switch of this style. Cut-thru switches generally need a lot less packet buffer space than store-n-forward switches. Also, ToR boxes tend not to have complex qos requirements. Having said that, you need to be careful deploying small-buffer boxes. If you're not careful, you will end up with bad packet loss. Nick From thegameiam at yahoo.com Tue Feb 12 15:47:21 2013 From: thegameiam at yahoo.com (David Barak) Date: Tue, 12 Feb 2013 07:47:21 -0800 (PST) Subject: The 100 Gbit/s problem in your network In-Reply-To: <201302121152.r1CBqslH000600@aurora.sol.net> Message-ID: <1360684041.95669.YahooMailClassic@web31806.mail.mud.yahoo.com> --- On Tue, 2/12/13, Joe Greco wrote: > Kind of like the special cases you need in order for > multicast to > work out, hey? A good example of (growing!) corner-case wide-area multicast is real-time remote sensor networking, although that does not tend to natively cross ISPs due to the breakage previously identified. The traffic flows there are basically backwards from the IPTV / video flows, so they don't contribute bandwidth problems nearly as much as they do (s,g) state problems. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From cfriacas at fccn.pt Tue Feb 12 15:52:52 2013 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 12 Feb 2013 15:52:52 +0000 (WET) Subject: Reachability problem with AS8388 [194.63.246.0/23] In-Reply-To: References: Message-ID: On Tue, 12 Feb 2013, Grant Ridder wrote: Hello, > Can you provide the traceroute? Yes. Please see below. We were already told they drop icmp packets making the traceroute useless beyond 62.38.94.98 I strongly suspect there is an issue only on the return path, but i would need a traceroute originated at the other end so i can be sure and understand where the packets (tcp & udp) are exactly being dropped. Regards, Carlos Fria?as # traceroute 194.63.247.20 traceroute to 194.63.247.20 (194.63.247.20), 30 hops max, 60 byte packets 1 193.136.2.29 (193.136.2.29) 0.278 ms 0.256 ms 0.241 ms 2 ROUTER4.10GE.Lisboa.fccn.pt (193.137.0.20) 0.294 ms 0.282 ms 0.269 ms 3 fccn.mx2.lis.pt.geant.net (62.40.124.97) 0.332 ms 0.320 ms 0.337 ms 4 xe-2-3-0.rt1.mad.es.geant.net (62.40.98.107) 12.650 ms 12.725 ms 12.641 ms 5 as2.rt1.gen.ch.geant2.net (62.40.112.25) 34.808 ms 34.791 ms 34.863 ms 6 ae3.rt1.fra.de.geant2.net (62.40.112.161) 43.062 ms 43.022 ms 43.010 ms 7 te0-7-0-5.ccr22.fra03.atlas.cogentco.com (149.6.42.73) 43.724 ms 43.808 ms 43.889 ms 8 te0-0-0-2.ccr22.ams03.atlas.cogentco.com (130.117.3.89) 50.106 ms te0-2-0-2.ccr22.ams03.atlas.cogentco.com (130.117.1.65) 50.240 ms te0-0-0-2.ccr22.ams03.atlas.cogentco.com (130.117.3.89) 50.114 ms 9 te0-2-0-0.ccr22.lon13.atlas.cogentco.com (130.117.1.170) 55.518 ms te0-0-0-0.ccr22.lon13.atlas.cogentco.com (130.117.1.225) 55.453 ms te0-5-0-0.ccr22.lon13.atlas.cogentco.com (154.54.61.154) 55.689 ms 10 te0-1-0-0.ccr22.lon01.atlas.cogentco.com (154.54.57.178) 55.570 ms te0-4-0-0.ccr22.lon01.atlas.cogentco.com (130.117.0.205) 55.452 ms te0-2-0-0.ccr22.lon01.atlas.cogentco.com (154.54.57.174) 55.481 ms 11 te2-1.mag02.lon01.atlas.cogentco.com (154.54.74.114) 55.439 ms 55.356 ms 55.342 ms 12 149.6.187.234 (149.6.187.234) 55.370 ms 55.451 ms 55.493 ms 13 POS00-07-00-03.med00.brd.hol.gr (62.38.36.13) 127.954 ms * 127.106 ms 14 tengigaeth00-01-00-02.med00.ccr.hol.gr (62.38.97.29) 136.321 ms * * 15 tengigaeth00-07-00-00.med00.csr.hol.gr (62.38.94.98) 125.525 ms 125.519 ms 125.584 ms 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * > -Grant > > On Tue, Feb 12, 2013 at 6:01 AM, Carlos Friacas wrote: > > Hello, > > Does anyone has reachability issues with AS8388? > > It seems i'm unable to get packets back from 194.63.246.0/23, but only if the source is my 193.136.0.0/15 block, at > AS1930. It works well from my other netblocks. I'm basically performing a (non-recursive) DNS query to DNS servers > within 194.63.246.0/23. > > I've been trying to involve upstream providers to take a deeper look at this problem, but i haven't had any luck so > far. I can't even get a traceroute back to my network from anyone at AS8388. > > Any suggestions? > > > Best Regards, > Carlos Fria?as > > > > From shortdudey123 at gmail.com Tue Feb 12 16:09:37 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Tue, 12 Feb 2013 10:09:37 -0600 Subject: Reachability problem with AS8388 [194.63.246.0/23] In-Reply-To: References: Message-ID: Traceroute to the same address from a TWTC circuit in Milwaukee, Wi drops in the same network as you. 7 7 ms 6 ms 7 ms xe-7-3-0.edge4.Chicago3.Level3.net[4.53.98.45] 8 114 ms 110 ms 113 ms vlan52.ebr2.Chicago2.Level3.net[4.69.138.190] 9 112 ms 110 ms 111 ms ae-6-6.ebr2.Washington12.Level3.net[4.69.148.145] 10 113 ms 113 ms 114 ms ae-5-5.ebr2.Washington1.Level3.net[4.69.143.221] 11 113 ms 109 ms 109 ms ae-43-43.ebr2.Paris1.Level3.net[4.69.137.57] 12 111 ms 111 ms 115 ms ae-45-45.ebr1.Frankfurt1.Level3.net[4.69.143.133] 13 111 ms 111 ms 111 ms ae-81-81.csw3.Frankfurt1.Level3.net[4.69.140.10] 14 110 ms 107 ms 109 ms ae-3-80.edge1.Frankfurt1.Level3.net[4.69.154.133] 15 190 ms 189 ms 183 ms 212.162.9.6 16 * * * Request timed out. 17 176 ms 169 ms 169 ms tengigaeth00-00-00-00.adr00.csr.hol.gr[62.38.93.98] 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 ^C On Tue, Feb 12, 2013 at 9:52 AM, Carlos Friacas wrote: > > > On Tue, 12 Feb 2013, Grant Ridder wrote: > > Hello, > > > Can you provide the traceroute? >> > > Yes. Please see below. We were already told they drop icmp packets making > the traceroute useless beyond 62.38.94.98 > > I strongly suspect there is an issue only on the return path, but i would > need a traceroute originated at the other end so i can be sure and > understand where the packets (tcp & udp) are exactly being dropped. > > > Regards, > Carlos Fria?as > > > # traceroute 194.63.247.20 > traceroute to 194.63.247.20 (194.63.247.20), 30 hops max, 60 byte packets > 1 193.136.2.29 (193.136.2.29) 0.278 ms 0.256 ms 0.241 ms > 2 ROUTER4.10GE.Lisboa.fccn.pt (193.137.0.20) 0.294 ms 0.282 ms 0.269 > ms > 3 fccn.mx2.lis.pt.geant.net (62.40.124.97) 0.332 ms 0.320 ms 0.337 ms > 4 xe-2-3-0.rt1.mad.es.geant.net (62.40.98.107) 12.650 ms 12.725 ms > 12.641 ms > 5 as2.rt1.gen.ch.geant2.net (62.40.112.25) 34.808 ms 34.791 ms > 34.863 ms > 6 ae3.rt1.fra.de.geant2.net (62.40.112.161) 43.062 ms 43.022 ms > 43.010 ms > 7 te0-7-0-5.ccr22.fra03.atlas.**cogentco.com(149.6.42.73) 43.724 ms 43.808 ms 43.889 ms > 8 te0-0-0-2.ccr22.ams03.atlas.**cogentco.com(130.117.3.89) 50.106 ms > te0-2-0-2.ccr22.ams03.atlas.**cogentco.com(130.117.1.65) 50.240 ms > te0-0-0-2.ccr22.ams03.atlas.**cogentco.com(130.117.3.89) 50.114 ms > 9 te0-2-0-0.ccr22.lon13.atlas.**cogentco.com(130.117.1.170) 55.518 ms > te0-0-0-0.ccr22.lon13.atlas.**cogentco.com(130.117.1.225) 55.453 ms > te0-5-0-0.ccr22.lon13.atlas.**cogentco.com(154.54.61.154) 55.689 ms > 10 te0-1-0-0.ccr22.lon01.atlas.**cogentco.com(154.54.57.178) 55.570 ms > te0-4-0-0.ccr22.lon01.atlas.**cogentco.com(130.117.0.205) 55.452 ms > te0-2-0-0.ccr22.lon01.atlas.**cogentco.com(154.54.57.174) 55.481 ms > 11 te2-1.mag02.lon01.atlas.**cogentco.com(154.54.74.114) 55.439 ms 55.356 ms 55.342 ms > 12 149.6.187.234 (149.6.187.234) 55.370 ms 55.451 ms 55.493 ms > 13 POS00-07-00-03.med00.brd.hol.**gr(62.38.36.13) 127.954 ms * 127.106 ms > 14 tengigaeth00-01-00-02.med00.**ccr.hol.gr(62.38.97.29) 136.321 ms * * > 15 tengigaeth00-07-00-00.med00.**csr.hol.gr(62.38.94.98) 125.525 ms 125.519 ms 125.584 ms > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > > > > > > -Grant >> >> On Tue, Feb 12, 2013 at 6:01 AM, Carlos Friacas wrote: >> >> Hello, >> >> Does anyone has reachability issues with AS8388? >> >> It seems i'm unable to get packets back from 194.63.246.0/23, but >> only if the source is my 193.136.0.0/15 block, at >> AS1930. It works well from my other netblocks. I'm basically >> performing a (non-recursive) DNS query to DNS servers >> within 194.63.246.0/23. >> >> I've been trying to involve upstream providers to take a deeper >> look at this problem, but i haven't had any luck so >> far. I can't even get a traceroute back to my network from anyone >> at AS8388. >> >> Any suggestions? >> >> >> Best Regards, >> Carlos Fria?as >> >> >> >> From fredan-nanog at fredan.se Tue Feb 12 16:17:50 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Tue, 12 Feb 2013 17:17:50 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> <20130211122316.GA3686@pob.ytti.fi> <51190100.8030105@kenweb.org> <51193796.3030604@amplex.net> <51194261.5080702@sprunk.org> <511A4E2F.7050901@fredan.se> Message-ID: <511A6B2E.3090907@fredan.se> > And if you don't have said awesome software, then how do you propose to > limit the bandwidth need for the cache so you aren't burning more bandwidth > than your hit rate, which is what everyone is trying to ask you (or more > accurately, explain to you)? Without the concept of TLMC, I don't know. I do think that I need to explain how TLMC works. (please see the file 'tlmc-20130207-r1.tar.gz' as well). This is going to be a long answer. We are trying to get the url: http://static.tlmc.csp.example/hello_world.html First the DNS needs to get the IP address of 'static.tlmc.csp.example', so we have something to connect to. What we would like to have is the IP address of a cache server at the ISP. The CSP has a 'database' of which ISP:s around the world do participate in TLMC. This information is stored in a remark field in the IRR. We do know of where the origin the DNS request is coming from, so we answer that request with a CNAME of: 'static.tlmc.csp.example' IN CNAME 'static.tlmc.csp.example.tlmc.isp.example' (If an ISP does not participate in TLMC, the CSP would instead answer with a A/AAAA record). We now have to ask the DNS server at the ISP for an IP address to connect to. The ISP is in a good mood today, so we are getting the anycast address to connect to. (If the ISP is not in a good mode, called Offline mode in TLMC, the DNS server at the ISP will answer with a CNAME of: 'static.tlmc.csp.example.tlmc.isp.example' IN CNAME 'kaa.k.se.static.tlmc.csp.example' This assume that the DNS server was place in Karlskrona, Sweden. With this the geographic location of where a request is coming is already built in). If we have an end-user/residence which have an cache server, this is the address (the anycast one) its going to listen too. If an end-user does not have an cache server, the ISP must have one. Probably as close to the edge as possible. (Here starts the answer to your question in the beginning): These two have on thing in comment, though. They have a plug-in in the Traffic Server called, 'hash_remap' (which I made specifically for trying to solve the scenario you replied with. And Netflix's). What the plug-in will do is to change the hostname from 'static.tlmc.csp.example' to a hash-based one. In the example url giving, this will be: 'b1902023cbb5ff2597718437.tlmc.isp.example'. The first hash, 'b1902023cbb5ff25', is the combined hash of host and url. The second hash, '97718437' is the hash of the host only. With this, the ISP is going to have another DNS request. A hashed based one. Depending of how much information they are collecting from their cache servers, they know from which one they should load the content from in this case. This principle is called consistent hashing and scales very well. How many layers of consistent hashing should a ISP be using? Only they know the answer for this one. -- //fredan The Last Mile Cache - http://tlmc.fredan.se From patrick at ianai.net Tue Feb 12 16:20:02 2013 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 12 Feb 2013 11:20:02 -0500 Subject: The 100 Gbit/s problem in your network In-Reply-To: <5119DBCF.2070904@dougbarton.us> References: <5114FC59.9030406@fredan.se> <82bafe65-4724-4c30-b515-99232d207b17@email.android.com> <20130208170208.GA28509@pob.ytti.fi> <026101ce0847$5cf9ad50$16ed07f0$@swan.sk> <20130211122316.GA3686@pob.ytti.fi> <51190100.8030105@kenweb.org> <51193796.3030604@amplex.net> <51194261.5080702@sprunk.org> <5119DBCF.2070904@dougbarton.us> Message-ID: <3C18404C-76BD-4103-8BEA-BFE3C89AF905@ianai.net> On Feb 12, 2013, at 01:06 , Doug Barton wrote: > On 02/11/2013 03:52 PM, Patrick W. Gilmore wrote: >> One of us has a different dictionary than everyone else. > > I'm not sure it's different dictionaries, I think you're talking past each other. No, it's definitely different dictionaries. I am purposely staying out of the whole multicast vs. CDN vs. set-top caching vs. $RANDOM_TECHNOLOGY thing. I was concentrating sole on one point - that the long tail "is _by definition_ a tiny fraction of total demand" (Stephen's emphasis). The long tail might be a fraction, or it might be a majority of the traffic. Depends on the use case. Important to remember this discussing the pros & cons of each protocol / approach. As for the rest, time will tell. But it's fun to watch the discussion, especially by people who have never attempted any of what they are espousing. :) Hey, sometimes that's where the best ideas come up - people who don't know what is impossible are not constrained! -- TTFN, patrick > Video on demand and broadcast are 2 totally different animals. For VOD, multicast is not a good fit, clearly. But for broadcast, it has a lot of potential. Most of the issues with people wanting to pause, rewind, etc. are already handled by modern DVRs, even with live programming. > > What I haven't seen yet in this discussion (and sorry if I've missed it) is the fact that every evening every broadcast network sends out hour after hour of what are essentially "live" broadcasts, in the sense that they were not available "on demand" before they were aired "on TV" that night. In addition to live broadcasts, this nightly programming is ideal for multicast, especially since nowadays most of that programming is viewed off the DVR at another time anyway. So filling up that DVR (or even watching it live) could happen over multicast just as well as it could happen over unicast. > > But more importantly, what's missing from this conversation is that the broadcast networks, the existing cable/satellite/etc. providers, and everyone else who has a multi-billion dollar vested interest in the way that the business is structured now would fight this tooth and nail. So we can engineer all the awesome solutions we want, they are overwhelmingly unlikely to actually happen. > > Doug > > From ljenkins at weber.edu Tue Feb 12 17:46:21 2013 From: ljenkins at weber.edu (Luke Jenkins) Date: Tue, 12 Feb 2013 10:46:21 -0700 Subject: IPv6 support by wifi systems In-Reply-To: References: Message-ID: MLD Snooping and IPv6 ACLs are a must. Check to make sure that the solution allows for many (for your network's definition of many) IPv6 addresses per host. You'll have at least three per host between link local, global, and one or more privacy addresses. I've been providing native dual stack on my Cisco controller based wireless network for a few years now. IPv6 support was brought up a notch with the 7.2 code release. RA Guard was the obvious big features that was added, but I also appreciated the addition of ND caching to keep that chatter down. http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bae506.shtml#discovery I've also used some Ruckus gear on an IPv6 network and it seemed to have all the right knobs and pass all the right IPv6 packets. Though this was on my home network so I can't speek to their IPv6 scalability (no reason to doubt it, just wanted to be clear). Feel free to ping me on or off list about either if you have more specific questions. -Luke On Mon, Feb 11, 2013 at 9:23 PM, Brandon Ross wrote: > Like so many things IPv6, many of the wifi vendors seem to lack decent > support for IPv6 clients. I'm not sure why I thought the situation was > better than it seems to be, I guess I'm just an optimist. > > Anyway, what wifi vendors provide the best support for IPv6? I don't > really care too much about management, but to deploy wifi in a service > provider environment with IPv6, it would seem that you'd want at least: > > RA Guard > DHCPv6 Shield (unless you just do SLAAC, I guess) > IPv6 Source Address Guard > > Am I missing anything critical? > > -- > Brandon Ross Yahoo & AIM: > BrandonNRoss > +1-404-635-6667 ICQ: > 2269442 > Schedule a meeting: https://doodle.com/bross Skype: > brandonross > > -- =-=-=-=-=-=-=-=-=-=-=-= Luke Jenkins Network Engineer Weber State University From william.mccall at gmail.com Tue Feb 12 17:52:50 2013 From: william.mccall at gmail.com (William McCall) Date: Tue, 12 Feb 2013 11:52:50 -0600 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <201302120111.r1C1BQGr090576@aurora.sol.net> Message-ID: On Mon, Feb 11, 2013 at 10:05 PM, Tim Durack wrote: > > Multicast is dead. Feel free to disagree. :-) > > Tim:> > I really wish I could agree! It would have saved me some time dealing with it. There is the argument of alternative bit rates, compression, etc., but HD streams are assumed[1] at 15 Mbps. At 100Gbps, I can do max 6826 streams of HD streaming. Multicast deployments laugh at this pathetically low number of viewers. At an upstream aggregation point, I can easily serve ~128K subs (7 slots, 8 ports per slot, 3 ports per $ACCESS, 8K[3] users per $ACCESS, 1 slot for upstream). I now assume 2.5 STBs per sub[2]. This results in, more or less, 320,000 STBs. To me, the math says its not dead and we'll need a couple of orders of magnitude (to accommodate the core) in speed improvements to get the same delivery unicast. [1] http://www.cablelabs.com/specifications/OC-SP-CEP3.0-I04-121210.pdf Lists 15Mbps as safe harbor value for HD [2] http://www.aceee.org/files/proceedings/2012/data/papers/0193-000294.pdf Has some stat (good or bad) wrt STBs/household [3] uBR10K (my $ACCESS comparison) specs out for max 64K CPE. One of my guys indicates to me that the actual number might be closer to 15-25K CPE on a given node. Please make adjustments as necessary. (required note: employer is Cisco. Views are my own.) -- William McCall From khelms at zcorum.com Tue Feb 12 18:13:20 2013 From: khelms at zcorum.com (Scott Helms) Date: Tue, 12 Feb 2013 13:13:20 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <5119E7E9.9000903@sprunk.org> References: <200375.5875.1360643582960.JavaMail.root@benjamin.baylink.com> <5119E7E9.9000903@sprunk.org> Message-ID: > If the L1 provider's responsibility ends at the jack on the outside NIU, > as an ILEC's does today with copper, then you have clean separation and > easy access for both initial installation and for later > troubleshooting--clear benefits that help mitigate nearly all the > problems Scott refers to, at least from the L1 provider's perspective. > Stephen, I'd say this is much less clean in my experience than you're describing. In fact, I'd say that operationally its downright problematic in many territories and not improving. So if this is the model if how it should be done I think we have a long way to go before doing it in a FTTx world is remotely economical. Now, this isn't a problem in all territories or operators but it is common as dirt. > > > -- > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From bross at pobox.com Tue Feb 12 18:49:02 2013 From: bross at pobox.com (Brandon Ross) Date: Tue, 12 Feb 2013 13:49:02 -0500 (EST) Subject: IPv6 support by wifi systems In-Reply-To: References: Message-ID: On Tue, 12 Feb 2013, Luke Jenkins wrote: > MLD Snooping and IPv6 ACLs are a must. MLD Snooping only seems important to me if you are actually going to do multicast outside of the local broadcast domain, which I can't imagine doing in most service provider environments. Am I missing a reason for it or a use case otherwise? > Check to make sure that the solution allows for many (for your network's > definition of many) IPv6 addresses per host. You'll have at least three > per host between link local, global, and one or more privacy addresses. It would seem to me that either a wifi vendor would support source address shield for IPv6, which MUST include multiple addresses, or it would just pass everything without paying attention to source addresses. Is there a vendor that does not do one or the other? If so, please name names. > I've been providing native dual stack on my Cisco controller based wireless > network for a few years now. IPv6 support was brought up a notch with the > 7.2 code release. RA Guard was the obvious big features that was added, but > I also appreciated the addition of ND caching to keep that chatter down. > http://www.cisco.com/en/US/products/ps10315/products_tech_note09186a0080bae506.shtml#discovery Nice. Can you confirm if they've added DHCPv6 shield too? Source address shield for IPv6? > I've also used some Ruckus gear on an IPv6 network and it seemed to have > all the right knobs and pass all the right IPv6 packets. Though this was on > my home network so I can't speek to their IPv6 scalability (no reason to > doubt it, just wanted to be clear). Thanks, that's a useful data point. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From khelms at zcorum.com Tue Feb 12 19:54:45 2013 From: khelms at zcorum.com (Scott Helms) Date: Tue, 12 Feb 2013 14:54:45 -0500 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <201302120111.r1C1BQGr090576@aurora.sol.net> Message-ID: > I really wish I could agree! It would have saved me some time dealing with > it. > > There is the argument of alternative bit rates, compression, etc., but HD > streams are assumed[1] at 15 Mbps. > > At 100Gbps, I can do max 6826 streams of HD streaming. Multicast > deployments laugh at this pathetically low number of viewers. > > At an upstream aggregation point, I can easily serve ~128K subs (7 slots, 8 > ports per slot, 3 ports per $ACCESS, 8K[3] users per $ACCESS, 1 slot for > upstream). I now assume 2.5 STBs per sub[2]. This results in, more or less, > 320,000 STBs. > Multicast for inside of a given service provider is certainly not dead and in fact its widely deployed for IPTV in DSL/FTTx networks. FIOS doesn't use it since they're not doing IPTV (traditional RFoG) but Uverse does as do most telco TV providers I've spoken with. > > To me, the math says its not dead and we'll need a couple of orders of > magnitude (to accommodate the core) in speed improvements to get the same > delivery unicast. > > [1] http://www.cablelabs.com/specifications/OC-SP-CEP3.0-I04-121210.pdfLists > 15Mbps as safe harbor value for HD > [2] > http://www.aceee.org/files/proceedings/2012/data/papers/0193-000294.pdfHas > some stat (good or bad) wrt STBs/household > [3] uBR10K (my $ACCESS comparison) specs out for max 64K CPE. One of my > guys indicates to me that the actual number might be closer to 15-25K CPE > on a given node. Please make adjustments as necessary. > > (required note: employer is Cisco. Views are my own.) > > -- > William McCall > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Tue Feb 12 19:57:27 2013 From: khelms at zcorum.com (Scott Helms) Date: Tue, 12 Feb 2013 14:57:27 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <200375.5875.1360643582960.JavaMail.root@benjamin.baylink.com> Message-ID: > In part because I'm realizing that it is literally viable to plonk a 6509 > into the colo, get a 10G uplink and pump out a bunch of 1000base?X > connections (or even 100base?X) to customers at a fairly low price > per port. In this case, there wouldn't be any active L2 termination at > the customer other than a media converter or router with an appropriate > SFP. > > Owen > > > Just so you know, this isn't viable, at least not to scale. You can on the other hand use Cisco's ME line to do this even less expensively (so long as you weren't planning on buying used 6509). -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Tue Feb 12 20:17:03 2013 From: khelms at zcorum.com (Scott Helms) Date: Tue, 12 Feb 2013 15:17:03 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <51199011.7050903@necom830.hpcl.titech.ac.jp> References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> Message-ID: Masataka, Numbers? Examples? This is simply incorrect in many places. The only reasons to run PON are financial, since Ethernet out performs it, are you saying that all greenfield PON installs are cheaper done as Ethernet without exception? On Mon, Feb 11, 2013 at 7:42 PM, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > Stephen Sprunk wrote: > > > The fiber plant would presumably be paid for with 30-year bonds, same as > > any other municipal infrastructure (eg. water and sewer lines--the real > > "pipes"), for which interest rates are currently running around the rate > > of inflation. There is no need to pay them off quickly. > > In addition, as PON is even less efficient initially when > subscriber density is low and there are few subscribers to > share a field splitter (unless extremely lengthy drop cables > are used, which costs a lot), PON is slower to pay them off. > > Masataka Ohta > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Tue Feb 12 20:20:50 2013 From: khelms at zcorum.com (Scott Helms) Date: Tue, 12 Feb 2013 15:20:50 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <51198E7D.8050602@sprunk.org> Message-ID: I was in an Incognito user group meeting with one of the guys involved with that project two years ago and we talked about it. Its very cool and frankly extreme engineering :) He had some pictures of them dragging under sea cables themselves that blew my mind. On Mon, Feb 11, 2013 at 7:47 PM, Warren Bailey < wbailey at satelliteintelligencegroup.com> wrote: > Though I should note that GCI was my former employer and a well respected > MSO and fiber infrastructure owner/operator. They are the smartest major > player I've come across, and an all around good bunch of people. > > > From my Android phone on T-Mobile. The first nationwide 4G network. > > > > -------- Original message -------- > From: Warren Bailey > Date: 02/11/2013 4:44 PM (GMT-08:00) > To: Stephen Sprunk ,nanog at nanog.org > Subject: Re: Muni fiber: L1 or L2? > > > Check out GCI's Terranet project. > > > From my Android phone on T-Mobile. The first nationwide 4G network. > > > > -------- Original message -------- > From: Stephen Sprunk > Date: 02/11/2013 4:37 PM (GMT-08:00) > To: nanog at nanog.org > Subject: Re: Muni fiber: L1 or L2? > > > On 11-Feb-13 18:23, Warren Bailey wrote: > > > On 2/11/13 4:16 PM, "Masataka Ohta" > wrote: > >> Scott Helms wrote: > >>> IMO if you can't pay for the initial build quickly and run it > efficiently then your chances of long term success are very low. > >> That is not a business model for infrastructure such as gas, > electricity, CATV, water and fiber network, all of which need long term > planning and investments. > > Nearly all of the industries you mentioned below receive some type of > local or federal/government funding. If I was going to build some kind of > access network, I would be banging on the .gov door asking for grants and > low interest loans to help roll out broadband to remote areas. > I followed the link in a recent email here to the details on the Maine > Fiber Co, and their web site indicates they got started with $7M in private > funding--and a $25M grant from the feds for improving service to rural > areas. That radically changes the economics, just as I'm sure it did for > other utilities. > > S > > -- > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From kauer at biplane.com.au Tue Feb 12 20:36:58 2013 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 13 Feb 2013 07:36:58 +1100 Subject: IPv6 support by wifi systems In-Reply-To: References: Message-ID: <1360701418.4340.114.camel@karl> On Tue, 2013-02-12 at 13:49 -0500, Brandon Ross wrote: > > MLD Snooping and IPv6 ACLs are a must. > > MLD Snooping only seems important to me if you are actually going to do > multicast outside of the local broadcast domain MLD snooping allows the switch to send multicast traffic only to those listeners wanting to receive it. Witout MLD snooping, the switch floods multicast to all ports. May be a security issue, is definitely a traffic issue, though in a small network, it may make no difference. For example, multicast is used by ND, the IPv6 equivalent of ARP. MLD snooping means only a few hosts (typically only one, in fact) in the subnet see any given ND request. Without MLD snooping, every port in the subnet sees it. Or DHCPv6 - without MLD snooping, every port sees all client traffic for all DHCP requests; with MLD snooping only the routers/relays in the subnet see it. "See" with MLD snooping means "see it at all", not "see and ignore it" as in the broadcast world. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 From bross at pobox.com Tue Feb 12 20:40:54 2013 From: bross at pobox.com (Brandon Ross) Date: Tue, 12 Feb 2013 15:40:54 -0500 (EST) Subject: IPv6 support by wifi systems In-Reply-To: <1360701418.4340.114.camel@karl> References: <1360701418.4340.114.camel@karl> Message-ID: On Wed, 13 Feb 2013, Karl Auer wrote: > For example, multicast is used by ND, the IPv6 equivalent of ARP. MLD > snooping means only a few hosts (typically only one, in fact) in the > subnet see any given ND request. Without MLD snooping, every port in the > subnet sees it. Or DHCPv6 - without MLD snooping, every port sees all > client traffic for all DHCP requests; with MLD snooping only the > routers/relays in the subnet see it. "See" with MLD snooping means "see > it at all", not "see and ignore it" as in the broadcast world. Oh really? Exactly when during the ND process does a device send an MLD message that can be snooped? -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From mohta at necom830.hpcl.titech.ac.jp Tue Feb 12 20:47:44 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 13 Feb 2013 05:47:44 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> Message-ID: <511AAA70.6090902@necom830.hpcl.titech.ac.jp> Scott Helms wrote: > Numbers? Examples? Greenfield SS and PON deployment costs in Japan was already shown. > This is simply incorrect in many places. The only > reasons to run PON are financial, since Ethernet out performs it, No, the only reason to insist on PON is to make L1 unbundling not feasible. > are you > saying that all greenfield PON installs are cheaper done as Ethernet > without exception? No, SS is cheaper than PON without exception. If the initial density of subscribers is high, SS is fine. If it is not, initially, most electric equipment, OE port, fibers, splitters and a large closures containing the splitters of PON can not be shared by two or more subscribers, which means PON incurs much more material and labor cost for each initial subscriber than SS. Masataka Ohta From khelms at zcorum.com Tue Feb 12 20:59:11 2013 From: khelms at zcorum.com (Scott Helms) Date: Tue, 12 Feb 2013 15:59:11 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <511AAA70.6090902@necom830.hpcl.titech.ac.jp> References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> Message-ID: On Tue, Feb 12, 2013 at 3:47 PM, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > Scott Helms wrote: > > > Numbers? Examples? > > Greenfield SS and PON deployment costs in Japan was already shown. > Japan has one of the highest population densities of major economies in the world with an average density of 873 per square mile. The US on the other hand has 89 per square mile. Canada has an average density of 10 people per square mile. I would also say that Japan's consumer behavior and regulatory climate are all significantly different from the North American market so making blanket statements is pretty silly. If you want to make your case then why don't you, the only Japanese & English speaker on this list I know of, extract the math behind the NTT papers and present why its cheaper in Japan and we can then see if that applies equally in the US & Canada. > > > This is simply incorrect in many places. The only > > reasons to run PON are financial, since Ethernet out performs it, > > No, the only reason to insist on PON is to make L1 unbundling > not feasible. > I don't know what conspiracy theory you're ascribing to here, but this is incorrect. > > > are you > > saying that all greenfield PON installs are cheaper done as Ethernet > > without exception? > > No, SS is cheaper than PON without exception. > Prove it. > > If the initial density of subscribers is high, SS is fine. > > If it is not, initially, most electric equipment, OE port, > fibers, splitters and a large closures containing the splitters > of PON can not be shared by two or more subscribers, which means > PON incurs much more material and labor cost for each initial > subscriber than SS. > > Masataka Ohta > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From kauer at biplane.com.au Tue Feb 12 21:06:35 2013 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 13 Feb 2013 08:06:35 +1100 Subject: IPv6 support by wifi systems In-Reply-To: References: <1360701418.4340.114.camel@karl> Message-ID: <1360703195.4340.118.camel@karl> On Tue, 2013-02-12 at 15:40 -0500, Brandon Ross wrote: > On Wed, 13 Feb 2013, Karl Auer wrote: > > > For example, multicast is used by ND, the IPv6 equivalent of ARP. MLD > Oh really? Exactly when during the ND process does a device send an MLD > message that can be snooped? ND just uses multicast, so MLD messages are not really part of ND itself. But during the setup of any interface with an IPv6 address, MLD traffic will move and can be snooped on. The switch then knows what listeners are where, so when for example an NS is sent to the solicited node multicast address of a target during ND, the switch can send it only to those hosts it knows are listeners on that group. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 From jason at thebaughers.com Tue Feb 12 21:15:02 2013 From: jason at thebaughers.com (Jason Baugher) Date: Tue, 12 Feb 2013 15:15:02 -0600 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> Message-ID: Scott, I've been down this road with Masataka. over the last few days. I gave up. On Tue, Feb 12, 2013 at 2:59 PM, Scott Helms wrote: > On Tue, Feb 12, 2013 at 3:47 PM, Masataka Ohta < > mohta at necom830.hpcl.titech.ac.jp> wrote: > > > Scott Helms wrote: > > > > > Numbers? Examples? > > > > Greenfield SS and PON deployment costs in Japan was already shown. > > > > Japan has one of the highest population densities of major economies in the > world with an average density of 873 per square mile. The US on the other > hand has 89 per square mile. Canada has an average density of 10 people > per square mile. I would also say that Japan's consumer behavior and > regulatory climate are all significantly different from the North American > market so making blanket statements is pretty silly. > > If you want to make your case then why don't you, the only Japanese & > English speaker on this list I know of, extract the math behind the NTT > papers and present why its cheaper in Japan and we can then see if that > applies equally in the US & Canada. > > > > > > This is simply incorrect in many places. The only > > > reasons to run PON are financial, since Ethernet out performs it, > > > > No, the only reason to insist on PON is to make L1 unbundling > > not feasible. > > > > I don't know what conspiracy theory you're ascribing to here, but this is > incorrect. > > > > > > are you > > > saying that all greenfield PON installs are cheaper done as Ethernet > > > without exception? > > > > No, SS is cheaper than PON without exception. > > > > Prove it. > > > > > > If the initial density of subscribers is high, SS is fine. > > > > If it is not, initially, most electric equipment, OE port, > > fibers, splitters and a large closures containing the splitters > > of PON can not be shared by two or more subscribers, which means > > PON incurs much more material and labor cost for each initial > > subscriber than SS. > > > > Masataka Ohta > > > > > > -- > Scott Helms > Vice President of Technology > ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > From bross at pobox.com Tue Feb 12 21:29:53 2013 From: bross at pobox.com (Brandon Ross) Date: Tue, 12 Feb 2013 16:29:53 -0500 (EST) Subject: IPv6 support by wifi systems In-Reply-To: <1360703195.4340.118.camel@karl> References: <1360701418.4340.114.camel@karl> <1360703195.4340.118.camel@karl> Message-ID: On Wed, 13 Feb 2013, Karl Auer wrote: > The switch then knows what listeners are where, so when for example an > NS is sent to the solicited node multicast address of a target during > ND, the switch can send it only to those hosts it knows are listeners on > that group. Okay, so then to answer my own question from earlier, the answer is actually that an MLD is sent when an interface configures a new address to join the appropriate solicited node multicast group. It seems that, then, MLD snooping is valuable as it will prevent DAD and other ND traffic from using bandwidth towards hosts not in that group. Other than solicited node multicast, is MLD used anywhere else in a network that does not have layer 3 multicast enabled on a router? -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From mike at mtcc.com Tue Feb 12 21:56:06 2013 From: mike at mtcc.com (Michael Thomas) Date: Tue, 12 Feb 2013 13:56:06 -0800 Subject: home network monitoring and shaping Message-ID: <511ABA76.8040003@mtcc.com> O oracle of nanog: unlike things like rogue processes eating tons of CPU, it seems to me that network monitoring is essentially a black art for the average schmuck home network operator (of which I count myself). That is: if the "network is slow", it's really hard to tell why that might be and who of the eleventy seven devices on my wifi is sucking the life out of my bandwidth. And then even if I get an idea of who the perp is, my remediation choice seems to be "find that device, smash it with sledge hammer". It seems that there really ought to be a better way here to manage my home network. Like, for example, the ability to get stats from router and tell it to shape various devices/flows to play nice. Right now, it seems to me that the state of the art is pretty bad -- static-y kinds of setups for static-y kinds of flows that people-y kind of users don't understand or touch on their home routers. The ob-nanog is that "my intertoobs r slow" is most likely a call to your support desks which is expensive, of course. Is anything happening on this front? Is openwrt, for example, paying much attention to this problem? Mike From wbailey at satelliteintelligencegroup.com Tue Feb 12 22:07:15 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 12 Feb 2013 22:07:15 +0000 Subject: home network monitoring and shaping In-Reply-To: <511ABA76.8040003@mtcc.com> References: <511ABA76.8040003@mtcc.com> Message-ID: <6bi43dr4labcjygsnvr21ti6.1360706827397@email.android.com> Someone created an application for uverse users that goes into the gateway and pulls relevant information. The information (link retrain, for example) is then color coded for caution and out of range. The application is called up real time, not something peddled by at&t to show how "great" your connection is. People unfortunately believe a speed test is a reliable way to measure a connection quality. There may be utilities out there like this that look at signal levels and statistics to tell the user their connection blows. I believe the uvrealtime application actually shows the provider sending resets as a deterrent for using bit torrent. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Michael Thomas Date: 02/12/2013 1:57 PM (GMT-08:00) To: NANOG list Subject: home network monitoring and shaping O oracle of nanog: unlike things like rogue processes eating tons of CPU, it seems to me that network monitoring is essentially a black art for the average schmuck home network operator (of which I count myself). That is: if the "network is slow", it's really hard to tell why that might be and who of the eleventy seven devices on my wifi is sucking the life out of my bandwidth. And then even if I get an idea of who the perp is, my remediation choice seems to be "find that device, smash it with sledge hammer". It seems that there really ought to be a better way here to manage my home network. Like, for example, the ability to get stats from router and tell it to shape various devices/flows to play nice. Right now, it seems to me that the state of the art is pretty bad -- static-y kinds of setups for static-y kinds of flows that people-y kind of users don't understand or touch on their home routers. The ob-nanog is that "my intertoobs r slow" is most likely a call to your support desks which is expensive, of course. Is anything happening on this front? Is openwrt, for example, paying much attention to this problem? Mike From mohta at necom830.hpcl.titech.ac.jp Tue Feb 12 22:57:22 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 13 Feb 2013 07:57:22 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> Message-ID: <511AC8D2.4060601@necom830.hpcl.titech.ac.jp> Scott Helms wrote: >>> Numbers? Examples? >> Greenfield SS and PON deployment costs in Japan was already shown. > Japan has one of the highest population densities of major economies in the The examples are in rural area and I already stated population density in English. >> No, the only reason to insist on PON is to make L1 unbundling >> not feasible. > I don't know what conspiracy theory you're ascribing to here, but this is > incorrect. PON being more expensive than SS, that is the only explanation. >> No, SS is cheaper than PON without exception. > Prove it. See above or below. >> If the initial density of subscribers is high, SS is fine. >> >> If it is not, initially, most electric equipment, OE port, >> fibers, splitters and a large closures containing the splitters >> of PON can not be shared by two or more subscribers, which means >> PON incurs much more material and labor cost for each initial >> subscriber than SS. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Tue Feb 12 23:03:44 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 13 Feb 2013 08:03:44 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> Message-ID: <511ACA50.9000109@necom830.hpcl.titech.ac.jp> Jason Baugher wrote: > Scott, I've been down this road with Masataka. over the last few days. I > gave up. You have lost instantly, because you insisted on 32:1, which makes expensive PON even more expensive. It's stupid to insist on 32:1 to have 6 trunk fibers and 31 drop fibers within a cable for 192 subscribers, because with 8:1, you only need 24 trunk fibers and 7 drop fibers. Your theory is not consistent with the reality. Masataka Ohta From wbailey at satelliteintelligencegroup.com Tue Feb 12 23:13:15 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 12 Feb 2013 23:13:15 +0000 Subject: Muni fiber: L1 or L2? In-Reply-To: <511ACA50.9000109@necom830.hpcl.titech.ac.jp> Message-ID: At this point I think the topic has been exhausted. If you participate in a conversation, try to chime in with thoughtful and insightful points. We're on here to help each other, if you want to measure girth there is probably a better venue to do so. I don't think anyone lost anything, other than a vast amount of wasted time trying to decipher your claims and opinion. It's easy to tell people how full of it they are, but if you're looking for a venue to argue (we have all done it) you should move on to greener pastures. If all of this is difficult to understand, I will summarize: Acting like a prick on a discussion list makes all of your opinions and concerns completely ignored. No one wants to deal with an arrogant prick, especially one who says someone "lost" because your opinion seems to be more valid to yourself. On 2/12/13 3:03 PM, "Masataka Ohta" wrote: >Jason Baugher wrote: > >> Scott, I've been down this road with Masataka. over the last few days. I >> gave up. > >You have lost instantly, because you insisted on 32:1, which >makes expensive PON even more expensive. > >It's stupid to insist on 32:1 to have 6 trunk fibers and 31 drop >fibers within a cable for 192 subscribers, because with 8:1, you >only need 24 trunk fibers and 7 drop fibers. > >Your theory is not consistent with the reality. > > Masataka Ohta > > > > From mike at mtcc.com Tue Feb 12 23:56:16 2013 From: mike at mtcc.com (Michael Thomas) Date: Tue, 12 Feb 2013 15:56:16 -0800 Subject: home network monitoring and shaping In-Reply-To: <6bi43dr4labcjygsnvr21ti6.1360706827397@email.android.com> References: <511ABA76.8040003@mtcc.com> <6bi43dr4labcjygsnvr21ti6.1360706827397@email.android.com> Message-ID: <511AD6A0.4000400@mtcc.com> On 02/12/2013 02:07 PM, Warren Bailey wrote: > Someone created an application for uverse users that goes into the gateway and pulls relevant information. The information (link retrain, for example) is then color coded for caution and out of range. The application is called up real time, not something peddled by at&t to show how "great" your connection is. People unfortunately believe a speed test is a reliable way to measure a connection quality. There may be utilities out there like this that look at signal levels and statistics to tell the user their connection blows. I believe the uvrealtime application actually shows the provider sending resets as a deterrent for using bit torrent. > > It would be nice for such a thing to tell me that my ISP connection is having trouble too, but I'm mostly interested in understanding the things that are nominally under my control on my home network. It seems that most routers have (gratuitous?) apps these day, but given the awfulness of their web UI's and their configurability, I don't have much hope that they do what I want. Mike From eaptech at gmail.com Wed Feb 13 00:01:55 2013 From: eaptech at gmail.com (Eric Adler) Date: Tue, 12 Feb 2013 19:01:55 -0500 Subject: home network monitoring and shaping In-Reply-To: <511ABA76.8040003@mtcc.com> References: <511ABA76.8040003@mtcc.com> Message-ID: I'm quite happy with what routeros (mikrotik) provides me on my home network. - Eric Eric Adler Broadcast Engineer On 2/12/13, Michael Thomas wrote: > > O oracle of nanog: unlike things like rogue processes eating tons of CPU, > it seems to me that network monitoring is essentially a black art for the > average schmuck home network operator (of which I count myself). That > is: if the "network is slow", it's really hard to tell why that might be > and > who of the eleventy seven devices on my wifi is sucking the life out of my > bandwidth. And then even if I get an idea of who the perp is, my > remediation > choice seems to be "find that device, smash it with sledge hammer". > > It seems that there really ought to be a better way here to manage my > home network. Like, for example, the ability to get stats from router and > tell it to shape various devices/flows to play nice. Right now, it seems to > me that the state of the art is pretty bad -- static-y kinds of setups for > static-y kinds of flows that people-y kind of users don't understand or > touch on their home routers. > > The ob-nanog is that "my intertoobs r slow" is most likely a call to your > support desks which is expensive, of course. Is anything happening on > this front? Is openwrt, for example, paying much attention to this problem? > > Mike > > -- Sent from my mobile device From james at talkunafraid.co.uk Wed Feb 13 00:10:19 2013 From: james at talkunafraid.co.uk (James Harrison) Date: Wed, 13 Feb 2013 00:10:19 +0000 Subject: home network monitoring and shaping In-Reply-To: <511ABA76.8040003@mtcc.com> References: <511ABA76.8040003@mtcc.com> Message-ID: <511AD9EB.3070101@talkunafraid.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/02/2013 21:56, Michael Thomas wrote: > > It seems that there really ought to be a better way here to manage > my home network. Like, for example, the ability to get stats from > router and tell it to shape various devices/flows to play nice. > Right now, it seems to me that the state of the art is pretty bad > -- static-y kinds of setups for static-y kinds of flows that > people-y kind of users don't understand or touch on their home > routers. > I've been using per-connection queues on a Mikrotik 450G; this permits shaping based on the destination/source IP, so no one device can nom all of the bandwidth on the link unless it's uncontested; should more than one device want all the bandwidth they both get half, and so on (in a typical config). It's not flawless but it's a massive improvement on no shaping whatsoever. The gotcha is that you need to configure your link speed in the router for it to be aware of the capacity it has to play with, but that's not something you have to touch very often most of the time (though if your connection speed/upstream capacity varies, there's not a lot that'll help you at that point. But it does most of the time stop the "X is watching HD YouTube videos and now I can't check my email" sort of problems. It's a nice set-and-forget solution. ntop or similar on a Linux boxen in concert with flows from said Mikrotik tends to help more than anything for analysis of usage etc, but it's still an inelelegant solution to the problem of analyzing links in this scenario. I'd be interested in what other people are using for home connection debugging. Cheers, James -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAlEa2esACgkQ22kkGnnJQAyFnwCfcaq95/Nd1iNk4Fj/j6jSB98A fEsAn3CIgoizBZjPbTTwlQPS+iKccx2Q =FUhz -----END PGP SIGNATURE----- From jmaslak at antelope.net Wed Feb 13 00:46:50 2013 From: jmaslak at antelope.net (Joel Maslak) Date: Tue, 12 Feb 2013 17:46:50 -0700 Subject: home network monitoring and shaping In-Reply-To: <511AD9EB.3070101@talkunafraid.co.uk> References: <511ABA76.8040003@mtcc.com> <511AD9EB.3070101@talkunafraid.co.uk> Message-ID: I've had great luck with Cisco's fair-queue option (and similar techniques). Using RED, small queues (think on the order of 10-20 packets), and creating a choke point in and out of the network, I've implemented similar behavior on plenty of DSL lines on the CPE-side. My most successful was sharing one 7mbps line with 120 technical employees - before the implementation of improved queuing, web pages took 60 seconds or more to load during peak usage. After implementation, people didn't know they were on a shared DSL unless they tried streaming video (fortunately not a business requirement) or a bulk download (it worked fine, it just would be slow if there were several others going on at the same time). I suspect I could have even made a VoIP call across the line with a MOS in the high 3's easily. A second issue is poor wireless retransmission and buffering implementations in consumer wireless. For my home, to make VoIP work with low-end gear, I had to break most HTTP sessions and switch to a delay-based congestion control algorithm inside my network - due to the 5+ second buffers on the wifi gear. That would probably have been enough, but turning on WMM really took the rest of the pain out of wifi-VoIP. I don't know how to fix the home wifi problems (WMM helps with some applications, certainly, but it's not a full solution if you still have 5 second buffers in the default traffic class). But for the other problems, it would be nice if my provider didn't give me huge buffers and no RED on the output queue (I have no idea if they are doing the best they can with the gear they have or not, so there may not be any option here). But, even without that, home routers can do better than they do now. My router knows what speed it's connected at. It can create an internal bottleneck slightly slower, prioritize small packets, implement RED, and use reasonably-sized buffers (fast downloads should not increase ping times by hundreds of ms). I shouldn't need to hang a Linux box between it and my home network. Large buffers have broken the average home internet. I can't tell you how many people are astonished when I say "one of your family members downloading a huge Microsoft ISO image (via TCP or other congestion-aware algorithm) shouldn't even be noticed by another family member doing web browsing. If it is noticed, the network is broke. Even if it's at the end of a slow DSL line." From r.engehausen at gmail.com Wed Feb 13 01:15:27 2013 From: r.engehausen at gmail.com (Roy) Date: Tue, 12 Feb 2013 17:15:27 -0800 Subject: home network monitoring and shaping In-Reply-To: <511AD9EB.3070101@talkunafraid.co.uk> References: <511ABA76.8040003@mtcc.com> <511AD9EB.3070101@talkunafraid.co.uk> Message-ID: <511AE92F.90200@gmail.com> On 2/12/2013 4:10 PM, James Harrison wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 12/02/2013 21:56, Michael Thomas wrote: >> It seems that there really ought to be a better way here to manage >> my home network. Like, for example, the ability to get stats from >> router and tell it to shape various devices/flows to play nice. >> Right now, it seems to me that the state of the art is pretty bad >> -- static-y kinds of setups for static-y kinds of flows that >> people-y kind of users don't understand or touch on their home >> routers. >> > I've been using per-connection queues on a Mikrotik 450G; this permits > shaping based on the destination/source IP, so no one device can nom > all of the bandwidth on the link unless it's uncontested; should more > than one device want all the bandwidth they both get half, and so on > (in a typical config). It's not flawless but it's a massive > improvement on no shaping whatsoever. > > The gotcha is that you need to configure your link speed in the router > for it to be aware of the capacity it has to play with, but that's not > something you have to touch very often most of the time (though if > your connection speed/upstream capacity varies, there's not a lot > that'll help you at that point. But it does most of the time stop the > "X is watching HD YouTube videos and now I can't check my email" sort > of problems. It's a nice set-and-forget solution. > > ntop or similar on a Linux boxen in concert with flows from said > Mikrotik tends to help more than anything for analysis of usage etc, > but it's still an inelelegant solution to the problem of analyzing > links in this scenario. I'd be interested in what other people are > using for home connection debugging. > > Cheers, > James For Mikrotik routers, use the Winbox application and the Torch function on the interface. You can set it to show flows by various criteria such as source IP. That will tell you which client is chewing up the bandwidth at any instant. Another way to go that I have not tried with Mikrotik is the Solarwinds Netflow analyzer. It tracks 60 minutes of data. http://www.solarwinds.com/products/freetools/netflow_analyzer.aspx From g at 1337.io Wed Feb 13 02:57:24 2013 From: g at 1337.io (g at 1337.io) Date: Tue, 12 Feb 2013 18:57:24 -0800 Subject: home network monitoring and shaping In-Reply-To: <511ABA76.8040003@mtcc.com> References: <511ABA76.8040003@mtcc.com> Message-ID: <511B0114.40007@1337.io> I vote pfSense.. don't skimp on the NIC's when you build one out (Intel ftw). My $0.02.. Gino On 2/12/13 1:56 PM, Michael Thomas wrote: > > O oracle of nanog: unlike things like rogue processes eating tons of CPU, > it seems to me that network monitoring is essentially a black art for the > average schmuck home network operator (of which I count myself). That > is: if the "network is slow", it's really hard to tell why that might be > and > who of the eleventy seven devices on my wifi is sucking the life out of my > bandwidth. And then even if I get an idea of who the perp is, my > remediation > choice seems to be "find that device, smash it with sledge hammer". > > It seems that there really ought to be a better way here to manage my > home network. Like, for example, the ability to get stats from router and > tell it to shape various devices/flows to play nice. Right now, it seems to > me that the state of the art is pretty bad -- static-y kinds of setups for > static-y kinds of flows that people-y kind of users don't understand or > touch on their home routers. > > The ob-nanog is that "my intertoobs r slow" is most likely a call to your > support desks which is expensive, of course. Is anything happening on > this front? Is openwrt, for example, paying much attention to this problem? > > Mike > From ler762 at gmail.com Wed Feb 13 03:17:09 2013 From: ler762 at gmail.com (Lee) Date: Tue, 12 Feb 2013 22:17:09 -0500 Subject: home network monitoring and shaping In-Reply-To: <511AD9EB.3070101@talkunafraid.co.uk> References: <511ABA76.8040003@mtcc.com> <511AD9EB.3070101@talkunafraid.co.uk> Message-ID: > I'd be interested in what other people are using for home connection debugging. I put the teenager behind a 10Mb hub & haven't had any problems since :) Regards, Lee On 2/12/13, James Harrison wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 12/02/2013 21:56, Michael Thomas wrote: >> >> It seems that there really ought to be a better way here to manage >> my home network. Like, for example, the ability to get stats from >> router and tell it to shape various devices/flows to play nice. >> Right now, it seems to me that the state of the art is pretty bad >> -- static-y kinds of setups for static-y kinds of flows that >> people-y kind of users don't understand or touch on their home >> routers. >> > > I've been using per-connection queues on a Mikrotik 450G; this permits > shaping based on the destination/source IP, so no one device can nom > all of the bandwidth on the link unless it's uncontested; should more > than one device want all the bandwidth they both get half, and so on > (in a typical config). It's not flawless but it's a massive > improvement on no shaping whatsoever. > > The gotcha is that you need to configure your link speed in the router > for it to be aware of the capacity it has to play with, but that's not > something you have to touch very often most of the time (though if > your connection speed/upstream capacity varies, there's not a lot > that'll help you at that point. But it does most of the time stop the > "X is watching HD YouTube videos and now I can't check my email" sort > of problems. It's a nice set-and-forget solution. > > ntop or similar on a Linux boxen in concert with flows from said > Mikrotik tends to help more than anything for analysis of usage etc, > but it's still an inelelegant solution to the problem of analyzing > links in this scenario. I'd be interested in what other people are > using for home connection debugging. > > Cheers, > James > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (MingW32) > > iEYEARECAAYFAlEa2esACgkQ22kkGnnJQAyFnwCfcaq95/Nd1iNk4Fj/j6jSB98A > fEsAn3CIgoizBZjPbTTwlQPS+iKccx2Q > =FUhz > -----END PGP SIGNATURE----- > > From kauer at biplane.com.au Wed Feb 13 03:32:22 2013 From: kauer at biplane.com.au (Karl Auer) Date: Wed, 13 Feb 2013 14:32:22 +1100 Subject: IPv6 support by wifi systems In-Reply-To: References: <1360701418.4340.114.camel@karl> <1360703195.4340.118.camel@karl> Message-ID: <1360726342.4340.128.camel@karl> On Tue, 2013-02-12 at 16:29 -0500, Brandon Ross wrote: > It seems that, then, > MLD snooping is valuable as it will prevent DAD and other ND traffic from > using bandwidth towards hosts not in that group. It will prevent *all* multicast traffic from using bandwidth towards hosts not in the multicast groups involved. ND, DAD etc are just specific cases. > Other than solicited node multicast, is MLD used anywhere else in a > network that does not have layer 3 multicast enabled on a router? MLD is used for all multicast - so a DHCPv6 packet, for example, will only go to any relays and servers in the subnet. *Any* multicast will be limited to its listeners. The only multicast that will go to all nodes will be multicast sent to the "all link-local nodes" address - and even that will not go to non-IPv6 nodes. MLD snooping happens on switches - you will get the benefit even if in an isolated network (no router at all). Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 From owen at delong.com Wed Feb 13 08:55:33 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 13 Feb 2013 00:55:33 -0800 Subject: IPv6 support by wifi systems In-Reply-To: <1360726342.4340.128.camel@karl> References: <1360701418.4340.114.camel@karl> <1360703195.4340.118.camel@karl> <1360726342.4340.128.camel@karl> Message-ID: On Feb 12, 2013, at 7:32 PM, Karl Auer wrote: > On Tue, 2013-02-12 at 16:29 -0500, Brandon Ross wrote: >> It seems that, then, >> MLD snooping is valuable as it will prevent DAD and other ND traffic from >> using bandwidth towards hosts not in that group. > > It will prevent *all* multicast traffic from using bandwidth towards > hosts not in the multicast groups involved. ND, DAD etc are just > specific cases. > >> Other than solicited node multicast, is MLD used anywhere else in a >> network that does not have layer 3 multicast enabled on a router? > > MLD is used for all multicast - so a DHCPv6 packet, for example, will > only go to any relays and servers in the subnet. *Any* multicast will be > limited to its listeners. The only multicast that will go to all nodes > will be multicast sent to the "all link-local nodes" address - and even > that will not go to non-IPv6 nodes. > > MLD snooping happens on switches - you will get the benefit even if in > an isolated network (no router at all). > In a wifi environment, however, this has additional complexity. A multicast packet originating within the WAP or from the wired side of the WAP and destined for more than one wireless host should be sent to be heard by all hosts so it is only transmitted once. Otherwise it ties up excessive air time. In this regard, a WAP is more like a hub than a switch. A multicast packet originating from a wifi host, OTOH, must be repeated by the WAP so that all subscribed hosts can hear it. Owen From adam.vitkovsky at swan.sk Wed Feb 13 12:10:59 2013 From: adam.vitkovsky at swan.sk (Adam Vitkovsky) Date: Wed, 13 Feb 2013 13:10:59 +0100 Subject: The 100 Gbit/s problem in your network In-Reply-To: References: <201302120111.r1C1BQGr090576@aurora.sol.net> Message-ID: <033301ce09e3$2f10a810$8d31f830$@swan.sk> > Multicast is dead. Feel free to disagree. :-) > > Tim:> > Multicast will never be dead. With ever raising bandwidth needs we'll always welcome a distribution method that allows us to pass the same data least times over the least number of links. We all remember the spikes in BW demands when the Austrian fellow jumped from space And regarding the global m-cast. Well we don't need it. You can get the IPTV streams via direct link or via common carrier's mvpn adam From khelms at zcorum.com Wed Feb 13 12:34:32 2013 From: khelms at zcorum.com (Scott Helms) Date: Wed, 13 Feb 2013 07:34:32 -0500 Subject: Muni fiber: L1 or L2? In-Reply-To: <511AC8D2.4060601@necom830.hpcl.titech.ac.jp> References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> <511AC8D2.4060601@necom830.hpcl.titech.ac.jp> Message-ID: Masataka, Using the UK as a model for US and Canadian deployments is a fallacy. The population density there is 673 per square mile, much closer to Japan's (873 per sq mile) than either the US (89 per sq mile) or Canada (10 per sq mile). The UK also has a legal monopoly for telephone infrastructure and very different regulatory system. Using the UK for anything in this discussion is simply wrong. You may be a brilliant conversationalist in Japanese, but you're not making a convincing argument in English and simply railing that your position is correct without regard to countering information isn't going to convince anyone. Keep on this track and you're just going to be ignored by most people on the list. On Tue, Feb 12, 2013 at 5:57 PM, Masataka Ohta < mohta at necom830.hpcl.titech.ac.jp> wrote: > Scott Helms wrote: > > >>> Numbers? Examples? > > >> Greenfield SS and PON deployment costs in Japan was already shown. > > > Japan has one of the highest population densities of major economies in > the > > The examples are in rural area and I already stated population > density in English. > > >> No, the only reason to insist on PON is to make L1 unbundling > >> not feasible. > > > I don't know what conspiracy theory you're ascribing to here, but this is > > incorrect. > > PON being more expensive than SS, that is the only explanation. > > >> No, SS is cheaper than PON without exception. > > > Prove it. > > See above or below. > > >> If the initial density of subscribers is high, SS is fine. > >> > >> If it is not, initially, most electric equipment, OE port, > >> fibers, splitters and a large closures containing the splitters > >> of PON can not be shared by two or more subscribers, which means > >> PON incurs much more material and labor cost for each initial > >> subscriber than SS. > > Masataka Ohta > > -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From mohta at necom830.hpcl.titech.ac.jp Wed Feb 13 13:33:04 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 13 Feb 2013 22:33:04 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: Message-ID: <511B9610.70402@necom830.hpcl.titech.ac.jp> Warren Bailey wrote: > No one wants to deal with an > arrogant prick, especially one who says someone "lost" because your > opinion seems to be more valid to yourself. Figures in http://www.soumu.go.jp/main_sosiki/joho_tsusin/policyreports/chousa/bb_seibi/pdf/041209_2_14.pdf is not my opinion but neutral data from a governmental regulator of Japan like FCC of USA. According to the data, the reality is that PON is more expensive than SS, w.r.t. for both cabling and equipments. So far, no one could have provided any concrete data or consistent theory to deny it. If you can't accept the shown reality that PON is more expensive than SS and insist on stating it were my opinion without any evidences, its your arrogance. PERIOD. Masataka Ohta From mohta at necom830.hpcl.titech.ac.jp Wed Feb 13 13:50:17 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Wed, 13 Feb 2013 22:50:17 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> <511AC8D2.4060601@necom830.hpcl.titech.ac.jp> Message-ID: <511B9A19.7080700@necom830.hpcl.titech.ac.jp> Scott Helms wrote: > Masataka, > > Using the UK as a model for US and Canadian deployments is a fallacy. May or may not be. But, what???? "Using the UK as a model for US and Canadian deployments"!!!!!????? I'm afraid it's not me but you to have done so. So? Who are you arguing against? > You may be a brilliant conversationalist in Japanese, but > you're not making a convincing argument in English and simply > railing that your position is correct without regard to > countering information isn't going to convince anyone. If you feel so, it merely means that your ability to understand English is a lot worse than mine. Sorry, but, it is your problem. > Keep on this track and you're just going to be ignored by > most people on the list. I'm afraid it is also your problem to be suffered by you. Masataka Ohta From mike at mikejones.in Wed Feb 13 15:07:02 2013 From: mike at mikejones.in (Mike Jones) Date: Wed, 13 Feb 2013 15:07:02 +0000 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> <511AC8D2.4060601@necom830.hpcl.titech.ac.jp> Message-ID: On 13 February 2013 12:34, Scott Helms wrote: > Using the UK as a model for US and Canadian deployments is a fallacy. I don't believe anyone was looking at the UK model? But now that you mention it the UK has a rather interesting model for fibre deployment, a significant portion of the country has "fibre optic broadband" avaliable from multiple providers. BT Openreach (and others on their infrastructure) offer "Fibre Optic Broadband" over twisted pair, and VirginMedia offer "Fibre Optic Broadband" over coax. The UKs 'just pretend it's fibre' deployment method is cheaper than both PON and SS. Only requirement is that you have a regulator that doesn't care when companies flat out lie to customers. - Mike From joesox at gmail.com Wed Feb 13 15:19:53 2013 From: joesox at gmail.com (JoeSox) Date: Wed, 13 Feb 2013 07:19:53 -0800 Subject: NOC display software Message-ID: Just wondering if anyone can recommend Windows software (it could be Linux too but I might need to create a separate host for that configuration) that enables rotating [on one monitor] several webpages (dashboards) or windows (application dashboards). It would be nice if it was freeware or open source but whatever works best is what I am looking for. For example, if I wanted one monitor to cycle thru my local SolarWinds Orion, Office 365 Health Status, and anyother webdashboards. -- Thank You, Joe From nat at nuqe.net Wed Feb 13 15:29:51 2013 From: nat at nuqe.net (Nat Morris) Date: Wed, 13 Feb 2013 15:29:51 +0000 Subject: NOC display software In-Reply-To: References: Message-ID: On 13 February 2013 15:19, JoeSox wrote: > Just wondering if anyone can recommend Windows software (it could be > Linux too but I might need to create a separate host for that > configuration) > that enables rotating [on one monitor] several webpages (dashboards) > or windows (application dashboards). > It would be nice if it was freeware or open source but whatever works > best is what I am looking for. > For example, if I wanted one monitor to cycle thru my local SolarWinds > Orion, Office 365 Health Status, and anyother webdashboards. Install firefox, open tabs for everything you wish to display, install Tab Slideshow and set it to cycle. https://addons.mozilla.org/en-us/firefox/addon/tab-slideshow/ Then just hit F11 and put Firefox into fullscreen mode, works on Win/Mac/Linux. -- Nat 07531 750292 http://natmorris.co.uk From marcus at linx.net Wed Feb 13 15:39:18 2013 From: marcus at linx.net (Marcus Taylor) Date: Wed, 13 Feb 2013 15:39:18 +0000 Subject: NOC display software In-Reply-To: References: Message-ID: <511BB3A6.7010804@linx.net> On 13/02/13 15:19, JoeSox wrote: > Just wondering if anyone can recommend Windows software This pains me to do this My quick google fu: http://www.autohotkey.com/ Loop { Send {Alt down}{Tab down}{Alt up}{Tab up} Sleep 60000 ; wait 60 seconds } You may have to switch off 'Tab through recently used windows' [Don't think this is an issue with XP] Cheers -- Marcus Taylor (Database Application Developer) London Internet Exchange Ltd. 2nd Floor Trinity Court, Trinity Street, PE1 1DA Registered England and Wales number 3137929 DDI 01733 207724 From seth.mos at dds.nl Wed Feb 13 15:42:23 2013 From: seth.mos at dds.nl (Seth Mos) Date: Wed, 13 Feb 2013 16:42:23 +0100 Subject: NOC display software In-Reply-To: References: Message-ID: <511BB45F.20304@dds.nl> On 13-2-2013 16:19, JoeSox wrote: > Just wondering if anyone can recommend Windows software (it could be > Linux too but I might need to create a separate host for that > configuration) > that enables rotating [on one monitor] several webpages (dashboards) > or windows (application dashboards). > It would be nice if it was freeware or open source but whatever works > best is what I am looking for. > For example, if I wanted one monitor to cycle thru my local SolarWinds > Orion, Office 365 Health Status, and anyother webdashboards. We use a Dell Optiplex that drives 2 rotated FullHD 42 inch TV's. This gives us effectively a 2k x 4k resolution to work with. We have written a custom webpage that refreshes divs automatically, it has a country map and puts the various sites on the map where the outage is. This is mainly handy for DSL outages. The left TV is almost entirely a map of the Netherlands with a few Nagios summaries and refresh counters underneath. The right TV pane lists the nagios detail and various business processes as well as open tickets from our ticket system. We use Chrome in kiosk mode, but Firefox could work too. Cheers, Seth From jra at baylink.com Wed Feb 13 15:47:30 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 13 Feb 2013 10:47:30 -0500 (EST) Subject: Muni fiber: L1 or L2? In-Reply-To: <511B9610.70402@necom830.hpcl.titech.ac.jp> Message-ID: <30654601.6023.1360770450486.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Masataka Ohta" > If you can't accept the shown reality that PON is more expensive > than SS and insist on stating it were my opinion without any > evidences, its your arrogance. > > PERIOD. Nope. It's you, dude. Really. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From Jason_Livingood at cable.comcast.com Wed Feb 13 16:33:48 2013 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Wed, 13 Feb 2013 16:33:48 +0000 Subject: IPv6 support by wifi systems In-Reply-To: Message-ID: <10229F86C86EB444898E629583FD41716160BB3C@PACDCEXMB06.cable.comcast.com> Access point support from many vendors seems okay. But another vendor gap on IPv6 is WiFi AAA, policy servers, and tunnel servers from vendors like Ericsson and ALU. I hope to see richer IPv6 support for these aspects of WiFi (helpful for those operating lots of outdoor WiFi systems for example). Jason On 2/11/13 11:23 PM, "Brandon Ross" wrote: >Like so many things IPv6, many of the wifi vendors seem to lack decent >support for IPv6 clients. I'm not sure why I thought the situation was >better than it seems to be, I guess I'm just an optimist. > >Anyway, what wifi vendors provide the best support for IPv6? I don't >really care too much about management, but to deploy wifi in a service >provider environment with IPv6, it would seem that you'd want at least: > >RA Guard >DHCPv6 Shield (unless you just do SLAAC, I guess) >IPv6 Source Address Guard > >Am I missing anything critical? > >-- >Brandon Ross Yahoo & AIM: >BrandonNRoss >+1-404-635-6667 ICQ: >2269442 >Schedule a meeting: https://doodle.com/bross Skype: >brandonross > From edward.dore at freethought-internet.co.uk Wed Feb 13 17:30:01 2013 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Wed, 13 Feb 2013 17:30:01 +0000 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> <511AC8D2.4060601@necom830.hpcl.titech.ac.jp> Message-ID: <2BD016DC-3F62-4B31-AAE3-F7B031DFA714@freethought-internet.co.uk> Sadly, despite this being challenged with both the telecoms regulator (Ofcom) and advertising watchdog (ASA), for some reason both seem pretty happy with the utter farce that is advertising BT/OpenReach's VDSL based Fibre To The Cabinet and Virgin Media's Hybrid Fibre Coax networks as "fibre optic broadband". We have a very small amount of Fibre To The Home/Fibre To The Premise being deployed by BT/Openreach using some kind of PON technology, but I'm not sure which variant off-hand. We were supposed to be getting FTTP where I live last March, but for some reason BT silently scrapped that plan and now we are getting FTTC this March apparently... I'm not going to hold my breath though! Edward Dore Freethought Internet On 13 Feb 2013, at 15:07, Mike Jones wrote: > On 13 February 2013 12:34, Scott Helms wrote: >> Using the UK as a model for US and Canadian deployments is a fallacy. > > I don't believe anyone was looking at the UK model? But now that you > mention it the UK has a rather interesting model for fibre deployment, > a significant portion of the country has "fibre optic broadband" > avaliable from multiple providers. > > BT Openreach (and others on their infrastructure) offer "Fibre Optic > Broadband" over twisted pair, and VirginMedia offer "Fibre Optic > Broadband" over coax. > > The UKs 'just pretend it's fibre' deployment method is cheaper than > both PON and SS. Only requirement is that you have a regulator that > doesn't care when companies flat out lie to customers. > > - Mike > From mike at mtcc.com Wed Feb 13 17:40:42 2013 From: mike at mtcc.com (Michael Thomas) Date: Wed, 13 Feb 2013 09:40:42 -0800 Subject: home network monitoring and shaping In-Reply-To: References: <511ABA76.8040003@mtcc.com> <511AD9EB.3070101@talkunafraid.co.uk> Message-ID: <511BD01A.6040502@mtcc.com> On 02/12/2013 04:46 PM, Joel Maslak wrote: > Large buffers have broken the average home internet. I can't tell you how > many people are astonished when I say "one of your family members > downloading a huge Microsoft ISO image (via TCP or other congestion-aware > algorithm) shouldn't even be noticed by another family member doing web > browsing. If it is noticed, the network is broke. Even if it's at the end > of a slow DSL line." This is true only to a point: if you have 5 people streaming movies on a 2 people broadband you're going to have problems regardless of the queuing discipline. That said, it's pretty awful that in this day and age that router vendors can't be bothered to set the default linux kernel queuing parameters to something reasonable. In any case, my point was really about wanting to deal with what happens when your isp bandwidth is saturated and being able to track it down and/or kill off the offenders. I haven't bought a router in the last year or two as "apps" have become de rigueur, but it sure seems like it would be nice to be able to do that. I'm pretty sure that I still can't (= being a dumb consumer, not a net geek jockey), but would like to hear otherwise. Mike From knife at toaster.net Wed Feb 13 18:50:50 2013 From: knife at toaster.net (Sean Lazar) Date: Wed, 13 Feb 2013 10:50:50 -0800 Subject: home network monitoring and shaping In-Reply-To: <511BD01A.6040502@mtcc.com> References: <511ABA76.8040003@mtcc.com> <511AD9EB.3070101@talkunafraid.co.uk> <511BD01A.6040502@mtcc.com> Message-ID: <511BE08A.4020506@toaster.net> I've had good luck with a via mini ITX board and http://ipcop.org/ This was in 2005 so things may have changed/progressed. It wasn't hard to give out some static dhcp leases and look at graphs and see who the bandwidth piggies were, and then set some throttling. Housemates weren't kicking down any money for the DSL line and running p2p sharing apps... Not good for latency sensitive gaming! Sean On 2/13/13 9:40 AM, Michael Thomas wrote: > On 02/12/2013 04:46 PM, Joel Maslak wrote: >> Large buffers have broken the average home internet. I can't tell >> you how >> many people are astonished when I say "one of your family members >> downloading a huge Microsoft ISO image (via TCP or other >> congestion-aware >> algorithm) shouldn't even be noticed by another family member doing web >> browsing. If it is noticed, the network is broke. Even if it's at >> the end >> of a slow DSL line." > > This is true only to a point: if you have 5 people streaming movies > on a 2 people broadband you're going to have problems regardless of > the queuing discipline. That said, it's pretty awful that in this day and > age that router vendors can't be bothered to set the default linux kernel > queuing parameters to something reasonable. > > In any case, my point was really about wanting to deal with what happens > when your isp bandwidth is saturated and being able to track it down > and/or > kill off the offenders. I haven't bought a router in the last year or > two as > "apps" have become de rigueur, but it sure seems like it would be nice to > be able to do that. I'm pretty sure that I still can't (= being a dumb > consumer, > not a net geek jockey), but would like to hear otherwise. > > Mike > > From brian.peter.dickson at gmail.com Wed Feb 13 19:19:59 2013 From: brian.peter.dickson at gmail.com (Brian Dickson) Date: Wed, 13 Feb 2013 14:19:59 -0500 Subject: puck.nether.net outage? Message-ID: Anyone know about puck.nether.net? I read the "outages" list via web archive there, but can't connect currently. (I know - irony or what.) If you know what's going on, please post on NANOG? kthanks, Brian From excelsio at gmx.com Wed Feb 13 19:39:39 2013 From: excelsio at gmx.com (excelsio at gmx.com) Date: Wed, 13 Feb 2013 20:39:39 +0100 Subject: IPv6 support by wifi systems In-Reply-To: References: Message-ID: <511BEBFB.4030706@gmx.com> Rather old document from 2010: Cisco + IPv6 over CAPWAP protocol: http://d2zmdbbm9feqrf.cloudfront.net/2012/usa/pdf/BRKEWN-2010.pdf From jra at baylink.com Wed Feb 13 19:54:27 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 13 Feb 2013 14:54:27 -0500 Subject: puck.nether.net outage? In-Reply-To: References: Message-ID: <727c6be7-4e17-4c81-ba27-2362f0354107@email.android.com> Checking; thanks. - jra Brian Dickson wrote: >Anyone know about puck.nether.net? > >I read the "outages" list via web archive there, but can't connect >currently. > >(I know - irony or what.) > >If you know what's going on, please post on NANOG? > >kthanks, > >Brian -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From morrowc.lists at gmail.com Wed Feb 13 20:08:26 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 13 Feb 2013 15:08:26 -0500 Subject: puck.nether.net outage? In-Reply-To: <727c6be7-4e17-4c81-ba27-2362f0354107@email.android.com> References: <727c6be7-4e17-4c81-ba27-2362f0354107@email.android.com> Message-ID: wait, email outages! wait! :) apparently jared's working on it. On Wed, Feb 13, 2013 at 2:54 PM, Jay Ashworth wrote: > Checking; thanks. > - jra > > Brian Dickson wrote: > >>Anyone know about puck.nether.net? >> >>I read the "outages" list via web archive there, but can't connect >>currently. >> >>(I know - irony or what.) >> >>If you know what's going on, please post on NANOG? >> >>kthanks, >> >>Brian > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. From morrowc.lists at gmail.com Wed Feb 13 20:09:23 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 13 Feb 2013 15:09:23 -0500 Subject: puck.nether.net outage? In-Reply-To: References: <727c6be7-4e17-4c81-ba27-2362f0354107@email.android.com> Message-ID: On Wed, Feb 13, 2013 at 3:08 PM, Christopher Morrow wrote: > wait, email outages! wait! :) > > apparently jared's working on it. oh sorry,. 'whats going on' == zombie attack... > On Wed, Feb 13, 2013 at 2:54 PM, Jay Ashworth wrote: >> Checking; thanks. >> - jra >> >> Brian Dickson wrote: >> >>>Anyone know about puck.nether.net? >>> >>>I read the "outages" list via web archive there, but can't connect >>>currently. >>> >>>(I know - irony or what.) >>> >>>If you know what's going on, please post on NANOG? >>> >>>kthanks, >>> >>>Brian >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. From morrowc.lists at gmail.com Wed Feb 13 20:31:00 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 13 Feb 2013 15:31:00 -0500 Subject: puck.nether.net outage? In-Reply-To: References: <727c6be7-4e17-4c81-ba27-2362f0354107@email.android.com> Message-ID: On Wed, Feb 13, 2013 at 3:09 PM, Christopher Morrow wrote: >> >> apparently jared's working on it. sorry, also: "should be better later today" is the update... From calin.chiorean at secdisk.net Wed Feb 13 20:51:58 2013 From: calin.chiorean at secdisk.net (Calin Chiorean) Date: Wed, 13 Feb 2013 21:51:58 +0100 Subject: NOC display software In-Reply-To: Message-ID: Hello, This should also work and can be customised however you want: http://pastebin.com/ty324mr8 I did add a test version at http://atl.ezeea.com/rotate.html just to check it if you want. HTH, Calin On 2/13/13 4:19 PM, "JoeSox" wrote: >Just wondering if anyone can recommend Windows software (it could be >Linux too but I might need to create a separate host for that >configuration) >that enables rotating [on one monitor] several webpages (dashboards) >or windows (application dashboards). >It would be nice if it was freeware or open source but whatever works >best is what I am looking for. >For example, if I wanted one monitor to cycle thru my local SolarWinds >Orion, Office 365 Health Status, and anyother webdashboards. > >-- >Thank You, Joe > From jjn at nuge.com Wed Feb 13 21:00:31 2013 From: jjn at nuge.com (Jay Nugent) Date: Wed, 13 Feb 2013 16:00:31 -0500 (EST) Subject: puck.nether.net outage? In-Reply-To: References: <727c6be7-4e17-4c81-ba27-2362f0354107@email.android.com> Message-ID: Greetings, On Wed, 13 Feb 2013, Christopher Morrow wrote: > On Wed, Feb 13, 2013 at 3:09 PM, Christopher Morrow > wrote: >>> >>> apparently jared's working on it. > > sorry, also: "should be better later today" > is the update... Or the term we used at the ANS NOC (internally, of course) was: "It be broke. We be fixin' it" --- Jay Nugent NSFnet/ANSnet 1992-1998 From livio.zanol.puppim at gmail.com Wed Feb 13 22:16:30 2013 From: livio.zanol.puppim at gmail.com (Livio Zanol Puppim) Date: Wed, 13 Feb 2013 20:16:30 -0200 Subject: NOC display software In-Reply-To: References: Message-ID: You can do this using Javascript as well... 2013/2/13 Calin Chiorean > Hello, > > This should also work and can be customised however you want: > > http://pastebin.com/ty324mr8 > > I did add a test version at http://atl.ezeea.com/rotate.html just to check > it if you want. > > HTH, > Calin > > On 2/13/13 4:19 PM, "JoeSox" wrote: > > >Just wondering if anyone can recommend Windows software (it could be > >Linux too but I might need to create a separate host for that > >configuration) > >that enables rotating [on one monitor] several webpages (dashboards) > >or windows (application dashboards). > >It would be nice if it was freeware or open source but whatever works > >best is what I am looking for. > >For example, if I wanted one monitor to cycle thru my local SolarWinds > >Orion, Office 365 Health Status, and anyother webdashboards. > > > >-- > >Thank You, Joe > > > > > > > -- []'s L?vio Zanol Puppim From chipps at chipps.com Wed Feb 13 22:22:34 2013 From: chipps at chipps.com (Kenneth M. Chipps Ph.D.) Date: Wed, 13 Feb 2013 16:22:34 -0600 Subject: NOC display software In-Reply-To: References: Message-ID: <00ff01ce0a38$9f8c2010$dea46030$@chipps.com> I use a VBScript that just ALT Tabs to go from screen to screen. -----Original Message----- From: Livio Zanol Puppim [mailto:livio.zanol.puppim at gmail.com] Sent: Wednesday, February 13, 2013 4:17 PM To: Calin Chiorean Cc: nanog at nanog.org Subject: Re: NOC display software You can do this using Javascript as well... 2013/2/13 Calin Chiorean > Hello, > > This should also work and can be customised however you want: > > http://pastebin.com/ty324mr8 > > I did add a test version at http://atl.ezeea.com/rotate.html just to > check it if you want. > > HTH, > Calin > > On 2/13/13 4:19 PM, "JoeSox" wrote: > > >Just wondering if anyone can recommend Windows software (it could be > >Linux too but I might need to create a separate host for that > >configuration) > >that enables rotating [on one monitor] several webpages (dashboards) > >or windows (application dashboards). > >It would be nice if it was freeware or open source but whatever works > >best is what I am looking for. > >For example, if I wanted one monitor to cycle thru my local > >SolarWinds Orion, Office 365 Health Status, and anyother webdashboards. > > > >-- > >Thank You, Joe > > > > > > > -- []'s L?vio Zanol Puppim From sparctacus at gmail.com Wed Feb 13 23:51:50 2013 From: sparctacus at gmail.com (Bryan Irvine) Date: Wed, 13 Feb 2013 15:51:50 -0800 Subject: NOC display software In-Reply-To: References: Message-ID: On Wed, Feb 13, 2013 at 7:19 AM, JoeSox wrote: > Just wondering if anyone can recommend Windows software (it could be > Linux too but I might need to create a separate host for that > configuration) > that enables rotating [on one monitor] several webpages (dashboards) > or windows (application dashboards). > It would be nice if it was freeware or open source but whatever works > best is what I am looking for. > For example, if I wanted one monitor to cycle thru my local SolarWinds > Orion, Office 365 Health Status, and anyother webdashboards. Tab Mix Plus is the one that I use for that. https://addons.mozilla.org/en-us/firefox/addon/tab-mix-plus/ From mohta at necom830.hpcl.titech.ac.jp Thu Feb 14 01:13:46 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Thu, 14 Feb 2013 10:13:46 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: <2BD016DC-3F62-4B31-AAE3-F7B031DFA714@freethought-internet.co.uk> References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> <511AC8D2.4060601@necom830.hpcl.titech.ac.jp> <2BD016DC-3F62-4B31-AAE3-F7B031DFA714@freethought-internet.co.uk> Message-ID: <511C3A4A.7050401@necom830.hpcl.titech.ac.jp> Edward Dore wrote: > Sadly, despite this being challenged with both the telecoms > regulator (Ofcom) and advertising watchdog (ASA), for some > reason both seem pretty happy with the utter farce that is > advertising BT/OpenReach's VDSL based Fibre To The Cabinet > and Virgin Media's Hybrid Fibre Coax networks as "fibre > optic broadband". Sadly, it is impossible to say FTTC not "fiber optic broadband", because it is "broadband" (at least with today's access speed) with "fiber optic". > We were supposed to be getting FTTP where I live last March, > but for some reason BT silently scrapped that plan and now we > are getting FTTC this March apparently... Obviously because it makes L1 unbundling difficult. Masataka Ohta From marka at isc.org Thu Feb 14 01:23:54 2013 From: marka at isc.org (Mark Andrews) Date: Thu, 14 Feb 2013 12:23:54 +1100 Subject: Muni fiber: L1 or L2? In-Reply-To: Your message of "Thu, 14 Feb 2013 10:13:46 +0900." <511C3A4A.7050401@necom830.hpcl.titech.ac.jp> References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> <511AC8D2.4060601@necom830.hpcl.titech.ac.jp> <2BD016DC-3F62-4B31-AAE3-F7B031DFA714@freethought-internet.co.uk> <511C3A4A.7050401@necom830.hpcl.titech.ac.jp> Message-ID: <20130214012354.C51042F91778@drugs.dv.isc.org> In message <511C3A4A.7050401 at necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Edward Dore wrote: > > > Sadly, despite this being challenged with both the telecoms > > regulator (Ofcom) and advertising watchdog (ASA), for some > > reason both seem pretty happy with the utter farce that is > > advertising BT/OpenReach's VDSL based Fibre To The Cabinet > > and Virgin Media's Hybrid Fibre Coax networks as "fibre > > optic broadband". > > Sadly, it is impossible to say FTTC not "fiber optic broadband", > because it is "broadband" (at least with today's access speed) > with "fiber optic". And by that argument pots dialup is fiber optic because the packets went over a fiber optic link to get to the CO. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From wbailey at satelliteintelligencegroup.com Thu Feb 14 01:44:07 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 14 Feb 2013 01:44:07 +0000 Subject: Muni fiber: L1 or L2? In-Reply-To: <20130214012354.C51042F91778@drugs.dv.isc.org> References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> <511AC8D2.4060601@necom830.hpcl.titech.ac.jp> <2BD016DC-3F62-4B31-AAE3-F7B031DFA714@freethought-internet.co.uk> <511C3A4A.7050401@necom830.hpcl.titech.ac.jp>, <20130214012354.C51042F91778@drugs.dv.isc.org> Message-ID: Game. Blouses. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Mark Andrews Date: 02/13/2013 5:25 PM (GMT-08:00) To: Masataka Ohta Cc: nanog at nanog.org Subject: Re: Muni fiber: L1 or L2? In message <511C3A4A.7050401 at necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Edward Dore wrote: > > > Sadly, despite this being challenged with both the telecoms > > regulator (Ofcom) and advertising watchdog (ASA), for some > > reason both seem pretty happy with the utter farce that is > > advertising BT/OpenReach's VDSL based Fibre To The Cabinet > > and Virgin Media's Hybrid Fibre Coax networks as "fibre > > optic broadband". > > Sadly, it is impossible to say FTTC not "fiber optic broadband", > because it is "broadband" (at least with today's access speed) > with "fiber optic". And by that argument pots dialup is fiber optic because the packets went over a fiber optic link to get to the CO. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From courtneysmith at comcast.net Thu Feb 14 02:19:07 2013 From: courtneysmith at comcast.net (Courtney Smith) Date: Wed, 13 Feb 2013 21:19:07 -0500 Subject: NANOG Digest, Vol 61, Issue 88 In-Reply-To: References: Message-ID: On Feb 13, 2013, at 4:00 PM, nanog-request at nanog.org wrote: > ------------------------------ > > Message: 3 > Date: Wed, 13 Feb 2013 10:50:50 -0800 > From: Sean Lazar > To: Michael Thomas > Cc: NANOG list > Subject: Re: home network monitoring and shaping > Message-ID: <511BE08A.4020506 at toaster.net> > Content-Type: text/plain; charset=ISO-8859-1 > > I've had good luck with a via mini ITX board and http://ipcop.org/ > > Anyone have good experience addressing this with TomatoUSB's QoS features? Specifically the Toastman builds. Courtney Smith courtneysmith at comcast.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From jared at puck.nether.net Thu Feb 14 03:41:10 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 13 Feb 2013 22:41:10 -0500 Subject: puck.nether.net outage? In-Reply-To: References: <727c6be7-4e17-4c81-ba27-2362f0354107@email.android.com> Message-ID: <0A4C94CA-4382-4386-8F56-2BED001CFC90@puck.nether.net> On Feb 13, 2013, at 4:00 PM, Jay Nugent wrote: > Greetings, > > On Wed, 13 Feb 2013, Christopher Morrow wrote: > >> On Wed, Feb 13, 2013 at 3:09 PM, Christopher Morrow >> wrote: >>>> >>>> apparently jared's working on it. >> >> sorry, also: "should be better later today" >> is the update... > > Or the term we used at the ANS NOC (internally, of course) was: > > "It be broke. We be fixin' it" http://www.youtube.com/watch?v=1D1cap6yETA If you notice something broken, *please* email me in private. I likely will be writing up a blog post or something about this? - Jared From deric.kwok2000 at gmail.com Thu Feb 14 13:02:12 2013 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Thu, 14 Feb 2013 08:02:12 -0500 Subject: bgp for ipv6 question Message-ID: Hi all Can I know how many ipv6 full bgp table routes now? how many memory can run one ipv6 full bgp table? how many peer for ipv6 in Router reflector you suggest? Do you suggest to separate the ipv4 and ipv6 in router reflector? Thank you for your info From jared at puck.nether.net Thu Feb 14 13:08:26 2013 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 14 Feb 2013 08:08:26 -0500 Subject: bgp for ipv6 question In-Reply-To: References: Message-ID: <3DEBAB6A-63EA-48ED-B6FB-8CF30A920918@puck.nether.net> On Feb 14, 2013, at 8:02 AM, Deric Kwok wrote: > Hi all > > Can I know how many ipv6 full bgp table routes now? Right now there are about 15k routes. > how many memory can run one ipv6 full bgp table? This depends on the platform. > how many peer for ipv6 in Router reflector you suggest? This depends on your architecture. > Do you suggest to separate the ipv4 and ipv6 in router reflector? I recommend keeping your network as congruent between IPv4 and IPv6 as possible, with dual-stack. - Jared From fredan-nanog at fredan.se Thu Feb 14 13:19:23 2013 From: fredan-nanog at fredan.se (fredrik danerklint) Date: Thu, 14 Feb 2013 14:19:23 +0100 Subject: bgp for ipv6 question In-Reply-To: <3DEBAB6A-63EA-48ED-B6FB-8CF30A920918@puck.nether.net> References: <3DEBAB6A-63EA-48ED-B6FB-8CF30A920918@puck.nether.net> Message-ID: <511CE45B.90109@fredan.se> >> Can I know how many ipv6 full bgp table routes now? > > Right now there are about 15k routes. 8k when you filter based on IRR. -- //fredan The Last Mile Cache - http://tlmc.fredan.se From ahebert at pubnix.net Thu Feb 14 13:40:09 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Thu, 14 Feb 2013 08:40:09 -0500 Subject: bgp for ipv6 question In-Reply-To: <511CE45B.90109@fredan.se> References: <3DEBAB6A-63EA-48ED-B6FB-8CF30A920918@puck.nether.net> <511CE45B.90109@fredan.se> Message-ID: <511CE939.3080807@pubnix.net> Not based of IRR =D Foundry CER2K 12111 BGP Number of Neighbors Configured: 7, UP: 5 Number of Routes Installed: 22866, Uses 1966476 bytes Number of Routes Advertising to All Neighbors: 53961 (41844 entries), Uses 2008512 bytes Number of Attribute Entries Installed: 22746, Uses 2047140 bytes Number of Neighbors Configured: 6, UP: 5 Number of Routes Installed: 40326, Uses 3468036 bytes Number of Routes Advertising to All Neighbors: 34987 (34987 entries), Uses 1679376 bytes Number of Attribute Entries Installed: 31290, Uses 2816100 bytes ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 02/14/13 08:19, fredrik danerklint wrote: >>> Can I know how many ipv6 full bgp table routes now? >> >> Right now there are about 15k routes. > > 8k when you filter based on IRR. > From job.snijders at atrato.com Thu Feb 14 13:42:45 2013 From: job.snijders at atrato.com (Job Snijders) Date: Thu, 14 Feb 2013 14:42:45 +0100 Subject: bgp for ipv6 question In-Reply-To: References: Message-ID: <55798995-7851-4D66-8518-E1B20043F77A@atrato.com> Hi, On Feb 14, 2013, at 2:02 PM, Deric Kwok wrote: > Can I know how many ipv6 full bgp table routes now? Here are various sources to discover the size of the IPv6 internet routing table: http://public01.infra.ring.nlnog.net/munin/infra.ring.nlnog.net/lg01.infra.ring.nlnog.net/bird6.html http://bgp.potaroo.net/v6/as2.0/index.html http://bgp.potaroo.net/v6/as6447/ Kind regards, Job From dhubbard at dino.hostasaurus.com Thu Feb 14 19:58:38 2013 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Thu, 14 Feb 2013 14:58:38 -0500 Subject: Suggestions for managed DNS provider? Message-ID: Hi all, anyone have suggestions for very stable/reliable managed DNS? Neustar/UltraDNS is an obvious option to look at, just curious about alternatives. Cost effective would be nice, but stable under attack is better. Thanks, David From rubensk at gmail.com Thu Feb 14 20:06:13 2013 From: rubensk at gmail.com (Rubens Kuhl) Date: Thu, 14 Feb 2013 18:06:13 -0200 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: On Thu, Feb 14, 2013 at 5:58 PM, David Hubbard wrote: > Hi all, anyone have suggestions for very stable/reliable managed DNS? > Neustar/UltraDNS is an obvious option to look at, just curious about > alternatives. Cost effective would be nice, but stable under attack is > better. Not tested under attack, but this DNS provider is worth a look since it's the only one with both IPv6 and DNSSEC a colleague could find: http://www.dnsunlimited.com/ Rubens From eyeronic.design at gmail.com Thu Feb 14 20:08:21 2013 From: eyeronic.design at gmail.com (Mike Hale) Date: Thu, 14 Feb 2013 12:08:21 -0800 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: DynDNS was pretty decent for us. We had a fair amount of load with them and they handled it with no problem. On Thu, Feb 14, 2013 at 11:58 AM, David Hubbard wrote: > Hi all, anyone have suggestions for very stable/reliable managed DNS? > Neustar/UltraDNS is an obvious option to look at, just curious about > alternatives. Cost effective would be nice, but stable under attack is > better. > > Thanks, > > David > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From jna at retina.net Thu Feb 14 20:31:08 2013 From: jna at retina.net (John Adams) Date: Thu, 14 Feb 2013 12:31:08 -0800 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: I'm extremely happy with Dyn, for both personal and work (Twitter.) Their staff is fantastic and great to deal with. -j On Thu, Feb 14, 2013 at 12:08 PM, Mike Hale wrote: > DynDNS was pretty decent for us. We had a fair amount of load with > them and they handled it with no problem. > > On Thu, Feb 14, 2013 at 11:58 AM, David Hubbard > wrote: > > Hi all, anyone have suggestions for very stable/reliable managed DNS? > > Neustar/UltraDNS is an obvious option to look at, just curious about > > alternatives. Cost effective would be nice, but stable under attack is > > better. > > > > Thanks, > > > > David > > > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > > From mureninc at gmail.com Thu Feb 14 20:32:43 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Thu, 14 Feb 2013 12:32:43 -0800 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: On 14 February 2013 11:58, David Hubbard wrote: > Hi all, anyone have suggestions for very stable/reliable managed DNS? > Neustar/UltraDNS is an obvious option to look at, just curious about > alternatives. Cost effective would be nice, but stable under attack is > better. Not sure about attacks, or what exactly "managed DNS" is, but dns.he.net. is a very nice service, with many anycast servers in many of their POPs. The ns1.he.net. is an IPv4 unicast in Fremont, but ns{2,3,4,5}.he.net. are all anycast on both IPv4 and IPv6, usually to different locations (HKG, FMT, SJC, PAO, LAX, NYC, LON, FRA, AMS are just some of the locations I've seen), depending on where you're at. Linode also lets you use their DNS infrastructure without any restrictions as long as you're a Linode customer (they have 5 independent unicast IPv4/IPv6 servers, 4 in US, 1 in UK). C. From smeuse at mara.org Thu Feb 14 20:44:03 2013 From: smeuse at mara.org (Steve Meuse) Date: Thu, 14 Feb 2013 15:44:03 -0500 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: On Thu, Feb 14, 2013 at 3:08 PM, Mike Hale wrote: > DynDNS was pretty decent for us. We had a fair amount of load with > them and they handled it with no problem. > > +1 Great company.... -Steve From jnegro at advance.net Thu Feb 14 20:29:38 2013 From: jnegro at advance.net (Jeffrey Negro) Date: Thu, 14 Feb 2013 20:29:38 +0000 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: Hi David - We use DynDNS at my company, and we're very happy with it. I've also used DNSMadeEasy at previous companies and found them to be rock solid and very affordable. I think about two years or so ago, they survived a full on botnet DDoS attack with no service outage - which my monitoring at the time confirmed as well. Hope that helps! --Jeffrey On Thu, Feb 14, 2013 at 5:58 PM, David Hubbard wrote: > Hi all, anyone have suggestions for very stable/reliable managed DNS? > Neustar/UltraDNS is an obvious option to look at, just curious about > alternatives. Cost effective would be nice, but stable under attack > is better. ------------------------------------------------------------------------------------------------ This e-mail, including attachments, is intended for the person(s) or company named and may contain confidential and/or legally privileged information. Unauthorized disclosure, copying or use of this information may be unlawful and is prohibited. If you are not the intended recipient, please delete this message and notify the sender. From Petter.Bruland at allegiantair.com Thu Feb 14 20:41:37 2013 From: Petter.Bruland at allegiantair.com (Petter Bruland) Date: Thu, 14 Feb 2013 20:41:37 +0000 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: Agree with John, Dyn are awesome. - Register your external IP with a Dyn account, and start controlling which site categories or custom URL lists to allow/block. - Get very good reports of which sites are popular - Get reports of DNS requests for "known" bad sites -Petter -----Original Message----- From: John Adams [mailto:jna at retina.net] Sent: Thursday, February 14, 2013 12:31 PM To: Mike Hale Cc: NANOG Operators' Group Subject: Re: Suggestions for managed DNS provider? I'm extremely happy with Dyn, for both personal and work (Twitter.) Their staff is fantastic and great to deal with. -j On Thu, Feb 14, 2013 at 12:08 PM, Mike Hale wrote: > DynDNS was pretty decent for us. We had a fair amount of load with > them and they handled it with no problem. > > On Thu, Feb 14, 2013 at 11:58 AM, David Hubbard > wrote: > > Hi all, anyone have suggestions for very stable/reliable managed DNS? > > Neustar/UltraDNS is an obvious option to look at, just curious about > > alternatives. Cost effective would be nice, but stable under attack > > is better. > > > > Thanks, > > > > David > > > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > > From karim.adel at gmail.com Thu Feb 14 20:52:09 2013 From: karim.adel at gmail.com (Kasper Adel) Date: Thu, 14 Feb 2013 12:52:09 -0800 Subject: Quantifying the value of customer support Message-ID: Hello, We are a 2nd level of escalation in a service provider, trying to put a $ value on the support we give to our NOC and other implementation teams, when they email us about problems they face. But we are merely bits and bytes engineers that cant quantify and justify the value of what we do to the management team. I guess these smart suits want to see an excel sheet with a table of how much they save or gain by the support we do. We respond to technical questions and simulate problems in a lab. Can anyone help me with an idea or any material i can reuse? Templates? Has any one been in a similar situation. Thanks Kim From kauer at biplane.com.au Thu Feb 14 20:58:10 2013 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 15 Feb 2013 07:58:10 +1100 Subject: bgp for ipv6 question In-Reply-To: <3DEBAB6A-63EA-48ED-B6FB-8CF30A920918@puck.nether.net> References: <3DEBAB6A-63EA-48ED-B6FB-8CF30A920918@puck.nether.net> Message-ID: <1360875490.2832.1.camel@karl> On Thu, 2013-02-14 at 08:08 -0500, Jared Mauch wrote: > I recommend keeping your network as congruent between IPv4 and IPv6 as possible, with dual-stack. Why? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 From l-nanog at iodi.se Thu Feb 14 21:03:36 2013 From: l-nanog at iodi.se (Joseph Chin) Date: Thu, 14 Feb 2013 21:03:36 -0000 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: <056301ce0af6$c2ca1820$485e4860$@iodi.se> I have been a big fan of CommunityDNS cdns.net for many years. Their infrastructure is very robust and the prices very reasonable too. If there is anything that needs improvement, it would be their draconian reporting tool. Otherwise, it is hard to beat them for no non-sense reasonably priced DNS hosting. -----Original Message----- From: David Hubbard [mailto:dhubbard at dino.hostasaurus.com] Sent: Thursday, February 14, 2013 7:59 PM To: nanog at nanog.org Subject: Suggestions for managed DNS provider? Hi all, anyone have suggestions for very stable/reliable managed DNS? Neustar/UltraDNS is an obvious option to look at, just curious about alternatives. Cost effective would be nice, but stable under attack is better. Thanks, David From lathama at gmail.com Thu Feb 14 21:05:27 2013 From: lathama at gmail.com (Andrew Latham) Date: Thu, 14 Feb 2013 16:05:27 -0500 Subject: Quantifying the value of customer support In-Reply-To: References: Message-ID: On Thu, Feb 14, 2013 at 3:52 PM, Kasper Adel wrote: > Hello, > > We are a 2nd level of escalation in a service provider, trying to put a $ > value on the support we give to our NOC and other implementation teams, > when they email us about problems they face. But we are merely bits and > bytes engineers that cant quantify and justify the value of what we do to > the management team. I guess these smart suits want to see an excel sheet > with a table of how much they save or gain by the support we do. We respond > to technical questions and simulate problems in a lab. > > Can anyone help me with an idea or any material i can reuse? Templates? Has > any one been in a similar situation. > > Thanks > Kim Kasper/Karim/Kim Your job is customer retention. Your value is maintaining all company income. Write the yearly revenue on a piece of paper and hand it to them. -- ~ Andrew "lathama" Latham lathama at gmail.com http://lathama.net ~ From j at 2600hz.com Thu Feb 14 21:09:11 2013 From: j at 2600hz.com (Joshua Goldbard) Date: Thu, 14 Feb 2013 21:09:11 +0000 Subject: Quantifying the value of customer support In-Reply-To: References: Message-ID: Hey, So usually this is done by the business unit leaders. At AT&T people used to call it "pushing the wastebasket". The idea is that each department runs as a separate business and in order to evaluate the business you debit and credit departments as if they were counterparties in a trade. Someone usually ends up on the outside looking in. Typically, for call centers, this evaluation is done on a cases handled versus calls placed manner with time/$ values associated with every ticket. Tier 2 support costs more per person than tier 1. If tier 2 doesn't actually speed or reduce call traffic, there's no point in having a tier 2. Now, as one might imagine, there is a great deal of subjectivity in these numbers. Many teams try to tackle this by dividing salaries by hours on the phone. This can hide a lot of the value of tier 2 as the whole point is to eliminate extra time someone would've spent in tier 1 looking for the answer. Your challenge is to quantify how much time you're saving and multiply it by your salary per hour number. That's a good place to start. Cheers, Joshua Sent from my iPhone On Feb 14, 2013, at 12:59 PM, "Kasper Adel" wrote: > Hello, > > We are a 2nd level of escalation in a service provider, trying to put a $ > value on the support we give to our NOC and other implementation teams, > when they email us about problems they face. But we are merely bits and > bytes engineers that cant quantify and justify the value of what we do to > the management team. I guess these smart suits want to see an excel sheet > with a table of how much they save or gain by the support we do. We respond > to technical questions and simulate problems in a lab. > > Can anyone help me with an idea or any material i can reuse? Templates? Has > any one been in a similar situation. > > Thanks > Kim From karim.adel at gmail.com Thu Feb 14 21:16:05 2013 From: karim.adel at gmail.com (Kasper Adel) Date: Thu, 14 Feb 2013 13:16:05 -0800 Subject: Quantifying the value of customer support In-Reply-To: References: Message-ID: I used to think that these kind of situations take place when a manager was never an engineer so he does not understand how things work but i was surprised when i faced these from managers with an intense engineering career so i gave up on trying to give conceptual excuses and want to just give them the dump tables and numbers that they are looking for. Kim On Thursday, February 14, 2013, Andrew Latham wrote: > On Thu, Feb 14, 2013 at 3:52 PM, Kasper Adel > > wrote: > > Hello, > > > > We are a 2nd level of escalation in a service provider, trying to put a $ > > value on the support we give to our NOC and other implementation teams, > > when they email us about problems they face. But we are merely bits and > > bytes engineers that cant quantify and justify the value of what we do to > > the management team. I guess these smart suits want to see an excel sheet > > with a table of how much they save or gain by the support we do. We > respond > > to technical questions and simulate problems in a lab. > > > > Can anyone help me with an idea or any material i can reuse? Templates? > Has > > any one been in a similar situation. > > > > Thanks > > Kim > > Kasper/Karim/Kim > > Your job is customer retention. Your value is maintaining all company > income. Write the yearly revenue on a piece of paper and hand it to > them. > > > -- > ~ Andrew "lathama" Latham lathama at gmail.com > http://lathama.net ~ > From ctassisf at gmail.com Thu Feb 14 21:00:52 2013 From: ctassisf at gmail.com (=?ISO-8859-1?Q?C=E9sar_de_Tassis_Filho?=) Date: Thu, 14 Feb 2013 19:00:52 -0200 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: Hi David, I don't know "what exactly 'managed DNS' is" too, but Amazon Route53is very reliable (but not cost effective) AFAIK. Rackspace also have "Free Cloud-Based DNS Management ", but I've never used it. You can find more information about "Free Secondary DNS" here . C?sar On Thu, Feb 14, 2013 at 6:29 PM, Jeffrey Negro wrote: > Hi David - We use DynDNS at my company, and we're very happy with it. > I've also used DNSMadeEasy at previous companies and found them to be rock > solid and very affordable. I think about two years or so ago, they > survived a full on botnet DDoS attack with no service outage - which my > monitoring at the time confirmed as well. > > Hope that helps! > > --Jeffrey > > > On Thu, Feb 14, 2013 at 5:58 PM, David Hubbard < > dhubbard at dino.hostasaurus.com> wrote: > > Hi all, anyone have suggestions for very stable/reliable managed DNS? > > Neustar/UltraDNS is an obvious option to look at, just curious about > > alternatives. Cost effective would be nice, but stable under attack > > is better. > > ------------------------------------------------------------------------------------------------ > This e-mail, including attachments, is intended for the person(s) > or company named and may contain confidential and/or legally > privileged information. Unauthorized disclosure, copying or use of > this information may be unlawful and is prohibited. If you are not > the intended recipient, please delete this message and notify the > sender. > > From owen at delong.com Thu Feb 14 21:18:24 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Feb 2013 13:18:24 -0800 Subject: bgp for ipv6 question In-Reply-To: <1360875490.2832.1.camel@karl> References: <3DEBAB6A-63EA-48ED-B6FB-8CF30A920918@puck.nether.net> <1360875490.2832.1.camel@karl> Message-ID: <48BD6E36-A9B8-43E8-ACAE-86B97E4BE344@delong.com> On Feb 14, 2013, at 12:58 , Karl Auer wrote: > On Thu, 2013-02-14 at 08:08 -0500, Jared Mauch wrote: >> I recommend keeping your network as congruent between IPv4 and IPv6 as possible, with dual-stack. > > Why? > For one thing, doing otherwise violates the principle of least astonishment. Other reasons include simplified network diagrams, improved reliability, easier troubleshooting, reduced complexity, and often lower costs of operations. Owen From SNaslund at medline.com Thu Feb 14 22:17:48 2013 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 14 Feb 2013 16:17:48 -0600 Subject: Quantifying the value of customer support In-Reply-To: References: Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0E67C026@MUNEXBE1.medline.com> I would think your $ value would be calculated by a few factors. 1. How much would it cost to train and hire NOC guys that do what you do today vs. using outsourced support for those issues or going to a higher level team. 2. How much longer would SLA affecting problems take to solve without you? 3. This one is tough, how many customer implementations would fail and how many customers would you lose due to the loss of technical expertise? A super simple calculation would be something like "we provided 10,000 hours of support and a consultant with similar skills would have cost X dollars" or if they would have escalated to an even higher level in your organization you have to calculate the cost of your hours vs the hours of more expensive engineers. A calculation you will probably not be able to make is if a higher engineering level than you had the time and resources to handle the same cases or if they would need more body count to do so. I can't tell what your $ value is without knowing the cost of not having you. I would think the best thing to respond with would be to take some of the cases you handled and find out what it would have taken to solve the problem if you had not been there. For example, I you provided three hours of help that no one else in your organization could have, you could calculate how much an outside consultant would have cost and how long it would have taken to retain that consultant. You will then be able to say that X project would have cost this much and taken this much longer. Bottom line is what is the cost of NOT having you. Steven Naslund -----Original Message----- From: Kasper Adel [mailto:karim.adel at gmail.com] Sent: Thursday, February 14, 2013 2:52 PM To: NANOG list Subject: Quantifying the value of customer support Hello, We are a 2nd level of escalation in a service provider, trying to put a $ value on the support we give to our NOC and other implementation teams, when they email us about problems they face. But we are merely bits and bytes engineers that cant quantify and justify the value of what we do to the management team. I guess these smart suits want to see an excel sheet with a table of how much they save or gain by the support we do. We respond to technical questions and simulate problems in a lab. Can anyone help me with an idea or any material i can reuse? Templates? Has any one been in a similar situation. Thanks Kim From mloftis at wgops.com Thu Feb 14 22:32:12 2013 From: mloftis at wgops.com (Michael Loftis) Date: Thu, 14 Feb 2013 14:32:12 -0800 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: On Thu, Feb 14, 2013 at 11:58 AM, David Hubbard wrote: > Hi all, anyone have suggestions for very stable/reliable managed DNS? > Neustar/UltraDNS is an obvious option to look at, just curious about > alternatives. Cost effective would be nice, but stable under attack is > better. It's not 100% clear what you mean here, resolvers or authoritative DNS, but, in either case, my suggestions are the same, OpenDNS has been reliable for me as a resolver service, and DynDNS (now just Dyn) has been great for authoritative and secondary nameservers for me. For authoritative nameservers I haven't looked for anything to deal with huge numbers of domains, just a few dozen. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From rodrick.brown at gmail.com Thu Feb 14 22:52:10 2013 From: rodrick.brown at gmail.com (Rodrick Brown) Date: Thu, 14 Feb 2013 17:52:10 -0500 Subject: Quantifying the value of customer support In-Reply-To: References: Message-ID: <6160114367141696973@unknownmsgid> On Feb 14, 2013, at 4:00 PM, Kasper Adel wrote: > Hello, > > We are a 2nd level of escalation in a service provider, trying to put a $ > value on the support we give to our NOC and other implementation teams, > when they email us about problems they face. But we are merely bits and > bytes engineers that cant quantify and justify the value of what we do to > the management team. I guess these smart suits want to see an excel sheet > with a table of how much they save or gain by the support we do. We respond > to technical questions and simulate problems in a lab. > > Can anyone help me with an idea or any material i can reuse? Templates? Has > any one been in a similar situation. Sounds like a job for the Bob's. > > Thanks > Kim From David.Siegel at Level3.com Thu Feb 14 23:09:34 2013 From: David.Siegel at Level3.com (Siegel, David) Date: Thu, 14 Feb 2013 23:09:34 +0000 Subject: Quantifying the value of customer support In-Reply-To: References: Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC0B5066A@USIDCWVEMBX10.corp.global.level3.com> There is no such thing as a generic business case that can be applied across all companies in an industry. Every business is unique in its product definition and organization structure, but each question is also unique and therefore the analysis must be done every time. The way to begin is to ask this manager what he believes the possible outcomes are (downsize your group, eliminate your group, re-define your group, etc.) and then work with each of the key stakeholders that you have to estimate the impact of those outcomes. For example, if 1st line operations indicates that eliminating your group would result in decreased customer satisfaction and missed SLA's, ask them to quantify it as much as possible and go to take the numbers back to your business people to have them estimate the impact on revenue. The analysis should be constructed and presented in standard finance terms (like NPV) so I would suggest that you make friends with someone in finance to assist you with the preparation. You can also take a short two-day course like this http://executive.mit.edu/openenrollment/program/fundamentals_of_finance_for_the_technical_executive/16 that will teach you how to build up these analysis yourself (I have taken the one referenced and I recommend it to all managers with budget responsibility). The outcome from these discussions often has surprising but positive outcomes for everyone...maintaining the status quo is not always the best possible outcome despite the biases we usually have when we begin the analysis. :-) If you work closely with all of your stakeholders, everyone will learn and benefit from the experience. Dave -----Original Message----- From: Kasper Adel [mailto:karim.adel at gmail.com] Sent: Thursday, February 14, 2013 2:16 PM To: Andrew Latham Cc: NANOG list Subject: Re: Quantifying the value of customer support I used to think that these kind of situations take place when a manager was never an engineer so he does not understand how things work but i was surprised when i faced these from managers with an intense engineering career so i gave up on trying to give conceptual excuses and want to just give them the dump tables and numbers that they are looking for. Kim On Thursday, February 14, 2013, Andrew Latham wrote: > On Thu, Feb 14, 2013 at 3:52 PM, Kasper Adel > > > wrote: > > Hello, > > > > We are a 2nd level of escalation in a service provider, trying to > > put a $ value on the support we give to our NOC and other > > implementation teams, when they email us about problems they face. > > But we are merely bits and bytes engineers that cant quantify and > > justify the value of what we do to the management team. I guess > > these smart suits want to see an excel sheet with a table of how > > much they save or gain by the support we do. We > respond > > to technical questions and simulate problems in a lab. > > > > Can anyone help me with an idea or any material i can reuse? Templates? > Has > > any one been in a similar situation. > > > > Thanks > > Kim > > Kasper/Karim/Kim > > Your job is customer retention. Your value is maintaining all company > income. Write the yearly revenue on a piece of paper and hand it to > them. > > > -- > ~ Andrew "lathama" Latham lathama at gmail.com > http://lathama.net ~ > From mohta at necom830.hpcl.titech.ac.jp Fri Feb 15 00:13:37 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 15 Feb 2013 09:13:37 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: <20130214012354.C51042F91778@drugs.dv.isc.org> References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> <511AC8D2.4060601@necom830.hpcl.titech.ac.jp> <2BD016DC-3F62-4B31-AAE3-F7B031DFA714@freethought-internet.co.uk> <511C3A4A.7050401@necom830.hpcl.titech.ac.jp> <20130214012354.C51042F91778@drugs.dv.isc.org> Message-ID: <511D7DB1.5040905@necom830.hpcl.titech.ac.jp> Mark Andrews wrote: >> Sadly, it is impossible to say FTTC not "fiber optic broadband", >> because it is "broadband" (at least with today's access speed) >> with "fiber optic". > > And by that argument pots dialup is fiber optic because the packets > went over a fiber optic link to get to the CO. Well, not pots, but, NTT was, against ADSL, advertising their 128Kbps ISDN dial up as "high speed Internet". So, 128Kbps dial up might have been "broadband" at that time at least for NTT, until, in late 2001, Japanese government defined "high speed Internet access network" access network to be able to smoothly download music data etc. with examples of xDSL, CATV and Wifi. Masataka Ohta From woody at pch.net Fri Feb 15 00:31:46 2013 From: woody at pch.net (Bill Woodcock) Date: Thu, 14 Feb 2013 16:31:46 -0800 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: <62841C6C-8BDB-452E-9A09-E2D55D10E0F3@pch.net> On Feb 14, 2013, at 12:06 PM, Rubens Kuhl wrote: > Not tested under attack, but this DNS provider is worth a look since > it's the only one with both IPv6 and DNSSEC a colleague could find: > http://www.dnsunlimited.com/ Hm. Your colleague didn't look very far. All of the registries and registrars who use our DNS back-end have had both v6 and DNSSEC for a very long time, now. -Bill From chindy at lwpca.net Fri Feb 15 01:50:29 2013 From: chindy at lwpca.net (Chris Hindy) Date: Fri, 15 Feb 2013 01:50:29 +0000 Subject: Muni fiber: L1 or L2? In-Reply-To: <511D7DB1.5040905@necom830.hpcl.titech.ac.jp> Message-ID: Guys?we're done on this. Let it go, already. -c On 14-02-13 19:13 , "Masataka Ohta" wrote: >Mark Andrews wrote: > >>> Sadly, it is impossible to say FTTC not "fiber optic broadband", >>> because it is "broadband" (at least with today's access speed) >>> with "fiber optic". >> >> And by that argument pots dialup is fiber optic because the packets >> went over a fiber optic link to get to the CO. > >Well, not pots, but, NTT was, against ADSL, advertising their >128Kbps ISDN dial up as "high speed Internet". > >So, 128Kbps dial up might have been "broadband" at that time >at least for NTT, until, in late 2001, Japanese government >defined "high speed Internet access network" access network to >be able to smoothly download music data etc. with examples of >xDSL, CATV and Wifi. > > Masataka Ohta > From josmon at rigozsaurus.com Fri Feb 15 04:21:39 2013 From: josmon at rigozsaurus.com (John Osmon) Date: Thu, 14 Feb 2013 21:21:39 -0700 Subject: bgp for ipv6 question In-Reply-To: <1360875490.2832.1.camel@karl> References: <3DEBAB6A-63EA-48ED-B6FB-8CF30A920918@puck.nether.net> <1360875490.2832.1.camel@karl> Message-ID: <20130215042139.GA10375@jeeves.rigozsaurus.com> On Fri, Feb 15, 2013 at 07:58:10AM +1100, Karl Auer wrote: > On Thu, 2013-02-14 at 08:08 -0500, Jared Mauch wrote: > > I recommend keeping your network as congruent between IPv4 and IPv6 as possible, with dual-stack. > > Why? I asked a similar question a few years ago: http://seclists.org/nanog/2007/Aug/653 Most of the answers came back along the lines of "keep your routing boundaries congruent." Doing so makes documentation and troubleshooting simpler -- having non-congruent boundaries is more complex and error prone. However, if a network you're running calls for non-congruency -- go for it! Just be cognizant of the trade offs. From maxsec at gmail.com Fri Feb 15 13:34:47 2013 From: maxsec at gmail.com (Martin Hepworth) Date: Fri, 15 Feb 2013 13:34:47 +0000 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: Another vote for Dyn, about 10% cost of UltraDNS and very similar features and way of billing (queries per second) Route 53 seems very popular as well. -- Martin Hepworth, CISSP Oxford, UK On 14 February 2013 19:58, David Hubbard wrote: > Hi all, anyone have suggestions for very stable/reliable managed DNS? > Neustar/UltraDNS is an obvious option to look at, just curious about > alternatives. Cost effective would be nice, but stable under attack is > better. > > Thanks, > > David > > From rubensk at gmail.com Fri Feb 15 14:51:55 2013 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 15 Feb 2013 12:51:55 -0200 Subject: Suggestions for managed DNS provider? In-Reply-To: <62841C6C-8BDB-452E-9A09-E2D55D10E0F3@pch.net> References: <62841C6C-8BDB-452E-9A09-E2D55D10E0F3@pch.net> Message-ID: On Thu, Feb 14, 2013 at 10:31 PM, Bill Woodcock wrote: > > On Feb 14, 2013, at 12:06 PM, Rubens Kuhl wrote: >> Not tested under attack, but this DNS provider is worth a look since >> it's the only one with both IPv6 and DNSSEC a colleague could find: >> http://www.dnsunlimited.com/ > > Hm. Your colleague didn't look very far. All of the registries and registrars who use our DNS back-end have had both v6 and DNSSEC for a very long time, now. I think he limited the price scope for yearly figures that do not require scientific notation... ;-) Rubens From eugen at leitl.org Fri Feb 15 16:17:07 2013 From: eugen at leitl.org (Eugen Leitl) Date: Fri, 15 Feb 2013 17:17:07 +0100 Subject: Fast fibre: A community shows the way Message-ID: <20130215161707.GC6172@leitl.org> http://www.bbc.co.uk/news/technology-21442348 Fast fibre: A community shows the way COMMENTS (198) Lancashire leads way on fast fibre connection How fast is your home broadband? Seventy to 80 Mbps if you're one of the few with the very fastest fibre broadband services? Perhaps 10Mbps if you've got an average connection, maybe under 2Mbps if you live some miles from your nearest exchange. So how would you fancy a 500Mbps download scheme? That is what I've seen on Harry Ball's quite ancient computer - not in the heart of London but in a village in rural Lancashire. Arkholme is hardly a teeming metropolis but Harry is one of the first local residents to be hooked up to the B4RN community broadband network. After deciding that they were never likely to get a fast broadband connection from one of the major suppliers, a group of local people across this sparsely populated area decided that sitting around moaning about it was not an option. Instead they began a DIY effort, digging channels across the fields and laying fibre optic cables. They have exploited all sorts of local expertise - from the Lancaster University professor who is an expert in computer networks to the farmer's wife who has just retired from a career in IT support. The cooperation of local landowners has been vital - free access to fields has made it much cheaper to roll out the network. BT and other companies which have to dig up the country roads to lay fibre networks reckon it can cost as much as ?10,000 to hook up one rural home - the people at B4RN reckon they can bring that down to around ?1,000. And people like Harry and Susan Ball are now entering the superfast broadband era. The retired couple told me they knew little about computers and had got used to the fact that it was almost impossible on their slow connection to watch video or use Skype. Now Harry is able to watch the iPlayer streaming in HD, and Susan has become a B4RN volunteer, helping to dig trenches for the fibre. But, after raising half a million pounds from locals who bought shares on the promise of a fast connection, the project now needs to move to the next stage. In the Arkholme village hall this afternoon, B4RN is holding an open day, inviting anyone to drop in and test the broadband connection on their phones or computers. The hope is that many will sign up to the ?30 per month service, but that some will also buy shares in B4RN. Another ?1.5m is needed if the full 265KM network is to be rolled out. That sounds ambitious - but having spent 24 hours watching the volunteers digging trenches, blowing fibre and learning a process called fusion splicing I can see they are a very determined bunch. As Barry Forde, the networking expert who is the chief executive of B4RN explained to me, fast broadband is not a luxury now, whether in the town or the country. "Farmers are being told they have to fill in forms online," he says. "If you haven't got broadband you are severely disadvantaged." And despite the ?530m government money to bring fast broadband to rural Britain, many communities face a long wait to get connected. In the meantime, others may learn the lesson from B4RN - if you want it in a hurry, just get out and start digging. From dhubbard at dino.hostasaurus.com Fri Feb 15 17:41:16 2013 From: dhubbard at dino.hostasaurus.com (David Hubbard) Date: Fri, 15 Feb 2013 12:41:16 -0500 Subject: Suggestions for managed DNS provider? References: Message-ID: Thanks for all the replies everyone (on and off list), I've got some great leads I'm investigating now. David > -----Original Message----- > From: David Hubbard > Sent: Thursday, February 14, 2013 2:59 PM > To: nanog at nanog.org > Subject: Suggestions for managed DNS provider? > > Hi all, anyone have suggestions for very stable/reliable managed DNS? > Neustar/UltraDNS is an obvious option to look at, just curious about > alternatives. Cost effective would be nice, but stable under > attack is > better. > > Thanks, > > David > > From aaron at mailbase.ca Fri Feb 15 15:05:20 2013 From: aaron at mailbase.ca (Aaron Fabiani) Date: Fri, 15 Feb 2013 10:05:20 -0500 Subject: Suggestions for managed DNS =?UTF-8?Q?provider=3F?= In-Reply-To: References: Message-ID: On 2013-02-14 17:32, Michael Loftis wrote: > On Thu, Feb 14, 2013 at 11:58 AM, David Hubbard > wrote: >> Hi all, anyone have suggestions for very stable/reliable managed DNS? >> Neustar/UltraDNS is an obvious option to look at, just curious about >> alternatives. Cost effective would be nice, but stable under attack >> is >> better. I've been using EasyDNS for some time and they've been very stable and reliable. From paigeadele at gmail.com Fri Feb 15 04:58:31 2013 From: paigeadele at gmail.com (Adele Thompson) Date: Thu, 14 Feb 2013 20:58:31 -0800 Subject: Suggestions for managed DNS provider? In-Reply-To: <62841C6C-8BDB-452E-9A09-E2D55D10E0F3@pch.net> References: <62841C6C-8BDB-452E-9A09-E2D55D10E0F3@pch.net> Message-ID: On Thu, Feb 14, 2013 at 4:31 PM, Bill Woodcock wrote: > > On Feb 14, 2013, at 12:06 PM, Rubens Kuhl wrote: > > Not tested under attack, but this DNS provider is worth a look since > > it's the only one with both IPv6 and DNSSEC a colleague could find: > > http://www.dnsunlimited.com/ > > Hm. Your colleague didn't look very far. All of the registries and > registrars who use our DNS back-end have had both v6 and DNSSEC for a very > long time, now. > > -Bill > > > > > > > Maybe Rackspace Cloud DNS.... still would so much rather manage my own DNS.... From raj at rajlog.com Fri Feb 15 15:56:31 2013 From: raj at rajlog.com (Raj Jalan) Date: Fri, 15 Feb 2013 10:56:31 -0500 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: http://www.dnsmadeeasy.com Cost effective. We use it for some level of failover and load sharing as well. -Raj Jalan @rjalan2 On Thu, Feb 14, 2013 at 2:58 PM, David Hubbard < dhubbard at dino.hostasaurus.com> wrote: > Hi all, anyone have suggestions for very stable/reliable managed DNS? > Neustar/UltraDNS is an obvious option to look at, just curious about > alternatives. Cost effective would be nice, but stable under attack is > better. > > Thanks, > > David > > From morrowc.lists at gmail.com Fri Feb 15 17:57:54 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 15 Feb 2013 12:57:54 -0500 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: If you have a dns server already, you can get some diversity for free with: http://puck.nether.net/dns/ of course, this week's outage not withstanding, puck has been pretty stable for me for this... On Fri, Feb 15, 2013 at 10:56 AM, Raj Jalan wrote: > http://www.dnsmadeeasy.com > Cost effective. We use it for some level of failover and load sharing as > well. > > -Raj Jalan > @rjalan2 > > On Thu, Feb 14, 2013 at 2:58 PM, David Hubbard < > dhubbard at dino.hostasaurus.com> wrote: > >> Hi all, anyone have suggestions for very stable/reliable managed DNS? >> Neustar/UltraDNS is an obvious option to look at, just curious about >> alternatives. Cost effective would be nice, but stable under attack is >> better. >> >> Thanks, >> >> David >> >> From james at freedomnet.co.nz Fri Feb 15 18:01:17 2013 From: james at freedomnet.co.nz (james jones) Date: Fri, 15 Feb 2013 13:01:17 -0500 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: +1 on Dyn On Fri, Feb 15, 2013 at 10:56 AM, Raj Jalan wrote: > http://www.dnsmadeeasy.com > Cost effective. We use it for some level of failover and load sharing as > well. > > -Raj Jalan > @rjalan2 > > On Thu, Feb 14, 2013 at 2:58 PM, David Hubbard < > dhubbard at dino.hostasaurus.com> wrote: > > > Hi all, anyone have suggestions for very stable/reliable managed DNS? > > Neustar/UltraDNS is an obvious option to look at, just curious about > > alternatives. Cost effective would be nice, but stable under attack is > > better. > > > > Thanks, > > > > David > > > > > From cscora at apnic.net Fri Feb 15 18:33:21 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 Feb 2013 04:33:21 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201302151833.r1FIXLAA014510@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 16 Feb, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 443072 Prefixes after maximum aggregation: 182226 Deaggregation factor: 2.43 Unique aggregates announced to Internet: 217209 Total ASes present in the Internet Routing Table: 43311 Prefixes per ASN: 10.23 Origin-only ASes present in the Internet Routing Table: 34169 Origin ASes announcing only one prefix: 15936 Transit ASes present in the Internet Routing Table: 5755 Transit-only ASes present in the Internet Routing Table: 141 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 29 Max AS path prepend of ASN ( 28730) 25 Prefixes from unregistered ASNs in the Routing Table: 384 Unregistered ASNs in the Routing Table: 139 Number of 32-bit ASNs allocated by the RIRs: 3756 Number of 32-bit ASNs visible in the Routing Table: 3387 Prefixes from 32-bit ASNs in the Routing Table: 9286 Special use prefixes present in the Routing Table: 17 Prefixes being announced from unallocated address space: 188 Number of addresses announced to Internet: 2616732428 Equivalent to 155 /8s, 248 /16s and 43 /24s Percentage of available address space announced: 70.7 Percentage of allocated address space announced: 70.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.3 Total number of prefixes smaller than registry allocations: 156364 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 106392 Total APNIC prefixes after maximum aggregation: 33093 APNIC Deaggregation factor: 3.21 Prefixes being announced from the APNIC address blocks: 107472 Unique aggregates announced from the APNIC address blocks: 43908 APNIC Region origin ASes present in the Internet Routing Table: 4816 APNIC Prefixes per ASN: 22.32 APNIC Region origin ASes announcing only one prefix: 1237 APNIC Region transit ASes present in the Internet Routing Table: 807 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 429 Number of APNIC addresses announced to Internet: 718760448 Equivalent to 42 /8s, 215 /16s and 106 /24s Percentage of available APNIC address space announced: 84.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 155600 Total ARIN prefixes after maximum aggregation: 78739 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 156259 Unique aggregates announced from the ARIN address blocks: 70972 ARIN Region origin ASes present in the Internet Routing Table: 15463 ARIN Prefixes per ASN: 10.11 ARIN Region origin ASes announcing only one prefix: 5840 ARIN Region transit ASes present in the Internet Routing Table: 1600 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 18 Number of ARIN addresses announced to Internet: 1076205440 Equivalent to 64 /8s, 37 /16s and 151 /24s Percentage of available ARIN address space announced: 56.9 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 113997 Total RIPE prefixes after maximum aggregation: 58785 RIPE Deaggregation factor: 1.94 Prefixes being announced from the RIPE address blocks: 117156 Unique aggregates announced from the RIPE address blocks: 74884 RIPE Region origin ASes present in the Internet Routing Table: 17064 RIPE Prefixes per ASN: 6.87 RIPE Region origin ASes announcing only one prefix: 8151 RIPE Region transit ASes present in the Internet Routing Table: 2778 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 29 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2190 Number of RIPE addresses announced to Internet: 653473892 Equivalent to 38 /8s, 243 /16s and 56 /24s Percentage of available RIPE address space announced: 95.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 47136 Total LACNIC prefixes after maximum aggregation: 9119 LACNIC Deaggregation factor: 5.17 Prefixes being announced from the LACNIC address blocks: 50849 Unique aggregates announced from the LACNIC address blocks: 23570 LACNIC Region origin ASes present in the Internet Routing Table: 1810 LACNIC Prefixes per ASN: 28.09 LACNIC Region origin ASes announcing only one prefix: 526 LACNIC Region transit ASes present in the Internet Routing Table: 342 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 743 Number of LACNIC addresses announced to Internet: 123073832 Equivalent to 7 /8s, 85 /16s and 245 /24s Percentage of available LACNIC address space announced: 73.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 10524 Total AfriNIC prefixes after maximum aggregation: 2437 AfriNIC Deaggregation factor: 4.32 Prefixes being announced from the AfriNIC address blocks: 11148 Unique aggregates announced from the AfriNIC address blocks: 3706 AfriNIC Region origin ASes present in the Internet Routing Table: 599 AfriNIC Prefixes per ASN: 18.61 AfriNIC Region origin ASes announcing only one prefix: 182 AfriNIC Region transit ASes present in the Internet Routing Table: 134 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 7 Number of AfriNIC addresses announced to Internet: 44860416 Equivalent to 2 /8s, 172 /16s and 132 /24s Percentage of available AfriNIC address space announced: 44.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2938 11558 924 Korea Telecom (KIX) 17974 2486 824 85 PT TELEKOMUNIKASI INDONESIA 7545 1824 301 88 TPG Internet Pty Ltd 4755 1686 382 190 TATA Communications formerly 9829 1430 1144 44 BSNL National Internet Backbo 9583 1207 89 501 Sify Limited 7552 1161 1070 12 Vietel Corporation 4808 1109 2040 316 CNCGROUP IP network: China169 9498 1061 310 75 BHARTI Airtel Ltd. 24560 1044 385 160 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3065 3696 101 bellsouth.net, inc. 7029 2170 1265 211 Windstream Communications Inc 18566 2080 382 185 Covad Communications 22773 1987 2931 128 Cox Communications, Inc. 1785 1955 677 125 PaeTec Communications, Inc. 20115 1692 1610 616 Charter Communications 4323 1603 1139 396 Time Warner Telecom 30036 1344 287 686 Mediacom Communications Corp 7018 1301 10552 856 AT&T WorldNet Services 11492 1197 217 334 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1858 544 16 Corbina telecom 2118 1115 97 13 EUnet/RELCOM Autonomous Syste 34984 1054 232 203 BILISIM TELEKOM 13188 850 99 26 Educational Network 12479 819 783 68 Uni2 Autonomous System 31148 758 39 18 FreeNet ISP 20940 750 255 592 Akamai Technologies European 6830 712 2313 433 UPC Distribution Services 8551 711 367 39 Bezeq International 34744 670 185 43 SC GVM SISTEM 2003 SRL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 2381 1327 87 NET Servicos de Comunicao S.A 10620 2319 397 223 TVCABLE BOGOTA 7303 1679 1147 206 Telecom Argentina Stet-France 8151 1506 2824 396 UniNet S.A. de C.V. 6503 1445 435 67 AVANTEL, S.A. 14754 939 120 78 Telgua S. A. 27947 776 86 98 Telconet S.A 18881 771 716 18 Global Village Telecom 3816 686 306 87 Empresa Nacional de Telecomun 7738 613 1242 34 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1286 80 4 MOBITEL 24863 898 275 36 LINKdotNET AS number 8452 542 958 13 TEDATA 6713 503 602 20 Itissalat Al-MAGHRIB 24835 329 80 8 RAYA Telecom - Egypt 3741 266 906 224 The Internet Solution 12258 193 28 67 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 189 696 90 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3065 3696 101 bellsouth.net, inc. 4766 2938 11558 924 Korea Telecom (KIX) 17974 2486 824 85 PT TELEKOMUNIKASI INDONESIA 28573 2381 1327 87 NET Servicos de Comunicao S.A 10620 2319 397 223 TVCABLE BOGOTA 7029 2170 1265 211 Windstream Communications Inc 18566 2080 382 185 Covad Communications 22773 1987 2931 128 Cox Communications, Inc. 1785 1955 677 125 PaeTec Communications, Inc. 8402 1858 544 16 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 2486 2401 PT TELEKOMUNIKASI INDONESIA 28573 2381 2294 NET Servicos de Comunicao S.A 10620 2319 2096 TVCABLE BOGOTA 4766 2938 2014 Korea Telecom (KIX) 7029 2170 1959 Windstream Communications Inc 18566 2080 1895 Covad Communications 22773 1987 1859 Cox Communications, Inc. 8402 1858 1842 Corbina telecom 1785 1955 1830 PaeTec Communications, Inc. 7545 1824 1736 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.60.0/23 57417 INTERNET TASMANIA SRL 128.0.62.0/23 57417 INTERNET TASMANIA SRL 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.96.0/21 12886 LEWTelNet GmbH 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.138.95.0/24 36930 ZanZibar Telecom 41.222.80.0/21 37110 Moztel LDA 62.12.96.0/19 38478 SunnyVision Limited 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:17 /9:13 /10:29 /11:88 /12:246 /13:483 /14:865 /15:1553 /16:12565 /17:6594 /18:11003 /19:21737 /20:31235 /21:33357 /22:45541 /23:41171 /24:232283 /25:1389 /26:1750 /27:859 /28:182 /29:75 /30:16 /31:0 /32:21 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2030 2080 Covad Communications 6389 1758 3065 bellsouth.net, inc. 8402 1585 1858 Corbina telecom 7029 1554 2170 Windstream Communications Inc 22773 1303 1987 Cox Communications, Inc. 36998 1280 1286 MOBITEL 30036 1235 1344 Mediacom Communications Corp 11492 1160 1197 Cable One 1785 1035 1955 PaeTec Communications, Inc. 6503 965 1445 AVANTEL, S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:672 2:747 3:3 4:13 5:760 6:3 8:499 12:1935 13:3 14:741 15:11 16:3 17:8 20:24 23:240 24:1798 27:1445 31:1131 32:54 33:2 34:5 36:11 37:1288 38:847 39:2 40:141 41:2713 42:179 44:4 46:1743 47:1 49:579 50:654 52:12 54:28 55:9 57:28 58:1079 59:560 60:251 61:1321 62:1027 63:2027 64:4308 65:2147 66:4263 67:2046 68:1125 69:3267 70:856 71:525 72:1875 74:2531 75:421 76:289 77:1078 78:1036 79:542 80:1215 81:972 82:627 83:538 84:558 85:1155 86:475 87:929 88:382 89:1746 90:278 91:5412 92:622 93:1693 94:2056 95:1589 96:506 97:336 98:1037 99:52 100:30 101:315 103:2122 105:519 106:131 107:206 108:511 109:1764 110:855 111:1014 112:487 113:739 114:684 115:920 116:876 117:787 118:984 119:1272 120:377 121:701 122:1738 123:1183 124:1320 125:1310 128:541 129:202 130:316 131:641 132:328 133:143 134:259 135:62 136:222 137:236 138:342 139:159 140:216 141:316 142:519 143:369 144:478 145:88 146:525 147:335 148:720 149:349 150:156 151:400 152:400 153:191 154:28 155:367 156:242 157:387 158:260 159:712 160:333 161:422 162:361 163:203 164:577 165:450 166:436 167:572 168:1010 169:131 170:940 171:164 172:4 173:1548 174:586 175:417 176:1166 177:1670 178:1742 180:1384 181:231 182:1153 183:321 184:635 185:236 186:2260 187:1427 188:1936 189:1539 190:6638 192:6322 193:5654 194:4643 195:3678 196:1290 197:891 198:4154 199:5221 200:6025 201:2146 202:8887 203:8759 204:4470 205:2544 206:2803 207:2810 208:4059 209:3508 210:2920 211:1565 212:1937 213:1904 214:901 215:93 216:5095 217:1586 218:594 219:328 220:1263 221:549 222:329 223:421 End of report From benno at NLnetLabs.nl Fri Feb 15 18:48:44 2013 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Fri, 15 Feb 2013 19:48:44 +0100 Subject: Call for Papers: RIPE 66, 13-17 May 2013 in Dublin, Ireland Message-ID: <511E830C.3040307@NLnetLabs.nl> Call for Papers: RIPE 66 A RIPE Meeting is an open event where Internet Service Providers, network operators and other interested parties get together. Although the meeting is mostly technical, it is also a chance for people to meet and network with others in their field. RIPE 66 will take place on 13-17 May 2013 in Dublin, Ireland. The RIPE Programme Committee (PC) is now seeking content proposals from the RIPE community for the Plenary, BoF and Tutorial sessions at RIPE 66. The PC is looking for presentations covering topics of network engineering and operations, including but not limited to: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data center technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange Submissions Attendees of the RIPE meetings are quite sensitive to keeping presentations non-commercial, and product marketing talks are strongly discouraged. Repeated audience feedback shows that the most successful talks focus on operational experience, research results, or case studies. For example, presenters wishing to describe a commercial solution should focus on the underlying technology and not attempt a product demonstration. Presenters who are proposing a panel or BoF are encouraged to include speakers from several (perhaps even competing) companies and/or a neutral facilitator. In addition to presentations selected in advance for the Plenary, the RIPE PC also offers several time slots for ?lightning talks? which are selected immediately before or during the conference. The following requirements apply: - Proposals for Plenary talks, BoFs, Panels and Tutorials must be submitted for full consideration no later than 24 February 2013, using the meeting submission system at: https://meetings.ripe.net/pc/ Proposals submitted after this date will be considered on a space-available basis. - Presenters should indicate how much time they will require (30 minutes for talks is a common maximum duration, although some talks can be longer). - Proposals for talks will only be considered by the PC if they contain at least draft presentation slides (slides may be updated later on). For BoFs and panels, proposals must contain a clear description as well as names of invited panelists/presenters. - Due to potential technical issues, it is expected that most if not all presenters/panelists will be physically present at the RIPE meeting. - Lightning talks should be submitted using the meeting submission system. They must be short (10 minutes maximum) and often involve more timely topics. They can be submitted at any time. The allocation of lightning talk slots will be announced one day prior to the relevant session. If you have any questions or requests concerning content submissions, please email pc [at] ripe [dot] net. -- Benno J. Overeinder NLnet Labs http://www.nlnetlabs.nl/ From cidr-report at potaroo.net Fri Feb 15 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Feb 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201302152200.r1FM00sF068672@wattle.apnic.net> This report has been generated at Fri Feb 15 21:13:14 2013 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 08-02-13 444908 254193 09-02-13 445257 254308 10-02-13 445138 254258 11-02-13 445138 254536 12-02-13 445341 254468 13-02-13 444932 254971 14-02-13 445625 254890 15-02-13 445440 255153 AS Summary 43403 Number of ASes in routing system 18011 Number of ASes announcing only one prefix 3064 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 116912864 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 15Feb13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 445499 255104 190395 42.7% All ASes AS6389 3064 104 2960 96.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2379 89 2290 96.3% NET Servicos de Comunicao S.A. AS17974 2486 471 2015 81.1% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2938 941 1997 68.0% KIXS-AS-KR Korea Telecom AS22773 1988 224 1764 88.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 2080 427 1653 79.5% COVAD - Covad Communications Co. AS10620 2319 671 1648 71.1% Telmex Colombia S.A. AS7303 1679 407 1272 75.8% Telecom Argentina S.A. AS4323 1606 400 1206 75.1% TWTC - tw telecom holdings, inc. AS4755 1686 582 1104 65.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1115 83 1032 92.6% RELCOM-AS OOO "NPO Relcom" AS7552 1161 183 978 84.2% VIETEL-AS-AP Vietel Corporation AS7029 2170 1200 970 44.7% WINDSTREAM - Windstream Communications Inc AS36998 1286 381 905 70.4% SDN-MOBITEL AS18101 1009 171 838 83.1% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7545 1832 1018 814 44.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS1785 1955 1166 789 40.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS8151 1515 745 770 50.8% Uninet S.A. de C.V. AS4808 1109 352 757 68.3% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS18881 771 26 745 96.6% Global Village Telecom AS14754 940 208 732 77.9% Telgua AS13977 838 123 715 85.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS9808 741 54 687 92.7% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS855 714 52 662 92.7% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS24560 1044 419 625 59.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS22561 1067 445 622 58.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS17676 719 98 621 86.4% GIGAINFRA Softbank BB Corp. AS3356 1103 498 605 54.9% LEVEL3 Level 3 Communications AS3549 1046 444 602 57.6% GBLX Global Crossing Ltd. AS19262 997 404 593 59.5% VZGNI-TRANSIT - Verizon Online LLC Total 45357 12386 32971 72.7% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 41.138.95.0/24 AS36930 Zantel-AS 41.222.80.0/21 AS37110 moztel-as 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.5.152.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC. 103.11.148.0/24 AS58452 103.11.149.0/24 AS58452 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 151.216.32.0/19 AS12835 INFOTN-AS Trentino Network S.r.l. 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 15 22:00:01 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Feb 2013 22:00:01 GMT Subject: BGP Update Report Message-ID: <201302152200.r1FM01UD068689@wattle.apnic.net> BGP Update Report Interval: 07-Feb-13 -to- 14-Feb-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9498 245687 6.8% 229.8 -- BBIL-AP BHARTI Airtel Ltd. 2 - AS24560 187479 5.2% 179.6 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 3 - AS18207 93694 2.6% 171.0 -- YOU-INDIA-AP YOU Broadband & Cable India Ltd. 4 - AS45609 57702 1.6% 220.2 -- BHARTI-MOBILITY-AS-AP Bharti Airtel Ltd. AS for GPRS Service 5 - AS18002 56356 1.6% 268.4 -- WORLDPHONE-IN AS Number for Interdomain Routing 6 - AS8402 53674 1.5% 25.7 -- CORBINA-AS OJSC "Vimpelcom" 7 - AS45514 44973 1.2% 147.0 -- TELEMEDIA-SMB-AS-AP Bharti Airtel Ltd., TELEMEDIA Services, for SMB customers 8 - AS7029 44480 1.2% 17.3 -- WINDSTREAM - Windstream Communications Inc 9 - AS3909 42918 1.2% 1262.3 -- QWEST-AS-3908 - Qwest Communications Company, LLC 10 - AS45528 35327 1.0% 59.0 -- TDN Tikona Digital Networks Pvt Ltd. 11 - AS29049 30582 0.8% 91.6 -- DELTA-TELECOM-AS Delta Telecom LTD. 12 - AS17488 30089 0.8% 44.8 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 13 - AS9829 25996 0.7% 18.1 -- BSNL-NIB National Internet Backbone 14 - AS8151 24991 0.7% 16.1 -- Uninet S.A. de C.V. 15 - AS2708 20213 0.6% 144.4 -- Universidad de Guanajuato 16 - AS17447 19948 0.6% 153.4 -- NET4INDIA Net4India Ltd. 17 - AS45769 19648 0.5% 78.9 -- DVOIS-IN D-Vois Broadband Pvt Ltd 18 - AS23682 19449 0.5% 132.3 -- PACENET-AS Broadband Pacenet Pvt. Ltd 19 - AS17917 19309 0.5% 163.6 -- QTLTELECOM-AS-AP Quadrant Televentures Limited 20 - AS4 19100 0.5% 526.0 -- COMUNICALO DE MEXICO S.A. DE C.V TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6174 5898 0.2% 2949.0 -- SPRINTLINK8 - Sprint 2 - AS14680 6290 0.2% 2096.7 -- REALE-6 - Auction.com 3 - AS57816 7228 0.2% 1807.0 -- SAMEN Samen Ertebat Asr Co. (P.J.S.) 4 - AS40946 8605 0.2% 1721.0 -- PROCON - Sat Track 5 - AS25806 3018 0.1% 1509.0 -- RALEYNET - Raleys 6 - AS3909 42918 1.2% 1262.3 -- QWEST-AS-3908 - Qwest Communications Company, LLC 7 - AS32777 5850 0.2% 1170.0 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 8 - AS4 19100 0.5% 526.0 -- COMUNICALO DE MEXICO S.A. DE C.V 9 - AS24773 851 0.0% 851.0 -- ASN-HH-LB HSH Nordbank AG 10 - AS22140 7433 0.2% 743.3 -- T-MOBILE-AS22140 - T-Mobile USA, Inc. 11 - AS16781 1391 0.0% 695.5 -- ARS-NATIONAL - ARS National Services, Inc. 12 - AS57201 669 0.0% 669.0 -- EDF-AS Estonian Defence Forces 13 - AS12397 565 0.0% 565.0 -- OPTOCOM Optocom Ltd 14 - AS40931 1674 0.1% 558.0 -- MOBITV - MobiTV, Inc 15 - AS54527 1607 0.0% 535.7 -- ASTUTEHOSTING - Astute Hosting Inc. 16 - AS55734 2063 0.1% 515.8 -- SYMBIOS-IN 001 IT Complex 17 - AS17293 2056 0.1% 514.0 -- VTXC - VTX Communications 18 - AS4 513 0.0% 742.0 -- COMUNICALO DE MEXICO S.A. DE C.V 19 - AS55578 513 0.0% 513.0 -- CGI-INDIA-IN Tower 2, #95/1 & 95/2, 20 - AS45154 1017 0.0% 508.5 -- APPNOMIC-AS-AP Appnomic Systems Pvt Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 151.118.254.0/24 14259 0.4% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 2 - 151.118.255.0/24 14259 0.4% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - 151.118.18.0/24 14255 0.4% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - 208.92.131.0/24 8598 0.2% AS40946 -- PROCON - Sat Track 5 - 196.1.167.0/24 7998 0.2% AS11139 -- CWRIN CW BARBADOS 6 - 202.41.70.0/24 7949 0.2% AS2697 -- ERX-ERNET-AS Education and Research Network 7 - 208.14.186.0/24 7389 0.2% AS22140 -- T-MOBILE-AS22140 - T-Mobile USA, Inc. 8 - 192.58.232.0/24 7327 0.2% AS6629 -- NOAA-AS - NOAA 9 - 37.9.248.0/21 7086 0.2% AS57816 -- SAMEN Samen Ertebat Asr Co. (P.J.S.) 10 - 12.139.133.0/24 5114 0.1% AS14680 -- REALE-6 - Auction.com 11 - 58.184.229.0/24 4777 0.1% AS9950 -- PUBNETPLUS2-AS-KR DACOM 12 - 194.63.9.0/24 4616 0.1% AS1273 -- CW Cable and Wireless Worldwide plc 13 - 69.38.178.0/24 4142 0.1% AS19406 -- TWRS-MA - Towerstream I, Inc. 14 - 84.205.66.0/24 3199 0.1% AS12654 -- RIPE-NCC-RIS-AS Reseaux IP Europeens Network Coordination Centre (RIPE NCC) 15 - 167.235.247.0/24 3012 0.1% AS25806 -- RALEYNET - Raleys 16 - 192.207.4.0/22 2954 0.1% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 17 - 192.207.8.0/22 2953 0.1% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 18 - 206.105.75.0/24 2949 0.1% AS6174 -- SPRINTLINK8 - Sprint 19 - 208.16.110.0/24 2949 0.1% AS6174 -- SPRINTLINK8 - Sprint 20 - 211.240.105.0/24 2711 0.1% AS4663 -- ELIMNET-AS ELIMNET, INC Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From karim.adel at gmail.com Fri Feb 15 22:15:49 2013 From: karim.adel at gmail.com (Kasper Adel) Date: Fri, 15 Feb 2013 14:15:49 -0800 Subject: Quantifying the value of customer support In-Reply-To: <970945E55BFD8C4EA4CAD74B647A9DC0B5066A@USIDCWVEMBX10.corp.global.level3.com> References: <970945E55BFD8C4EA4CAD74B647A9DC0B5066A@USIDCWVEMBX10.corp.global.level3.com> Message-ID: Thanks everyone for the feedback. Can someone give an example on how i can calculate $ value from improving a product/service usability and servicability? I am trying to categorize what we offer : 1) Improve customer experience 2) Reduce service deployment time 3) Improve service availability Regards Kim On Friday, February 15, 2013, Siegel, David wrote: > There is no such thing as a generic business case that can be applied > across all companies in an industry. Every business is unique in its > product definition and organization structure, but each question is also > unique and therefore the analysis must be done every time. > > The way to begin is to ask this manager what he believes the possible > outcomes are (downsize your group, eliminate your group, re-define your > group, etc.) and then work with each of the key stakeholders that you have > to estimate the impact of those outcomes. For example, if 1st line > operations indicates that eliminating your group would result in decreased > customer satisfaction and missed SLA's, ask them to quantify it as much as > possible and go to take the numbers back to your business people to have > them estimate the impact on revenue. > > The analysis should be constructed and presented in standard finance terms > (like NPV) so I would suggest that you make friends with someone in finance > to assist you with the preparation. You can also take a short two-day > course like this > http://executive.mit.edu/openenrollment/program/fundamentals_of_finance_for_the_technical_executive/16that will teach you how to build up these analysis yourself (I have taken > the one referenced and I recommend it to all managers with budget > responsibility). > > The outcome from these discussions often has surprising but positive > outcomes for everyone...maintaining the status quo is not always the best > possible outcome despite the biases we usually have when we begin the > analysis. :-) If you work closely with all of your stakeholders, everyone > will learn and benefit from the experience. > > Dave > > -----Original Message----- > From: Kasper Adel [mailto:karim.adel at gmail.com ] > Sent: Thursday, February 14, 2013 2:16 PM > To: Andrew Latham > Cc: NANOG list > Subject: Re: Quantifying the value of customer support > > I used to think that these kind of situations take place when a manager > was never an engineer so he does not understand how things work but i was > surprised when i faced these from managers with an intense engineering > career so i gave up on trying to give conceptual excuses and want to just > give them the dump tables and numbers that they are looking for. > > Kim > > On Thursday, February 14, 2013, Andrew Latham wrote: > > > On Thu, Feb 14, 2013 at 3:52 PM, Kasper Adel > > > > > wrote: > > > Hello, > > > > > > We are a 2nd level of escalation in a service provider, trying to > > > put a $ value on the support we give to our NOC and other > > > implementation teams, when they email us about problems they face. > > > But we are merely bits and bytes engineers that cant quantify and > > > justify the value of what we do to the management team. I guess > > > these smart suits want to see an excel sheet with a table of how > > > much they save or gain by the support we do. We > > respond > > > to technical questions and simulate problems in a lab. > > > > > > Can anyone help me with an idea or any material i can reuse? Templates? > > Has > > > any one been in a similar situation. > > > > > > Thanks > > > Kim > > > > Kasper/Karim/Kim > > > > Your job is customer retention. Your value is maintaining all company > > income. Write the yearly revenue on a piece of paper and hand it to > > them. > > > > > > -- > > ~ Andrew "lathama" Latham lathama at gmail.com > > http://lathama.net ~ > > > From alter3d at alter3d.ca Fri Feb 15 22:49:13 2013 From: alter3d at alter3d.ca (Peter Kristolaitis) Date: Fri, 15 Feb 2013 17:49:13 -0500 Subject: Quantifying the value of customer support In-Reply-To: References: <970945E55BFD8C4EA4CAD74B647A9DC0B5066A@USIDCWVEMBX10.corp.global.level3.com> Message-ID: <511EBB69.7040509@alter3d.ca> You need to talk to your marketing/sales department and have them figure out how many existing clients you would retain by maintaining the current level of service, how many clients you would lose with lower quality of service, and how many clients you would attract with better service. From that, you can figure out a rough ROI for your department. This isn't a fundamentally technical question, it's a marketing & sales one. You can have the best service ever, but if your company is unable to attract or retain clients (whether due to your company's PR reputation, market saturation, or whatever), it doesn't matter. - Pete On 02/15/2013 05:15 PM, Kasper Adel wrote: > Thanks everyone for the feedback. > > Can someone give an example on how i can calculate $ value from improving a > product/service usability and servicability? I am trying to categorize what > we offer : > > 1) Improve customer experience > 2) Reduce service deployment time > 3) Improve service availability > > Regards > Kim > > On Friday, February 15, 2013, Siegel, David wrote: > >> There is no such thing as a generic business case that can be applied >> across all companies in an industry. Every business is unique in its >> product definition and organization structure, but each question is also >> unique and therefore the analysis must be done every time. >> >> The way to begin is to ask this manager what he believes the possible >> outcomes are (downsize your group, eliminate your group, re-define your >> group, etc.) and then work with each of the key stakeholders that you have >> to estimate the impact of those outcomes. For example, if 1st line >> operations indicates that eliminating your group would result in decreased >> customer satisfaction and missed SLA's, ask them to quantify it as much as >> possible and go to take the numbers back to your business people to have >> them estimate the impact on revenue. >> >> The analysis should be constructed and presented in standard finance terms >> (like NPV) so I would suggest that you make friends with someone in finance >> to assist you with the preparation. You can also take a short two-day >> course like this >> http://executive.mit.edu/openenrollment/program/fundamentals_of_finance_for_the_technical_executive/16that will teach you how to build up these analysis yourself (I have taken >> the one referenced and I recommend it to all managers with budget >> responsibility). >> >> The outcome from these discussions often has surprising but positive >> outcomes for everyone...maintaining the status quo is not always the best >> possible outcome despite the biases we usually have when we begin the >> analysis. :-) If you work closely with all of your stakeholders, everyone >> will learn and benefit from the experience. >> >> Dave >> >> -----Original Message----- >> From: Kasper Adel [mailto:karim.adel at gmail.com ] >> Sent: Thursday, February 14, 2013 2:16 PM >> To: Andrew Latham >> Cc: NANOG list >> Subject: Re: Quantifying the value of customer support >> >> I used to think that these kind of situations take place when a manager >> was never an engineer so he does not understand how things work but i was >> surprised when i faced these from managers with an intense engineering >> career so i gave up on trying to give conceptual excuses and want to just >> give them the dump tables and numbers that they are looking for. >> >> Kim >> >> On Thursday, February 14, 2013, Andrew Latham wrote: >> >>> On Thu, Feb 14, 2013 at 3:52 PM, Kasper Adel >>> > >>> wrote: >>>> Hello, >>>> >>>> We are a 2nd level of escalation in a service provider, trying to >>>> put a $ value on the support we give to our NOC and other >>>> implementation teams, when they email us about problems they face. >>>> But we are merely bits and bytes engineers that cant quantify and >>>> justify the value of what we do to the management team. I guess >>>> these smart suits want to see an excel sheet with a table of how >>>> much they save or gain by the support we do. We >>> respond >>>> to technical questions and simulate problems in a lab. >>>> >>>> Can anyone help me with an idea or any material i can reuse? Templates? >>> Has >>>> any one been in a similar situation. >>>> >>>> Thanks >>>> Kim >>> Kasper/Karim/Kim >>> >>> Your job is customer retention. Your value is maintaining all company >>> income. Write the yearly revenue on a piece of paper and hand it to >>> them. >>> >>> >>> -- >>> ~ Andrew "lathama" Latham lathama at gmail.com >>> http://lathama.net ~ >>> From edward.dore at freethought-internet.co.uk Fri Feb 15 23:25:31 2013 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Fri, 15 Feb 2013 23:25:31 +0000 Subject: Muni fiber: L1 or L2? In-Reply-To: <511C3A4A.7050401@necom830.hpcl.titech.ac.jp> References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> <511AC8D2.4060601@necom830.hpcl.titech.ac.jp> <2BD016DC-3F62-4B31-AAE3-F7B031DFA714@freethought-internet.co.uk> <511C3A4A.7050401@necom830.hpcl.titech.ac.jp> Message-ID: On 14 Feb 2013, at 01:13, Masataka Ohta wrote: > Edward Dore wrote: > >> Sadly, despite this being challenged with both the telecoms >> regulator (Ofcom) and advertising watchdog (ASA), for some >> reason both seem pretty happy with the utter farce that is >> advertising BT/OpenReach's VDSL based Fibre To The Cabinet >> and Virgin Media's Hybrid Fibre Coax networks as "fibre >> optic broadband". > > Sadly, it is impossible to say FTTC not "fiber optic broadband", > because it is "broadband" (at least with today's access speed) > with "fiber optic". Then why would you not also consider bog standard ADSL to also be "fibre optic"? >> We were supposed to be getting FTTP where I live last March, >> but for some reason BT silently scrapped that plan and now we >> are getting FTTC this March apparently... > > Obviously because it makes L1 unbundling difficult. With BT/OpenReach's FTTC and FTTP there's no difference in terms of layer 1 unbundling - it's impossible with either as they are both shared mediums aggregated before the exchange. FTTC is fibre from the local exchange to the street cabinet where there is a VDSL DSLAM feeding the last part of the copper loop through to the property. This provides up to 80Mbps down and 20Mbps up. FTTP is GPON from the exchange right through to the property completely independent of the existing copper loop. Currently this provides up to 330Mbps down and 30Mbps up. There is also an "FTTP on-demenad" option where if you are in a FTTC area then you basically pay for BT/OpenReach to extend the fibre to your property and provide the FTTP service. This is expensive though as you foot all of the excess construction charges. Apparently the average cost is going to be around ?1500. In either case, OpenReach are required to provide "open" access at the exchange to any companies wishing to make use of the local infrastructure and provide competing services to BT. Pricing for this is controlled by the regulator, Ofcom. Both FTTC and FTTP are provided as VLANs over gigabit Ethernet interconnections in the Exchange BT/OpenReach is doing a large FTTC deployment across the UK (two thirds of the properties by spring next year I believe), and are starting to roll out FTTP in some areas having been conducting trials since early 2010. I believe that the deployed BT/OpenReach FTT* footprint now covers approximately 13 million properties. The area where I live was one of those listed as getting FTTP last March, but then that was silently scrapped at the last minute for some reason never specified and now they are starting to roll out FTTC to us for this March (only recently announced). It does seem that they are actually doing it this time at least, as the new street cabinets have started appearing and pavements are being dug up, but it's obviously disappointing that we were switched from FTTP to FTTC along with a year's delay. The rest of the city was always supposed to be FTTC and that was rolled out successfully last March. Edward Dore Freethought Internet From owen at delong.com Sat Feb 16 01:10:55 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Feb 2013 17:10:55 -0800 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> <511AC8D2.4060601@necom830.hpcl.titech.ac.jp> <2BD016DC-3F62-4B31-AAE3-F7B031DFA714@freethought-internet.co.uk> <511C3A4A.7050401@necom830.hpcl.titech.ac.jp> Message-ID: > > With BT/OpenReach's FTTC and FTTP there's no difference in terms of layer 1 unbundling - it's impossible with either as they are both shared mediums aggregated before the exchange. > Which is a classic example of why I say the L1 provider must not be allowed to participate in or act as a related party to the L2+ providers. Owen From bill at herrin.us Sat Feb 16 02:17:37 2013 From: bill at herrin.us (William Herrin) Date: Fri, 15 Feb 2013 21:17:37 -0500 Subject: Quantifying the value of customer support In-Reply-To: References: Message-ID: On Feb 14, 2013 12:58 PM, "Kasper Adel" wrote: > We are a 2nd level of escalation in a service provider, > trying to put a $ value on the support we give to > our NOC and other implementation teams, > when they email us about problems they face. Hi Kasper, Support is about customer retention. You solved a customer's problem. As a result, the company continues to recognize revenue from that customer for another year. When you fail, the company loses that revenue stream. Tier 2 support is about solving the difficult customer problems. Often these are Power User problems -- they would have solved a tier 1 problem for themselves. Power Users are interesting because each "recommends" services to something like another dozen customers. They're the "computer guy" the luddites know. When a power user departs upset, other customers will leave over the course of the next 12 months because he recommended something else to them. They won't complain. They won't offer the company an opportunity to retain them. They just leave. So, success on a tier 2 call means retaining not one, but as many as a dozen customers. And that is the value of tier 2 support. You're tier 1 with a multiplier effect on customer retention which is much higher than the difference in your salary. > Can anyone help me with an idea or any material i can reuse? Templates? Has > any one been in a similar situation. Sorry, can't help you there. You'll have to do your own research to put supportable numbers to the claims. Regards, Bill Herrin From jra at baylink.com Sat Feb 16 02:55:46 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 15 Feb 2013 21:55:46 -0500 (EST) Subject: Can the L1 provider offer L2 services? In-Reply-To: Message-ID: <26787708.6263.1360983346076.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > > With BT/OpenReach's FTTC and FTTP there's no difference in terms of > > layer 1 unbundling - it's impossible with either as they are both > > shared mediums aggregated before the exchange. > > Which is a classic example of why I say the L1 provider must not be > allowed to participate in or act as a related party to the L2+ > providers. Submitted: you're saying, Owen, that L2+ providers should not be able to own the L1. I agree with that, and the case in point example is here: http://money.cnn.com/video/technology/2010/03/15/tech_tt_fiber_fios.cnnmoney/ That's orthogonal to the question as we discussed it before, though, which is what I've adjusted the title to here: I don't see that there is a bar to competition if a *municipal* L1 provider offers L2 service, as long as they offer that service to all comers, at the same, published, cost-recovery rates, including themselves. Arguments can be made about "whose tickets take priority" and such, but those seem easy to hand: FCFS. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From ikiris at gmail.com Sat Feb 16 03:19:58 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Fri, 15 Feb 2013 21:19:58 -0600 Subject: Can the L1 provider offer L2 services? In-Reply-To: <26787708.6263.1360983346076.JavaMail.root@benjamin.baylink.com> References: <26787708.6263.1360983346076.JavaMail.root@benjamin.baylink.com> Message-ID: I don't know, I see FCFS as a bad constraint in a lot of situations... Rather just see true separation between conduit and carrier and not have to worry about it. -Blake On Fri, Feb 15, 2013 at 8:55 PM, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Owen DeLong" > > > > With BT/OpenReach's FTTC and FTTP there's no difference in terms of > > > layer 1 unbundling - it's impossible with either as they are both > > > shared mediums aggregated before the exchange. > > > > Which is a classic example of why I say the L1 provider must not be > > allowed to participate in or act as a related party to the L2+ > > providers. > > Submitted: you're saying, Owen, that L2+ providers should not be able > to own the L1. I agree with that, and the case in point example is here: > > > http://money.cnn.com/video/technology/2010/03/15/tech_tt_fiber_fios.cnnmoney/ > > That's orthogonal to the question as we discussed it before, though, > which is what I've adjusted the title to here: I don't see that there > is a bar to competition if a *municipal* L1 provider offers L2 service, > as long as they offer that service to all comers, at the same, published, > cost-recovery rates, including themselves. > > Arguments can be made about "whose tickets take priority" and such, but > those seem easy to hand: FCFS. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > From ablackington at lionlink.net Sat Feb 16 04:29:12 2013 From: ablackington at lionlink.net (Adam Blackington) Date: Fri, 15 Feb 2013 23:29:12 -0500 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: +1 for DME these guys are fantastic. On Fri, Feb 15, 2013 at 10:56 AM, Raj Jalan wrote: > http://www.dnsmadeeasy.com > Cost effective. We use it for some level of failover and load sharing as > well. > > -Raj Jalan > @rjalan2 > > On Thu, Feb 14, 2013 at 2:58 PM, David Hubbard < > dhubbard at dino.hostasaurus.com> wrote: > > > Hi all, anyone have suggestions for very stable/reliable managed DNS? > > Neustar/UltraDNS is an obvious option to look at, just curious about > > alternatives. Cost effective would be nice, but stable under attack is > > better. > > > > Thanks, > > > > David > > > > > From swmike at swm.pp.se Sat Feb 16 04:54:19 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 16 Feb 2013 05:54:19 +0100 (CET) Subject: Fast fibre: A community shows the way In-Reply-To: <20130215161707.GC6172@leitl.org> References: <20130215161707.GC6172@leitl.org> Message-ID: On Fri, 15 Feb 2013, Eugen Leitl wrote: > After deciding that they were never likely to get a fast broadband > connection from one of the major suppliers, a group of local people > across this sparsely populated area decided that sitting around moaning > about it was not an option. Instead they began a DIY effort, digging > channels across the fields and laying fibre optic cables. This is quote common in Sweden as well. People living in the countryside are already used to cooperating, they do private road maintenance cooperatively (5-10 houses sharing an access road to the closest major road), so for them it's not that different to also do cables. Usually tractors or equivalent is already available, so getting someone within the community to do the work is not that hard. Here is an example (In swedish) "For people living in the country side getting access to fiber within reasonable time there is a need for you, neighbours and friends to join into a 'economic association'. With our help you build your own area network to the closest network connection point. Translating it into english works surprisingly well, for your convenience here goes: Byalag model-it works Step 1 Examine and register interest Investigate whether there is interest in your neighbors to join the broadband. Some may have the knowledge and contacts that may be useful. A basic principle is that more households get together and build the area network (fiber) properties to be connected. In this way it is possible to drastically bring down the total connection cost of each property. When there are at least 30 interested, feel more, in an area you should submit an expression of interest to the municipality. Are you less, you should of course make an inquiry anyway. Step 2-Establish a cooperative In order to build an area of ??the village community concept you must use an economic association. In many cases, there is already an economic association established that can be used, such as a village community. If a cooperative is missing, you must create one for this purpose, ie. building broadband. The compound can be dismantled after the construction is completed, if desired. The association shall have a chairman and a contact person for the project. Step 3-Feasibility Study You are doing a feasibility study to get an estimate on the cost of trenching and more. Assistance can be sought from the Leader. Step 4-agreement with the municipality Norkr?pings municipality sign a contract with you. The feasibility study is approved, and a detailed planning undertaken by the municipality. With the feasibility study as a basis, you can also determine how construction costs will be distributed between the members of the village community. Before ground work starts, everything should be clear about what should be done, who is present and all land contracts and permits are in place. Step 5-Review existing agreements Inform everyone in the village community to terminate existing contracts for Internet, television and telephone in time. Step 6 Compare prices Keep in mind that it is only digging work to be purchased because the remaining materials such as fiber cable, hoses, wells, etc. are supplied by us. Our planners are happy to help in this work. Step 7 Start building Come supply all the materials needed for you. Then begin digging. Our recommendation is that you take the help of our planners even at this stage. It creates good conditions for it to go as smoothly as possible. Cost for the designer paid for by the municipality. Step 8-Inspection and connection Once the works are complete, they inspected by the municipality or other authority. Step 9 Use your new broadband Connect your home network to the fiber network and select service providers. Step 10 fee for connection The fee is according to today's current broadband tariff set by the Municipal Council of the Municipality of Norrk?ping. Agreements Examples of contracts and documents Rules of the Association Minutes Registration with the Building and Planning Project Documentation Agreement between the union and the respective owners Land Contract -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Sat Feb 16 04:59:24 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 16 Feb 2013 05:59:24 +0100 (CET) Subject: Can the L1 provider offer L2 services? In-Reply-To: <26787708.6263.1360983346076.JavaMail.root@benjamin.baylink.com> References: <26787708.6263.1360983346076.JavaMail.root@benjamin.baylink.com> Message-ID: On Fri, 15 Feb 2013, Jay Ashworth wrote: > That's orthogonal to the question as we discussed it before, though, > which is what I've adjusted the title to here: I don't see that there is > a bar to competition if a *municipal* L1 provider offers L2 service, as > long as they offer that service to all comers, at the same, published, > cost-recovery rates, including themselves. I agree with this, *but* they should also offer L1 services. Most commonly, they end up doing L2 and then L1 isn't available. The last people in Sweden to get IPv6 is most likely going to be the active municipality network customers, because they need to fix their stuff before the ISP can offer anything (this is because it's ethernet based on L2 and security functions need to exist in the L2 access equipment). If someone says PPPoE is better because of this, please mind that these networks commonly offer speeds up to 500 megabit/s or 1gigabit/s per user. :P -- Mikael Abrahamsson email: swmike at swm.pp.se From owen at delong.com Sat Feb 16 06:22:43 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 15 Feb 2013 22:22:43 -0800 Subject: Can the L1 provider offer L2 services? In-Reply-To: <26787708.6263.1360983346076.JavaMail.root@benjamin.baylink.com> References: <26787708.6263.1360983346076.JavaMail.root@benjamin.baylink.com> Message-ID: <6933B2B3-6EAA-4D25-AFEF-10E8036243C4@delong.com> On Feb 15, 2013, at 18:55 , Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >>> With BT/OpenReach's FTTC and FTTP there's no difference in terms of >>> layer 1 unbundling - it's impossible with either as they are both >>> shared mediums aggregated before the exchange. >> >> Which is a classic example of why I say the L1 provider must not be >> allowed to participate in or act as a related party to the L2+ >> providers. > > Submitted: you're saying, Owen, that L2+ providers should not be able > to own the L1. I agree with that, and the case in point example is here: > > http://money.cnn.com/video/technology/2010/03/15/tech_tt_fiber_fios.cnnmoney/ > > That's orthogonal to the question as we discussed it before, though, > which is what I've adjusted the title to here: I don't see that there > is a bar to competition if a *municipal* L1 provider offers L2 service, > as long as they offer that service to all comers, at the same, published, > cost-recovery rates, including themselves. > I don't see a difference between an L1 provider offering L2 service and an L2 provider owning L1 infrastructure. The problem is that the minute you give an organization an ability to compete with its customers for product (A) as customers for product (B), you create a conflict of interest. If company A offers L1+L2 and company B offers L2 and up, then company A has an incentive to provide better L1 service to those who are also getting their L2 from company A than they might provide to those company B's L2 customers using only the L1 product from company A. > Arguments can be made about "whose tickets take priority" and such, but > those seem easy to hand: FCFS. FCFS sounds like a great theory, but the devil is in the details. Since many tickets are always being processed in parallel and since there will be inevitable shuffling of ticket priorities due to standard externalities (there are always customers you have to take care of more than others, etc.). The more thought I give to this question, the more I think that the L1 provider should be strictly L1 only and not allowed to affiliate with anyone higher up the stack. Owen From edward.dore at freethought-internet.co.uk Sat Feb 16 11:05:46 2013 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Sat, 16 Feb 2013 11:05:46 +0000 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> <511AC8D2.4060601@necom830.hpcl.titech.ac.jp> <2BD016DC-3F62-4B31-AAE3-F7B031DFA714@freethought-internet.co.uk> <511C3A4A.7050401@necom830.hpcl.titech.ac.jp> Message-ID: <7F73AE5F-E326-4000-8807-4E9ADF133E70@freethought-internet.co.uk> I completely agree with you on this Owen, and we were almost in that situation in the UK but Ofcom backed down for some reason :( BT, as a state created monopoly, was facing being broken up with the local loop operations being hived off into a completely separate company to give all providers equal access. In the end, BT somehow managed to convince Ofcom to let them keep the local loop operations in-house, on the condition that it was in a strictly controlled child company where Ofcom sets a lot of the prices. It's a much better situation than we used to have, and it has done a good job of opening up the local loop to competitors, but I can't help but feel that if it had been split off into a completely separate company without BT Group as the parent. At the end of the day, the money still goes into the same group funds and there's still going to be a lot of internal influence from BT in decision making. One interesting recent development is that OpenReach are opening up their ducts and poles so that other providers can install their own fibre in/on them, but from my reading of the limitation on this it sounds like Active Ethernet (or similar) deployments would be impossible as BT/OpenReach have somehow managed to get Ofcom to agree to prevent any deployments that would threaten their leased line business barred: > 3.2 The Customer warrants that it will use the Service solely for the deployment in the Access Network of the Customer?s network serving Multiple Premises for the provision to end users of Next Generation Access Services or the deployment in the Access Network of Sub Loop Unbundling backhaul and for no other purpose whatsoever, in particular not for: > > 3.2.1 leased lines for the provision of point to point services offered with the intent or effect of providing private circuit type services; > > 3.2.2 direct connection between two Customer Points of Handover or any other connection which may be regarded as core network; or > > 3.2.3 backhaul services, including fixed or mobile and wireless backhaul services, with the exception of Sub Loop Unbundling backhaul services for fixed traffic (inclusive of Sub Loop Unbundling daisy chain aggregation) to the Local Access Node or Customer Point of Handover. > > as more fully described in the Duct and Pole Sharing Product Description, > > If the Customer uses the Services for any other purposes than for the deployment in accordance with clause 3.2 above, this will be a material breach of this Agreement under clause 2.3 (a) (ii) and BT may also at its sole discretion refuse to accept any Orders for the Service on notice to the Customer until the breach has been rectified. Of course, IANAL so may be getting that completely backwards :) Edward Dore Freethought Internet On 16 Feb 2013, at 01:10, Owen DeLong wrote: >> >> With BT/OpenReach's FTTC and FTTP there's no difference in terms of layer 1 unbundling - it's impossible with either as they are both shared mediums aggregated before the exchange. >> > > Which is a classic example of why I say the L1 provider must not be allowed to participate in or act as a related party to the L2+ providers. > > Owen > From mohta at necom830.hpcl.titech.ac.jp Sat Feb 16 11:30:14 2013 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Sat, 16 Feb 2013 20:30:14 +0900 Subject: Muni fiber: L1 or L2? In-Reply-To: References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> <511AC8D2.4060601@necom830.hpcl.titech.ac.jp> <2BD016DC-3F62-4B31-AAE3-F7B031DFA714@freethought-internet.co.uk> <511C3A4A.7050401@necom830.hpcl.titech.ac.jp> Message-ID: <511F6DC6.3070608@necom830.hpcl.titech.ac.jp> Edward Dore wrote: >> Sadly, it is impossible to say FTTC not "fiber optic broadband", >> because it is "broadband" (at least with today's access speed) >> with "fiber optic". > > Then why would you not also consider bog standard ADSL to also > be "fibre optic"? Because I think "fiber optic broadband" implies access and ADSL is no fiber optic broadband access, unless you have FTTC with not VDSL but ADSL. But, feel free to have your own definition, which may or may not be legally challenged by people having common sense. > With BT/OpenReach's FTTC and FTTP there's no difference in > terms of layer 1 unbundling - it's impossible with either as > they are both shared mediums aggregated before the exchange. Both of them sucks badly, indeed. > There is also an "FTTP on-demenad" option where if you are in > a FTTC area then you basically pay for BT/OpenReach to extend > the fibre to your property and provide the FTTP service. This > is expensive though as you foot all of the excess construction > charges. Apparently the average cost is going to be around GBP > 1500. I changed your pond sign in windows 1252 encoding (even though your improperly configured mailer says it ISO-8859-1) to GBP. I think 1500 GBP is too high as a cost to have fiber between a cabinet and your premise. Considering that cost of SS is almost identical to POTS, the reasonable cost should be GBP 500 or so. Is it a result of BT monopoly or can there be some competition possible to choose an entity to install the fiber from multiple independent entities? > In either case, OpenReach are required to provide "open" > access at the exchange to any companies wishing to make use of > the local infrastructure and provide competing services to BT. The problem is on the density of the exchanges. The exchanges at every CO with L1 unbundling is, seemingly, most competitive against BT. Masataka Ohta From edward.dore at freethought-internet.co.uk Sat Feb 16 11:56:44 2013 From: edward.dore at freethought-internet.co.uk (Edward Dore) Date: Sat, 16 Feb 2013 11:56:44 +0000 Subject: Muni fiber: L1 or L2? In-Reply-To: <511F6DC6.3070608@necom830.hpcl.titech.ac.jp> References: <30393215.5773.1360610021862.JavaMail.root@benjamin.baylink.com> <51195E58.20800@sprunk.org> <5119897C.4010007@sprunk.org> <51199011.7050903@necom830.hpcl.titech.ac.jp> <511AAA70.6090902@necom830.hpcl.titech.ac.jp> <511AC8D2.4060601@necom830.hpcl.titech.ac.jp> <2BD016DC-3F62-4B31-AAE3-F7B031DFA714@freethought-internet.co.uk> <511C3A4A.7050401@necom830.hpcl.titech.ac.jp> <511F6DC6.3070608@necom830.hpcl.titech.ac.jp> Message-ID: On 16 Feb 2013, at 11:30, Masataka Ohta wrote: > Edward Dore wrote: > >>> Sadly, it is impossible to say FTTC not "fiber optic broadband", >>> because it is "broadband" (at least with today's access speed) >>> with "fiber optic". >> >> Then why would you not also consider bog standard ADSL to also > > be "fibre optic"? > > Because I think "fiber optic broadband" implies access and ADSL > is no fiber optic broadband access, unless you have FTTC with not > VDSL but ADSL. > > But, feel free to have your own definition, which may or may not > be legally challenged by people having common sense. Both ADSL fed from the exchange and VDSL fed from the street cabinet have a portion provided over fibre... where is the magic separation point that moves it from not being "fibre optic broadband" to being "fibre optic broadband"? >> With BT/OpenReach's FTTC and FTTP there's no difference in > > terms of layer 1 unbundling - it's impossible with either as > > they are both shared mediums aggregated before the exchange. > > Both of them sucks badly, indeed. > >> There is also an "FTTP on-demenad" option where if you are in > > a FTTC area then you basically pay for BT/OpenReach to extend > > the fibre to your property and provide the FTTP service. This > > is expensive though as you foot all of the excess construction > > charges. Apparently the average cost is going to be around GBP > > 1500. > > I changed your pond sign in windows 1252 encoding (even though > your improperly configured mailer says it ISO-8859-1) to GBP. > > I think 1500 GBP is too high as a cost to have fiber between a > cabinet and your premise. > > Considering that cost of SS is almost identical to POTS, the > reasonable cost should be GBP 500 or so. > > Is it a result of BT monopoly or can there be some competition > possible to choose an entity to install the fiber from multiple > independent entities? The ?1500 is what BT are quoting as an average based on distance. The cost works out as something like a fixed ?500 setup + a per meter charge which varies depending on how they have to get from the cabinet to your property + any other civils/construction work required along the way. For example, grass verges are much cheaper than pavements which are in turn cheaper than roads. They also have set charges for things like drilling through a wall depending on whether it is internal or external and if it is concrete or not concrete. There's a list of the current OpenReach Excess COnstruction Charges at http://www.openreach.co.uk/orpg/home/products/pricing/loadProductPriceDetails.do?data=ZdqG%2Fxv%2FjSuBEEITnogh5uNOEwQ2%2FKws5WBAVcIlcholMnGHsqdC0vzO163bJmh34D91D7M0q8u%2F%0AIlSgtIFAKw%3D%3D Unfortunately, only OpenReach can install these as part of the "FTTP on-demand" product. Any OpenReach service provider customer can order these, but it is OpenReach (part of the BT Group) that does the work. >> In either case, OpenReach are required to provide "open" >> access at the exchange to any companies wishing to make use of > > the local infrastructure and provide competing services to BT. > > The problem is on the density of the exchanges. > > The exchanges at every CO with L1 unbundling is, seemingly, most > competitive against BT. OpenReach are required to sell space+power at the exchange for co-location of service provider equipment as well as selling all of the services that they sell internally in to the wholesale and retail divisions in the BT Group. It is then up to the service provider to aggregate customers and arrange their own backhaul, which obviously means that exchanges with a lower density of customers and/or which are more remote and therefore more expensive to arrange backhaul from are less attractive to unbundle. What generally ends up happening is that the service providers competing with BT unbundle the more attractive exchanges where it makes financial sense to do so and then use BT Wholesale services to cover the other exchanges with more expensive, slower products that include a lower monthly cap due to the high cost of backhaul on the BT Wholesale network. Edward Dore Freethought Internet From fernando at gont.com.ar Sat Feb 16 18:18:20 2013 From: fernando at gont.com.ar (Fernando Gont) Date: Sat, 16 Feb 2013 15:18:20 -0300 Subject: SI6 Networks IPv6 Toolkit v1.3 released! Message-ID: <511FCD6C.60004@gont.com.ar> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, We are pleased to release the SI6 Networks' IPv6 Toolkit v1.3: a security assessment and trouble-shooting toolkit for the IPv6 protocol suite. The toolkit is available at: , where you can find a the usual tarball, a PGP-signed version of it, a link to the toolkit's GIT repository, etc. This release has a number of features: * It includes a full-fledged IPv6 address scanning tool (scan6) -- probably the only comprehensive IPv6 address scanning tool out there. Check out all the newly incorporated features! * It includes support for tunnels (in most of the tools). So if you are currently employing e.g. a free IPv6 tunnel to connect to the IPv6 Internet, you'll now be able t play with the tools using your tunnel. * Adds features that have been in our "todo list" for a while: + It includes manual pages in troff format for all the tools. + It includes a makefile, to easily build and install the tools, configuration file, manuals, etc., on your local system. The toolkit runs on (at least) the latest versions of Linux, FreeBSD, NetBSD, OpenBSD, and Mac OS X. Please send any bug reports and/or feature requests to . As always, you can get the latest news on IPv6 security research and tools by following us on Twitter: @SI6Networks. Thanks! Best regards, - -- Fernando Gont SI6 Networks e-mail: fgont at si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 - -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRH81hAAoJEJbuqe/Qdv/xvogH/jpydcxEaII0cRMoF7r9yDfL uV4LJYYsGg56pHn07UEaa8SWFtZP5/ynuq+9A9bmPuXzuRshOLj87MBqL3FOBAXO 9C6GwiyHP/OfpkLC+QIEp2WlNMFQ4n2d0/wIotKvMtz7XZMKkYyP2Awcu0yQTH/f /EglnuOvXWFNgz+CI1FcRFJ5+TOWJjFf5AnNT44toVcVzDEiaXDcp2xcAyLX+bmn 3WrNUIjZtV4hibwbrxxPrHHC+0U6YxfW2aqNfI3PMWl2N9GdoJAOHsQT6Qn6TyXG +AjPoCaZI/RovWpDEYM2Z8UcvHwFOgBguwIgqKO0/3rw78co8OziJNtWd2lCJkI= =Rrjk -----END PGP SIGNATURE----- From cloos at jhcloos.com Sun Feb 17 00:40:30 2013 From: cloos at jhcloos.com (James Cloos) Date: Sat, 16 Feb 2013 19:40:30 -0500 Subject: 10 Mbit/s problem in your network In-Reply-To: <5118D678.2000107@necom830.hpcl.titech.ac.jp> (Masataka Ohta's message of "Mon, 11 Feb 2013 20:31:04 +0900") References: <5118D678.2000107@necom830.hpcl.titech.ac.jp> Message-ID: >>>>> "MO" == Masataka Ohta writes: MO> Internet connectivity (FTTH) Fibre-To-The-Hotel, eh? :) :) :) :) :) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From mysidia at gmail.com Sun Feb 17 01:37:09 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 16 Feb 2013 19:37:09 -0600 Subject: 10 Mbit/s problem in your network In-Reply-To: <20130211125111.GA15626@airstripone.org.uk> References: <20130211125111.GA15626@airstripone.org.uk> Message-ID: On 2/11/13, Graham Donaldson wrote: > On Sat, Feb 09, 2013 at 07:55:59PM -0800, Constantine A. Murenin wrote: > I personally think you're being unreasonable on the bandwidth and latency > expectations, Hotel Internet connections are > there as a convenience rather than some kind of business grade connection. Hey, the name business grade connection is prejudiced, as if to imply, that only businesses get it. I think the expectation from a visitor, is only, that their internet experience will be comparable to their home cable/dsl internet. If it's not... that's fine, but they should provide disclosure of that, whenever mentioning the feature, before a reservation could be made. Of course there can be no worldwide standard, but there should be a standard, based on what is normal in the country. If the advertising tells you, that the room has electric lights, air conditioning, and cable tv; you don't want to see a room that just has a 9 volt battery, a little LED lamp, as your light source -- a portable battery powered fan. And a single shared television in the lobby, plugged into a cable provider that charges a per-minute fee to visitors wishing to see anything other than channel 3. > Graham. -- -JH From mureninc at gmail.com Sun Feb 17 02:12:25 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Sat, 16 Feb 2013 18:12:25 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: <6f7463e86492204c83dc874e049161b9@mail.dessus.com> References: <-4891392952970062557@unknownmsgid> <6f7463e86492204c83dc874e049161b9@mail.dessus.com> Message-ID: On 9 February 2013 22:49, Keith Medcalf wrote: > > Most of these networks are provided by "Internet Marketing Companies". In exchange for free-reign in data harvesting and data capture/logging/tracking and advertisement/javascript insertion in web pages (etc), the hotel gets to offer "free" internet connections. Often the Hotel Internet is a profit center for the Hotel, the "Internet Company" paying the Hotel for unrestricted diddling rights to the unsuspecting guests traffic. > > Same applies to almost every business that offers "free complimentary internet connections" ... > > Occasionally you run into a Hotel that offers a quality and clean internet connection, however, these are few and far between ... Several 2.5* / 3* hotel managers I spoke with volunteered, implied or confirmed that they're paying on the order of 2k$/mo for "internet" in Northern California. And at least in the US, I'm yet to encounter a complementary WiFi at any hotel that would be doing JavaScript insertion, so I'm not sure where you get your information that the free internet always means ads or a very high level of tampering. One of my prior residential ISPs, Embarq, arguably did more tampering and data mining with my connection than any of the hotels I have ever stayed at. (I'm talking about DNS hijacking.) Now. Notice that these hotels are already paying 2k$/mo and getting 10Mbps, which residentially retails at 40$/mo. How much will 100Mbps cost them? What, still 2k/mo? What are they waiting for? Or, pardon my residential bias, but are some of them still using T1's? Don't those cost a fortune? Wouldn't they actually save their money by going elsewhere? I hear microwave links are pretty popular these days, and offer great bandwidth and latency. C. >> -----Original Message----- >> From: Mike Lyon [mailto:mike.lyon at gmail.com] >> Sent: Saturday, 09 February, 2013 23:23 >> To: Constantine A. Murenin >> Cc: North American Network Operators' Group >> Subject: Re: 10 Mbit/s problem in your network >> >> "why do the sub-contracted internet support companies design and >> support such broken-by-design setups?" >> >> Because they don't know any better and lack the technical clue on how >> to implement a network that can support a hotel-full (or half-full) of >> people... >> >> But i'm sure they all have their MCSEs and CCNAs so they are qualified :) >> >> -mike >> >> Sent from my iPhone >> >> On Feb 9, 2013, at 19:57, "Constantine A. Murenin" >> wrote: >> >> > why do the sub-contracted internet support >> > companies design and support such broken-by-design setups? From scott at doc.net.au Sun Feb 17 08:36:25 2013 From: scott at doc.net.au (Scott Howard) Date: Sun, 17 Feb 2013 00:36:25 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: References: <-4891392952970062557@unknownmsgid> <6f7463e86492204c83dc874e049161b9@mail.dessus.com> Message-ID: On Sat, Feb 16, 2013 at 6:12 PM, Constantine A. Murenin wrote: > And at least in the US, I'm yet to encounter a complementary WiFi at any hotel that would be doing JavaScript insertion, so I'm not sure > where you get your information that the free internet always means ads > or a very high level of tampering. > They exist, although they are rare. eg, http://bits.blogs.nytimes.com/2012/04/06/courtyard-marriott-wifi/ (This particular hotel apparently stopped shortly after this news broke) On Sun, Feb 10, 2013 at 8:11 AM, M?ns Nilsson wrote: > A VPN or SSH session (which is what most hotel guests traveling for > work will do) won't cache at all well, so this is a very bad idea. Might > improve some things, but not the really important ones. > The chances of the average hotel wifi user even knowing what SSH means is close to zero. VPN connections are obviously common, but are becoming fewer and fewer by the day - especially non-split tunnel VPN. An on-site transparent proxy(with or without cache) will improve performance to at least some extent, if only because it's isolating the issues of the local network (potentially congested wifi in an environment that really isn't designed for good wifi coverage!) from the upstream. It's far better (and quicker) to handle a dropped packet between the client and the proxy than between the client and the webserver. >From personal experience (around a dozen different hotels this year already) the best thing you can to do improve performance is to avoid Wifi and revert to a wired connection - or if you really want a wireless connection take your own travel wifi router and connect it via a wired connection. The performance difference in many hotels is significant, showing that the problem is often less the hotels Internet connection, and more their wifi. As an aside, I was sitting in JFK airport (terminal 4) a few days ago and having a shocking time getting a good internet connection - even from my own Mifi. I fired up inSSIDer, and within a few seconds it had detected 122 AP's... Scott. From jra at baylink.com Sun Feb 17 16:33:44 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 17 Feb 2013 11:33:44 -0500 (EST) Subject: 10 Mbit/s problem in your network In-Reply-To: Message-ID: <28915468.6329.1361118824719.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Howard" > > A VPN or SSH session (which is what most hotel guests traveling for > > work will do) won't cache at all well, so this is a very bad idea. > > Might improve some things, but not the really important ones. > > The chances of the average hotel wifi user even knowing what SSH means > is close to zero. {{citation-needed}} > As an aside, I was sitting in JFK airport (terminal 4) a few days ago and > having a shocking time getting a good internet connection - even from my > own Mifi. I fired up inSSIDer, and within a few seconds it had detected > 122 AP's... Yup; B/G/N congestion is a real problem. Nice that the latest generation of both mifi's and cellphones all seem to do A as well, in addition to current-gen business laptops (my x61 is almost 5 years old, and speaks A). Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From joelja at bogus.com Sun Feb 17 16:49:03 2013 From: joelja at bogus.com (joel jaeggli) Date: Sun, 17 Feb 2013 08:49:03 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: <28915468.6329.1361118824719.JavaMail.root@benjamin.baylink.com> References: <28915468.6329.1361118824719.JavaMail.root@benjamin.baylink.com> Message-ID: <512109FF.1000305@bogus.com> On 2/17/13 8:33 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Scott Howard" >>> A VPN or SSH session (which is what most hotel guests traveling for >>> work will do) won't cache at all well, so this is a very bad idea. >>> Might improve some things, but not the really important ones. >> The chances of the average hotel wifi user even knowing what SSH means >> is close to zero. > {{citation-needed}} The crapy facebook games that everyone plays are both latency senstive and unhappy when their connections are reset. zynga poker peaked at something like 38 million players (per wikipedia) > >> As an aside, I was sitting in JFK airport (terminal 4) a few days ago and >> having a shocking time getting a good internet connection - even from my >> own Mifi. I fired up inSSIDer, and within a few seconds it had detected >> 122 AP's... > Yup; B/G/N congestion is a real problem. Nice that the latest generation > of both mifi's and cellphones all seem to do A as well, in addition to > current-gen business laptops (my x61 is almost 5 years old, and speaks A). > > Cheers, > -- jra From owen at delong.com Sun Feb 17 20:07:13 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 17 Feb 2013 12:07:13 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: <28915468.6329.1361118824719.JavaMail.root@benjamin.baylink.com> References: <28915468.6329.1361118824719.JavaMail.root@benjamin.baylink.com> Message-ID: On Feb 17, 2013, at 08:33 , Jay Ashworth wrote: > ----- Original Message ----- >> From: "Scott Howard" > >>> A VPN or SSH session (which is what most hotel guests traveling for >>> work will do) won't cache at all well, so this is a very bad idea. >>> Might improve some things, but not the really important ones. >> >> The chances of the average hotel wifi user even knowing what SSH means >> is close to zero. > > {{citation-needed}} > >> As an aside, I was sitting in JFK airport (terminal 4) a few days ago and >> having a shocking time getting a good internet connection - even from my >> own Mifi. I fired up inSSIDer, and within a few seconds it had detected >> 122 AP's... > > Yup; B/G/N congestion is a real problem. Nice that the latest generation > of both mifi's and cellphones all seem to do A as well, in addition to > current-gen business laptops (my x61 is almost 5 years old, and speaks A). > I think by A you actually mean 5Ghz N. A doesn't do much better than G, though you still have the advantage of wider channels and less frequency congestion with other uses. Owen From jra at baylink.com Sun Feb 17 20:18:56 2013 From: jra at baylink.com (Jay Ashworth) Date: Sun, 17 Feb 2013 15:18:56 -0500 (EST) Subject: 10 Mbit/s problem in your network In-Reply-To: Message-ID: <21152885.6381.1361132336307.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > I think by A you actually mean 5Ghz N. A doesn't do much better than G, though > you still have the advantage of wider channels and less frequency congestion > with other uses. No, my ThinkPad doesn't *do* N, 5GHz or otherwise. Neither does my Sprint EVO, nor, as near as I can tell, the Galaxy S4 I'm going to replace it with this year (though on that one, I'm a tad less certain). I'd forgotten that N was dual band, though, yes. I can't say I've ever needed the extra bandwidth N provides, personally, though certainly the hotels we've been discussing might need more to share around. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From joelja at bogus.com Mon Feb 18 00:17:40 2013 From: joelja at bogus.com (joel jaeggli) Date: Sun, 17 Feb 2013 16:17:40 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: <21152885.6381.1361132336307.JavaMail.root@benjamin.baylink.com> References: <21152885.6381.1361132336307.JavaMail.root@benjamin.baylink.com> Message-ID: <51217324.4010509@bogus.com> On 2/17/13 12:18 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" >> I think by A you actually mean 5Ghz N. A doesn't do much better than G, though >> you still have the advantage of wider channels and less frequency congestion >> with other uses. > No, my ThinkPad doesn't *do* N, 5GHz or otherwise. Neither does my Sprint > EVO, nor, as near as I can tell, the Galaxy S4 I'm going to replace it > with this year (though on that one, I'm a tad less certain). > > I'd forgotten that N was dual band, though, yes. I can't say I've ever > needed the extra bandwidth N provides, personally, though certainly the > hotels we've been discussing might need more to share around. entirely orthonal to the frequency band used spatial division multipluxing as used by 802.11n is generally going to increase the SNR. so what you get out of A/N is: * more non-overlapping bands and therefore a much easier map coloring problem) * greater attentuation, which implies more limited range, but also less interferance. * with N-mimo higher SNR if you have >= 2 antennas All of those things make the 5Ghz band a more attractive alternative for lots of applications. given that it's 5Ghz it also requires more power, which is a problem for cellphones, but not so much for tablets and laptops. > Cheers, > -- jra From owen at delong.com Mon Feb 18 00:32:13 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 17 Feb 2013 16:32:13 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: <51217324.4010509@bogus.com> References: <21152885.6381.1361132336307.JavaMail.root@benjamin.baylink.com> <51217324.4010509@bogus.com> Message-ID: <6ADF01F8-557E-4FA6-826E-AC44C07036F9@delong.com> On Feb 17, 2013, at 4:17 PM, joel jaeggli wrote: > On 2/17/13 12:18 PM, Jay Ashworth wrote: >> ----- Original Message ----- >>> From: "Owen DeLong" >>> I think by A you actually mean 5Ghz N. A doesn't do much better than G, though >>> you still have the advantage of wider channels and less frequency congestion >>> with other uses. >> No, my ThinkPad doesn't *do* N, 5GHz or otherwise. Neither does my Sprint >> EVO, nor, as near as I can tell, the Galaxy S4 I'm going to replace it >> with this year (though on that one, I'm a tad less certain). >> >> I'd forgotten that N was dual band, though, yes. I can't say I've ever >> needed the extra bandwidth N provides, personally, though certainly the >> hotels we've been discussing might need more to share around. > entirely orthonal to the frequency band used spatial division multipluxing as used by 802.11n is generally going to increase the SNR. > > so what you get out of A/N is: > > * more non-overlapping bands and therefore a much easier map coloring problem) > * greater attenuation, which implies more limited range, but also less interferance. Greater attenuation is an oversimplification. 5Ghz penetrates things like stucco and concrete better than 2.4. OTOH, 2.4 gets through trees and moist air better. In dry air and/or a vacuum, they're similar. Neither penetrates humans particularly well, though 5 tends to do slightly better. > * with N-mimo higher SNR if you have >= 2 antennas > > All of those things make the 5Ghz band a more attractive alternative for lots of applications. given that it's 5Ghz it also requires more power, which is a problem for cellphones, but not so much for tablets and laptops. OTOH, with 5Ghz, a high-gain antenna is ? - ? the size (depending on the type of antenna) the size of a 2.4Ghz which also has advantages in portable applications. Owen From owen at delong.com Mon Feb 18 00:33:02 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 17 Feb 2013 16:33:02 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: <6ADF01F8-557E-4FA6-826E-AC44C07036F9@delong.com> References: <21152885.6381.1361132336307.JavaMail.root@benjamin.baylink.com> <51217324.4010509@bogus.com> <6ADF01F8-557E-4FA6-826E-AC44C07036F9@delong.com> Message-ID: On Feb 17, 2013, at 4:32 PM, Owen DeLong wrote: > > On Feb 17, 2013, at 4:17 PM, joel jaeggli wrote: > >> On 2/17/13 12:18 PM, Jay Ashworth wrote: >>> ----- Original Message ----- >>>> From: "Owen DeLong" >>>> I think by A you actually mean 5Ghz N. A doesn't do much better than G, though >>>> you still have the advantage of wider channels and less frequency congestion >>>> with other uses. >>> No, my ThinkPad doesn't *do* N, 5GHz or otherwise. Neither does my Sprint >>> EVO, nor, as near as I can tell, the Galaxy S4 I'm going to replace it >>> with this year (though on that one, I'm a tad less certain). >>> >>> I'd forgotten that N was dual band, though, yes. I can't say I've ever >>> needed the extra bandwidth N provides, personally, though certainly the >>> hotels we've been discussing might need more to share around. >> entirely orthonal to the frequency band used spatial division multipluxing as used by 802.11n is generally going to increase the SNR. >> >> so what you get out of A/N is: >> >> * more non-overlapping bands and therefore a much easier map coloring problem) >> * greater attenuation, which implies more limited range, but also less interferance. > > Greater attenuation is an oversimplification. 5Ghz penetrates things like stucco and concrete better than 2.4. OTOH, 2.4 gets through trees and moist air better. In dry air and/or a vacuum, they're similar. Neither penetrates humans particularly well, though 5 tends to do slightly better. > >> * with N-mimo higher SNR if you have >= 2 antennas >> >> All of those things make the 5Ghz band a more attractive alternative for lots of applications. given that it's 5Ghz it also requires more power, which is a problem for cellphones, but not so much for tablets and laptops. > > OTOH, with 5Ghz, a high-gain antenna is ? - ? the size (depending on the type of antenna) the size of a 2.4Ghz which also has advantages in portable applications. > Sorry? Hit send prematurely? An important consideration: A good high-gain antenna helps you with transmit _AND_ receive. More power helps you with transmit. > Owen > From swmike at swm.pp.se Mon Feb 18 05:12:27 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 18 Feb 2013 06:12:27 +0100 (CET) Subject: 10 Mbit/s problem in your network In-Reply-To: <6ADF01F8-557E-4FA6-826E-AC44C07036F9@delong.com> References: <21152885.6381.1361132336307.JavaMail.root@benjamin.baylink.com> <51217324.4010509@bogus.com> <6ADF01F8-557E-4FA6-826E-AC44C07036F9@delong.com> Message-ID: On Sun, 17 Feb 2013, Owen DeLong wrote: > Greater attenuation is an oversimplification. 5Ghz penetrates things > like stucco and concrete better than 2.4. OTOH, 2.4 gets through trees My empirical experience with 5GHz says it penetrates concrete a lot less than 2.4. For instance, in one building I was in, 5GHz didn't penetrate the floor so it was only available on the same floor as the AP, but 2.4 GHz worked well both on the floor above and below the AP. This was in a building with quite thick concrete floor, a 3 story town house with the AP placed on the middle. In my current apartment, I moved my AP out of the clothes closet (fairly thin "light concrete" (don't know what it's called) and put it on the wall in my hallway, this increased performance on 5GHz substantially. So I'd like to know where you got your information from because I'd like to read up more because my experience says exactly the opposite. Apart from that, 5GHz is great. More bandwidth, less crowded. -- Mikael Abrahamsson email: swmike at swm.pp.se From owen at delong.com Mon Feb 18 09:42:04 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Feb 2013 01:42:04 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: References: <21152885.6381.1361132336307.JavaMail.root@benjamin.baylink.com> <51217324.4010509@bogus.com> <6ADF01F8-557E-4FA6-826E-AC44C07036F9@delong.com> Message-ID: <385A965A-09A7-4818-BCBF-810448D91AD6@delong.com> On Feb 17, 2013, at 21:12 , Mikael Abrahamsson wrote: > On Sun, 17 Feb 2013, Owen DeLong wrote: > >> Greater attenuation is an oversimplification. 5Ghz penetrates things like stucco and concrete better than 2.4. OTOH, 2.4 gets through trees > > My empirical experience with 5GHz says it penetrates concrete a lot less than 2.4. For instance, in one building I was in, 5GHz didn't penetrate the floor so it was only available on the same floor as the AP, but 2.4 GHz worked well both on the floor above and below the AP. This was in a building with quite thick concrete floor, a 3 story town house with the AP placed on the middle. The floor isn't just concrete. Many industrial floors include solid steel plating in the floor. 5 Ghz will not penetrate that and neither will 2.4 (at least not very well). A town house is also likely to have some form of metal plating (or at least a very high concentration of rebar) in the concrete between floors as well, so, I suspect your issue was the metal, not the concrete. 2.4Ghz probably found a path around the outside of the building and back in. 5Ghz once it starts in a direction tends to continue in that direction. It doesn't bounce or curve well at all. 2.4Ghz tends to do better at that, creating the illusion of lesser attenuation. As I said, attenuation is an oversimplification. RF path identification and multipath can get very complex very quickly. > > In my current apartment, I moved my AP out of the clothes closet (fairly thin "light concrete" (don't know what it's called) and put it on the wall in my hallway, this increased performance on 5GHz substantially. > > So I'd like to know where you got your information from because I'd like to read up more because my experience says exactly the opposite. Without knowing the details of the makeup of the walls in your closet, I have to say that seems a bit odd to me. Perhaps there is another explanation. The reason 5Ghz penetrates stucco better, for example is that the 23cm wavelength is more than 4x the size of the openings in most of the chicken wire used to adhere stucco to walls. The 12cm wavelength of 5Ghz, OTOH, goes through quite nicely. Owen From swmike at swm.pp.se Mon Feb 18 10:59:26 2013 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 18 Feb 2013 11:59:26 +0100 (CET) Subject: 10 Mbit/s problem in your network In-Reply-To: <385A965A-09A7-4818-BCBF-810448D91AD6@delong.com> References: <21152885.6381.1361132336307.JavaMail.root@benjamin.baylink.com> <51217324.4010509@bogus.com> <6ADF01F8-557E-4FA6-826E-AC44C07036F9@delong.com> <385A965A-09A7-4818-BCBF-810448D91AD6@delong.com> Message-ID: On Mon, 18 Feb 2013, Owen DeLong wrote: > The reason 5Ghz penetrates stucco better, for example is that the 23cm > wavelength is more than 4x the size of the openings in most of the > chicken wire used to adhere stucco to walls. The 12cm wavelength of > 5Ghz, OTOH, goes through quite nicely. "Aside from large cement blocks and red bricks that displayed somewhat more loss at 5 GHz than at 2.4 GHz (Table 3), losses for all other materials tested were very much the same in both frequency regimes." Looking at their chart on page 9, I see substantially higher attenuation for cinder blocks, 5% lower attenuation with stucco, and 3x attenuation through red bricks. If concrete (10cm think or even more) is similar to red bricks in attenuation, then that would explain the behaviour I have observed in real life. The only material that 5GHz had a lot lower attenuation with was diamond mesh. -- Mikael Abrahamsson email: swmike at swm.pp.se From paigeadele at gmail.com Sun Feb 17 10:29:42 2013 From: paigeadele at gmail.com (Adele Thompson) Date: Sun, 17 Feb 2013 02:29:42 -0800 Subject: Suggestions for managed DNS provider? In-Reply-To: References: Message-ID: Diy++ Dbap++ On Feb 15, 2013 8:31 PM, "Adam Blackington" wrote: > +1 for DME these guys are fantastic. > > > On Fri, Feb 15, 2013 at 10:56 AM, Raj Jalan wrote: > > > http://www.dnsmadeeasy.com > > Cost effective. We use it for some level of failover and load sharing as > > well. > > > > -Raj Jalan > > @rjalan2 > > > > On Thu, Feb 14, 2013 at 2:58 PM, David Hubbard < > > dhubbard at dino.hostasaurus.com> wrote: > > > > > Hi all, anyone have suggestions for very stable/reliable managed DNS? > > > Neustar/UltraDNS is an obvious option to look at, just curious about > > > alternatives. Cost effective would be nice, but stable under attack is > > > better. > > > > > > Thanks, > > > > > > David > > > > > > > > > From joelja at bogus.com Mon Feb 18 23:07:41 2013 From: joelja at bogus.com (joel jaeggli) Date: Mon, 18 Feb 2013 15:07:41 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: <385A965A-09A7-4818-BCBF-810448D91AD6@delong.com> References: <21152885.6381.1361132336307.JavaMail.root@benjamin.baylink.com> <51217324.4010509@bogus.com> <6ADF01F8-557E-4FA6-826E-AC44C07036F9@delong.com> <385A965A-09A7-4818-BCBF-810448D91AD6@delong.com> Message-ID: <5122B43D.6070409@bogus.com> On 2/18/13 1:42 AM, Owen DeLong wrote: > On Feb 17, 2013, at 21:12 , Mikael Abrahamsson wrote: > >> On Sun, 17 Feb 2013, Owen DeLong wrote: >> >>> Greater attenuation is an oversimplification. Along some dimensions sure, e.g. we have quite a lot of parameters we can fiddle with. With respect to an istropic raditor and the same power level it is not. It's about 6-7dB depending on which end of the bands we're comparing - e.g. friis trasmission equation. From owen at delong.com Mon Feb 18 23:52:57 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Feb 2013 15:52:57 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: <5122B43D.6070409@bogus.com> References: <21152885.6381.1361132336307.JavaMail.root@benjamin.baylink.com> <51217324.4010509@bogus.com> <6ADF01F8-557E-4FA6-826E-AC44C07036F9@delong.com> <385A965A-09A7-4818-BCBF-810448D91AD6@delong.com> <5122B43D.6070409@bogus.com> Message-ID: On Feb 18, 2013, at 3:07 PM, joel jaeggli wrote: > On 2/18/13 1:42 AM, Owen DeLong wrote: >> On Feb 17, 2013, at 21:12 , Mikael Abrahamsson wrote: >> >>> On Sun, 17 Feb 2013, Owen DeLong wrote: >>> >>>> Greater attenuation is an oversimplification. > > Along some dimensions sure, e.g. we have quite a lot of parameters we can fiddle with. > > With respect to an istropic raditor and the same power level it is not. It's about 6-7dB depending on which end of the bands we're comparing - e.g. friis trasmission equation. Show me a wifi access point for 802.11n that uses an isotropic radiator and I'll consider that more relevant. (Yes, I'm aware that an isotropic radiator is useful as a baseline comparison because it eliminates antenna issues, near-field/far field issues, and a host of other complications. However, the purpose of an isotropic radiator is, at its core, the very definition of oversimplification because it is a theoretical antenna which removes all of the real world complexities. To the best of my knowledge, nobody has ever actually built an isotropic radiator, though there are a couple of very complex antennas that come a little closer than a ? wave whip.) Owen From jra at baylink.com Tue Feb 19 03:23:51 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 18 Feb 2013 22:23:51 -0500 Subject: NYT covers China cyberthreat Message-ID: <94bf868f-e631-49ca-b5c8-b1ed0f9333f2@email.android.com> http://www.nytimes.com/2013/02/19/technology/chinas-army-is-seen-as-tied-to-hacking-against-us.html?pagewanted=all -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From jra at baylink.com Tue Feb 19 05:05:10 2013 From: jra at baylink.com (jra at baylink.com) Date: 19 Feb 2013 05:05:10 +0000 Subject: VOA - Voice of America English News Message-ID: Jay Ashworth has sent you an article from VOAnews.com: http://www.voanews.com/content/skorea-says-nkorean-leadership-wont-be-convinced-to-abandon-nukes/1604190.html From jra at baylink.com Tue Feb 19 05:09:55 2013 From: jra at baylink.com (jra at baylink.com) Date: 19 Feb 2013 05:09:55 +0000 Subject: VOA - Voice of America English News Message-ID: Jay Ashworth has sent you an article from VOAnews.com: http://www.voanews.com/content/russian-officials-say-city-survived-space-attack/1606017.html From jra at baylink.com Tue Feb 19 05:45:06 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 19 Feb 2013 00:45:06 -0500 Subject: VOA - Voice of America English News In-Reply-To: References: Message-ID: He did like hell. This is not his first (or tenth) rodeo. Cheers, - jra jra at baylink.com wrote: >Jay Ashworth has sent you an article from VOAnews.com: >http://www.voanews.com/content/skorea-says-nkorean-leadership-wont-be-convinced-to-abandon-nukes/1604190.html -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From jra at baylink.com Tue Feb 19 15:20:12 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 19 Feb 2013 10:20:12 -0500 (EST) Subject: Endpoint Security and Smartphones Message-ID: <916177.6509.1361287212637.JavaMail.root@benjamin.baylink.com> Some time back, the FBI was heard to say in public that draw-your-passpattern security, as seen on Android smartphones and tablets, was too much for them, at least as long as you kept your screen clean of skin oil. :-) Whether or not that's true, there are apparently ways to attack even that, using just the sensors on the platform. Specifically, the accelerometers (which are actually usually just angle sensors): http://www.schneier.com/blog/archives/2013/02/guessing_smart.html If you're responsible for security, BTW (and if you're on NANOG, you probably are), Bruce Schneier should be on your daily bookmark list... even if you think he's full of crap. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From SNaslund at medline.com Tue Feb 19 16:07:17 2013 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 19 Feb 2013 10:07:17 -0600 Subject: Endpoint Security and Smartphones In-Reply-To: <916177.6509.1361287212637.JavaMail.root@benjamin.baylink.com> References: <916177.6509.1361287212637.JavaMail.root@benjamin.baylink.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0E6F94F0@MUNEXBE1.medline.com> Kind of seems to me that if I am deep enough in your mobile device to get your accelerometer data, I probably can get access to your stored data in the device. The only reason I think I would want your passcode would be to physically steal your device and then try to use it. This is one of those attacks that is probably possible but not practical. Interesting blog however. Steven Naslund -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Tuesday, February 19, 2013 9:20 AM To: NANOG Subject: Endpoint Security and Smartphones Some time back, the FBI was heard to say in public that draw-your-passpattern security, as seen on Android smartphones and tablets, was too much for them, at least as long as you kept your screen clean of skin oil. :-) Whether or not that's true, there are apparently ways to attack even that, using just the sensors on the platform. Specifically, the accelerometers (which are actually usually just angle sensors): http://www.schneier.com/blog/archives/2013/02/guessing_smart.html If you're responsible for security, BTW (and if you're on NANOG, you probably are), Bruce Schneier should be on your daily bookmark list... even if you think he's full of crap. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From SNaslund at medline.com Tue Feb 19 16:35:09 2013 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 19 Feb 2013 10:35:09 -0600 Subject: Endpoint Security and Smartphones In-Reply-To: <31889643.6536.1361290909711.JavaMail.root@benjamin.baylink.com> References: <2A76E400AC84B845AAC35AA19F8E7A5D0E6F94F0@MUNEXBE1.medline.com> <31889643.6536.1361290909711.JavaMail.root@benjamin.baylink.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0E6F9543@MUNEXBE1.medline.com> My knowledge on mobile device security is pretty limited. I am just trying to wrap my head around the value of your passcode. I suppose it would be good to know if I could get covert access to the device itself so I could see what is on it. I would however have to get some malicious code on the device to get the passcode so it would seem to be easier to put malicious code on your device that sends me whatever I need the passcode to access in the first place. I guess one of my thoughts on computer security in general is that if someone gets physical access to the device, it is history. I would not count on the passcode to be very protective because it would seem that there would be some kind of way around it through the hardware vendor, maybe not but someone would have to convince me that a backdoor does not exist. Steven Naslund -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Tuesday, February 19, 2013 10:22 AM To: Naslund, Steve Subject: Re: Endpoint Security and Smartphones ----- Original Message ----- > From: "Steve Naslund" > Kind of seems to me that if I am deep enough in your mobile device to > get your accelerometer data, I probably can get access to your stored > data in the device. The only reason I think I would want your passcode > would be to physically steal your device and then try to use it. > > This is one of those attacks that is probably possible but not > practical. Interesting blog however. I dunno, Steve; think "trojan horse". -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From george.herbert at gmail.com Tue Feb 19 16:46:39 2013 From: george.herbert at gmail.com (George Herbert) Date: Tue, 19 Feb 2013 08:46:39 -0800 Subject: Endpoint Security and Smartphones In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0E6F94F0@MUNEXBE1.medline.com> References: <916177.6509.1361287212637.JavaMail.root@benjamin.baylink.com> <2A76E400AC84B845AAC35AA19F8E7A5D0E6F94F0@MUNEXBE1.medline.com> Message-ID: <4A3A3116-03EA-43C6-A854-390BE396835E@gmail.com> Normal apps can usually get the accelerometer data without breaking device security. So you download the newest cool free Mine Birds or whatnot, and its server upload traffic eventually includes guesses at your passcode along with your game status... George William Herbert Sent from my iPhone On Feb 19, 2013, at 8:07 AM, "Naslund, Steve" wrote: > Kind of seems to me that if I am deep enough in your mobile device to get your accelerometer data, I probably can get access to your stored data in the device. The only reason I think I would want your passcode would be to physically steal your device and then try to use it. > > This is one of those attacks that is probably possible but not practical. Interesting blog however. > > Steven Naslund > > > > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: Tuesday, February 19, 2013 9:20 AM > To: NANOG > Subject: Endpoint Security and Smartphones > > Some time back, the FBI was heard to say in public that draw-your-passpattern security, as seen on Android smartphones and tablets, was too much for them, at least as long as you kept your screen clean of skin oil. :-) > > Whether or not that's true, there are apparently ways to attack even that, using just the sensors on the platform. Specifically, the accelerometers (which are actually usually just angle sensors): > > http://www.schneier.com/blog/archives/2013/02/guessing_smart.html > > If you're responsible for security, BTW (and if you're on NANOG, you probably are), Bruce Schneier should be on your daily bookmark list... > even if you think he's full of crap. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > From SNaslund at medline.com Tue Feb 19 17:00:26 2013 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 19 Feb 2013 11:00:26 -0600 Subject: Endpoint Security and Smartphones In-Reply-To: <4A3A3116-03EA-43C6-A854-390BE396835E@gmail.com> References: <916177.6509.1361287212637.JavaMail.root@benjamin.baylink.com> <2A76E400AC84B845AAC35AA19F8E7A5D0E6F94F0@MUNEXBE1.medline.com> <4A3A3116-03EA-43C6-A854-390BE396835E@gmail.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0E79378D@MUNEXBE1.medline.com> I get that part. I guess I am just trying to figure out why having your passcode is such an advantage. I guess if you really want to physically steal (or temporarily "borrow") my phone and get into it, that would be useful. I would be much more concerned about remote exploits because I have always assumed that if you physically have the device, you are going to get into it. All I count on my passcode for is to prevent me from butt dialing. I think the real value here would be if it were used as more of a general purpose key stroke grabber that could tell me remotely what you are doing with your phone. Problem with that is that the accuracy would have to be much better for that purpose. Steven Naslund -----Original Message----- From: George Herbert [mailto:george.herbert at gmail.com] Sent: Tuesday, February 19, 2013 10:47 AM To: Naslund, Steve Cc: NANOG; George Herbert Subject: Re: Endpoint Security and Smartphones Normal apps can usually get the accelerometer data without breaking device security. So you download the newest cool free Mine Birds or whatnot, and its server upload traffic eventually includes guesses at your passcode along with your game status... George William Herbert Sent from my iPhone On Feb 19, 2013, at 8:07 AM, "Naslund, Steve" wrote: > Kind of seems to me that if I am deep enough in your mobile device to get your accelerometer data, I probably can get access to your stored data in the device. The only reason I think I would want your passcode would be to physically steal your device and then try to use it. > > This is one of those attacks that is probably possible but not practical. Interesting blog however. > > Steven Naslund > > > > -----Original Message----- > From: Jay Ashworth [mailto:jra at baylink.com] > Sent: Tuesday, February 19, 2013 9:20 AM > To: NANOG > Subject: Endpoint Security and Smartphones > > Some time back, the FBI was heard to say in public that draw-your-passpattern security, as seen on Android smartphones and tablets, was too much for them, at least as long as you kept your screen clean of skin oil. :-) > > Whether or not that's true, there are apparently ways to attack even that, using just the sensors on the platform. Specifically, the accelerometers (which are actually usually just angle sensors): > > http://www.schneier.com/blog/archives/2013/02/guessing_smart.html > > If you're responsible for security, BTW (and if you're on NANOG, you probably are), Bruce Schneier should be on your daily bookmark list... > even if you think he's full of crap. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > From SNaslund at medline.com Tue Feb 19 17:13:11 2013 From: SNaslund at medline.com (Naslund, Steve) Date: Tue, 19 Feb 2013 11:13:11 -0600 Subject: Endpoint Security and Smartphones In-Reply-To: <2506936.6538.1361292087299.JavaMail.root@benjamin.baylink.com> References: <2A76E400AC84B845AAC35AA19F8E7A5D0E6F9543@MUNEXBE1.medline.com> <2506936.6538.1361292087299.JavaMail.root@benjamin.baylink.com> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0E7937B8@MUNEXBE1.medline.com> Well, I guess it all goes back to my original assumption that unless you control physical access to the device there really is no security. Unless someone can prove to me that the pass code is a part of a cryptographically secure system (which is unlikely given the key length of the passcode) that guards the entire file system of the device, then it is nothing more than a lock to keep kids out and prevent butt dialing. This is no different than losing physical control of your laptop computer or desktop machine. Unless you have implemented some of the most draconian security measures including full file system encryption with a removable key store (like a smartcard or such), loss of the physical device is game over in most cases. I think this attack might have value if aimed at a single individual target with a high value reason for needing access to the phone (think CIA going after a high value target). To write an app that randomly grabs pass codes from the general public is a lot less useful because the pass code does nothing for me without the physical device. I still cannot figure out the practical value of this is other than demonstrate that having all of these sensors on your person is a security threat. Steve -----Original Message----- From: Jay Ashworth [mailto:jra at baylink.com] Sent: Tuesday, February 19, 2013 10:41 AM To: Naslund, Steve Subject: Re: Endpoint Security and Smartphones ----- Original Message ----- > From: "Steve Naslund" > My knowledge on mobile device security is pretty limited. I am just > trying to wrap my head around the value of your passcode. I suppose it > would be good to know if I could get covert access to the device > itself so I could see what is on it. I would however have to get some > malicious code on the device to get the passcode so it would seem to > be easier to put malicious code on your device that sends me whatever > I need the passcode to access in the first place. I guess one of my > thoughts on computer security in general is that if someone gets > physical access to the device, it is history. I would not count on the > passcode to be very protective because it would seem that there would > be some kind of way around it through the hardware vendor, maybe not > but someone would have to convince me that a backdoor does not exist. Well, certainly it's stored on there, but the received wisdom is that it is somewhere where apps not granted superuser by the user can't reach it, so a "normal" trojan couldn't get to it. It is, of course, in the FBI's best interest to lie about whether they can break this sort of security... But in fact, the point of the pass-swipe is that no, physical access is not enough -- as long as you're not the "disassemble the device and put the flash memory on a scanning-tunnelling microscope" class of attacker; there probably really are uses for this attack. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From lstewart at superb.net Tue Feb 19 19:11:05 2013 From: lstewart at superb.net (Landon Stewart) Date: Tue, 19 Feb 2013 11:11:05 -0800 Subject: Anyone know of a good InfiniBand vendor in the US? Message-ID: Hello NANOG, We are thinking of utilizing some InfiniBand stuff for some specific application in our data centres. We are new to InfiniBand however so we want to get some equipment and see if it does what we need. Does anyone know of a good vendor in the US? East or West coast, doesn't matter. If anyone has any good advice or information about InfiniBand that would be nice to hear too as we are totally new to it at present. -- Landon Stewart Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From eesslinger at fpu-tn.com Tue Feb 19 20:30:05 2013 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Tue, 19 Feb 2013 14:30:05 -0600 Subject: bidirectional fiber inline amps. Message-ID: <489EAE655F69A246A2CBF4197BFD251117848059@exchange.corp.fpu-tn.com> Due to some bundle size restrictions, we are looking at converting some runs over to use bi-directional fiber sfp's (the Cisco version is GLC-BX-D/GLC-BX-U). However a couple of our runs are farther than the spec 6.2 miles. Is anyone aware of a vendor that makes an inline bidirectional amp for this sort of application? I did some digging but either they do not exist or my google fu is weak today. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. From jared at puck.nether.net Tue Feb 19 20:42:32 2013 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 19 Feb 2013 15:42:32 -0500 Subject: bidirectional fiber inline amps. In-Reply-To: <489EAE655F69A246A2CBF4197BFD251117848059@exchange.corp.fpu-tn.com> References: <489EAE655F69A246A2CBF4197BFD251117848059@exchange.corp.fpu-tn.com> Message-ID: <7987EFCB-62B8-4823-AD29-E24E4BCF286C@puck.nether.net> On Feb 19, 2013, at 3:30 PM, Eric J Esslinger wrote: > Due to some bundle size restrictions, we are looking at converting some runs over to use bi-directional fiber sfp's (the Cisco version is GLC-BX-D/GLC-BX-U). However a couple of our runs are farther than the spec 6.2 miles. Is anyone aware of a vendor that makes an inline bidirectional amp for this sort of application? I did some digging but either they do not exist or my google fu is weak today. So you really just want the 20km optics: GLC-BX-U20 GLC-BX-D20 Most places also make 40km and 80km optics of the same sort. - Jared From eesslinger at fpu-tn.com Tue Feb 19 21:15:14 2013 From: eesslinger at fpu-tn.com (Eric J Esslinger) Date: Tue, 19 Feb 2013 15:15:14 -0600 Subject: bidirectional fiber inline amps. In-Reply-To: <7987EFCB-62B8-4823-AD29-E24E4BCF286C@puck.nether.net> Message-ID: <489EAE655F69A246A2CBF4197BFD25111784805A@exchange.corp.fpu-tn.com> Didn't see those. Thanks. Idiot moment for me. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 > -----Original Message----- > From: Jared Mauch [mailto:jared at puck.nether.net] > Sent: Tuesday, February 19, 2013 2:43 PM > To: Eric J Esslinger > Cc: 'nanog at nanog.org' > Subject: Re: bidirectional fiber inline amps. > > > > On Feb 19, 2013, at 3:30 PM, Eric J Esslinger wrote: > > > Due to some bundle size restrictions, we are looking at converting > > some runs over to use bi-directional fiber sfp's (the Cisco > version is > > GLC-BX-D/GLC-BX-U). However a couple of our runs are > farther than the > > spec 6.2 miles. Is anyone aware of a vendor that makes an inline > > bidirectional amp for this sort of application? I did some > digging but > > either they do not exist or my google fu is weak today. > > So you really just want the 20km optics: > > GLC-BX-U20 > GLC-BX-D20 > > Most places also make 40km and 80km optics of the same sort. > > - Jared > This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. -------------- next part -------------- A non-text attachment was scrubbed... Name: Eric J Esslinger.vcf Type: text/x-vcard Size: 498 bytes Desc: Eric J Esslinger.vcf URL: From matt.addison at lists.evilgeni.us Tue Feb 19 22:37:42 2013 From: matt.addison at lists.evilgeni.us (Matt Addison) Date: Tue, 19 Feb 2013 17:37:42 -0500 Subject: Anyone know of a good InfiniBand vendor in the US? In-Reply-To: References: Message-ID: <9137230821910144412@unknownmsgid> VAR or Manufacturer? Mellanox are essentially the defacto standard for IB switches and HCAs. Sent from my mobile device, so please excuse any horrible misspellings. On Feb 19, 2013, at 14:12, Landon Stewart wrote: > Hello NANOG, > > We are thinking of utilizing some InfiniBand stuff for some specific > application in our data centres. We are new to InfiniBand however so we > want to get some equipment and see if it does what we need. Does anyone > know of a good vendor in the US? East or West coast, doesn't matter. If > anyone has any good advice or information about InfiniBand that would be > nice to hear too as we are totally new to it at present. > > -- > Landon Stewart > Sr. Administrator > Systems Engineering > Superb Internet Corp - 888-354-6128 x 4199 > Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From mihai at ploiesti.rdsnet.ro Tue Feb 19 12:29:49 2013 From: mihai at ploiesti.rdsnet.ro (Mihai Necsa) Date: Tue, 19 Feb 2013 14:29:49 +0200 Subject: regarding 188.24.168.0/21 Message-ID: <5123703D.1020604@ploiesti.rdsnet.ro> Hi list Any help will be appreciated, it seems that apple is filtering prefixes for untraceable reasons I wrote emails to Apple-NOC at apple.com droot at apple.com but no answer. Staring about 2 weeks ago we encountered several complaints from our customers which are using 188.24.168.0/21. The prefix is allocated to our residential customers, dynamically via pppoe. Actually they are not able to connect AppStore and associated resources like developer.apple.com from their IOS terminal phones or tablets, nor using iTunes or browser from their respective operating systems. Using tcpdump we saw that 17.154.66.17 is not responding to client request. IP 188.27.253.245.63289 > 17.154.66.17.443: tcp 0 Furthermore we did manage to ping hosts from 188.24.168.0/21 using a looking glass server (4.69.185.226) from LEVEL3 San Jose which seems to be last hop provider to apple network. Ping results from San Jose, CA to 188.27.248.26(188-27-248-26.rdsnet.ro) icmp_seq=0 time=188 ms ---- statistics ---- 1 packets transmitted, 1 packets received, 0% packet loss rtt min/avg/median/max/mdev/stddev = 188/188/188/188/0/0 ms Regards, -- Mihai NECSA network engineer @AS8708 From alex at pssclabs.com Tue Feb 19 19:14:00 2013 From: alex at pssclabs.com (Alex Lesser) Date: Tue, 19 Feb 2013 14:14:00 -0500 Subject: Anyone know of a good InfiniBand vendor in the US? In-Reply-To: References: Message-ID: <5123CEF8.2060706@pssclabs.com> Hi Landon: We deliver Infiniband based servers and switches. We have been working with Infiniband for many years already. What are you looking for? Alex www.pssclabs.com On 2/19/2013 2:11 PM, Landon Stewart wrote: > Hello NANOG, > > We are thinking of utilizing some InfiniBand stuff for some specific > application in our data centres. We are new to InfiniBand however so we > want to get some equipment and see if it does what we need. Does anyone > know of a good vendor in the US? East or West coast, doesn't matter. If > anyone has any good advice or information about InfiniBand that would be > nice to hear too as we are totally new to it at present. > From lstewart at superb.net Wed Feb 20 00:46:03 2013 From: lstewart at superb.net (Landon Stewart) Date: Tue, 19 Feb 2013 16:46:03 -0800 Subject: Anyone know of a good InfiniBand vendor in the US? In-Reply-To: <9137230821910144412@unknownmsgid> References: <9137230821910144412@unknownmsgid> Message-ID: Oh by vendor I mean VAR I guess. Mostly I'm also wondering how an IB network handles IPoIB and how one uses IB with a gateway to layer 3 Ethernet switches or edge routers. If anyone has any resources that provide details on how this works and how ethernet VLANs are handled I'd appreciate it. On 19 February 2013 14:37, Matt Addison wrote: > VAR or Manufacturer? Mellanox are essentially the defacto standard for > IB switches and HCAs. > > Sent from my mobile device, so please excuse any horrible misspellings. > > On Feb 19, 2013, at 14:12, Landon Stewart wrote: > > > Hello NANOG, > > > > We are thinking of utilizing some InfiniBand stuff for some specific > > application in our data centres. We are new to InfiniBand however so we > > want to get some equipment and see if it does what we need. Does anyone > > know of a good vendor in the US? East or West coast, doesn't matter. If > > anyone has any good advice or information about InfiniBand that would be > > nice to hear too as we are totally new to it at present. > > > > -- > > Landon Stewart > > Sr. Administrator > > Systems Engineering > > Superb Internet Corp - 888-354-6128 x 4199 > > Web hosting and more "Ahead of the Rest": http://www.superbhosting.net > -- Landon Stewart Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more "Ahead of the Rest": http://www.superbhosting.net From jlewis at lewis.org Wed Feb 20 00:55:39 2013 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 19 Feb 2013 19:55:39 -0500 (EST) Subject: Anyone know of a good InfiniBand vendor in the US? In-Reply-To: References: <9137230821910144412@unknownmsgid> Message-ID: On Tue, 19 Feb 2013, Landon Stewart wrote: > Oh by vendor I mean VAR I guess. Mostly I'm also wondering how an IB > network handles IPoIB and how one uses IB with a gateway to layer 3 > Ethernet switches or edge routers. If anyone has any resources that > provide details on how this works and how ethernet VLANs are handled I'd > appreciate it. My limited IB experience has been that the IB switch acts much like a dumb ethernet switch, caring only about which IB hardware addresses are reachable via which port. Routing between IPoIB and IP over ethernet can be done by any host with interfaces on both networks and IP forwarding enabled. In our setups, we've used IPoIB, but with 1918 addresses and not routed beyond the IB network. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jra at baylink.com Wed Feb 20 01:48:18 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 20 Feb 2013 01:48:18 GMT Subject: Check this out T-Mobile Launches GoSmart Prepaid Service Nationally on Phone Scoop Message-ID: <201302200148.r1K1mIXH028050@web2.phonescoop.com> Check this out: http://www.phonescoop.com/articles/article.php?a=11946 This email was sent via Phone Scoop (www.phonescoop.com). The sender thought you might be interested in the page linked above. From shortdudey123 at gmail.com Wed Feb 20 01:50:46 2013 From: shortdudey123 at gmail.com (Grant Ridder) Date: Tue, 19 Feb 2013 19:50:46 -0600 Subject: Check this out T-Mobile Launches GoSmart Prepaid Service Nationally on Phone Scoop In-Reply-To: <201302200148.r1K1mIXH028050@web2.phonescoop.com> References: <201302200148.r1K1mIXH028050@web2.phonescoop.com> Message-ID: haha i love the header: Received: (from nobody at localhost) On Tue, Feb 19, 2013 at 7:48 PM, Jay Ashworth wrote: > Check this out: > > http://www.phonescoop.com/articles/article.php?a=11946 > > This email was sent via Phone Scoop (www.phonescoop.com). The sender > thought you might be interested in the page linked above. > > From quantumfoam at gmail.com Wed Feb 20 01:58:37 2013 From: quantumfoam at gmail.com (Jonathan Rogers) Date: Tue, 19 Feb 2013 20:58:37 -0500 Subject: Check this out T-Mobile Launches GoSmart Prepaid Service Nationally on Phone Scoop In-Reply-To: References: <201302200148.r1K1mIXH028050@web2.phonescoop.com> Message-ID: An email from nobody? WHAT IS THIS SORCERY?!? --JR On Tue, Feb 19, 2013 at 8:50 PM, Grant Ridder wrote: > haha i love the header: > > Received: (from nobody at localhost) > > On Tue, Feb 19, 2013 at 7:48 PM, Jay Ashworth wrote: > > > Check this out: > > > > http://www.phonescoop.com/articles/article.php?a=11946 > > > > This email was sent via Phone Scoop (www.phonescoop.com). The sender > > thought you might be interested in the page linked above. > > > > > From jra at baylink.com Wed Feb 20 02:16:41 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 20 Feb 2013 02:16:41 GMT Subject: Check this out Review LG Spirit 4G for MetroPCS on Phone Scoop Message-ID: <201302200216.r1K2GfJe028155@web2.phonescoop.com> Check this out: http://www.phonescoop.com/articles/article.php?a=11938 This email was sent via Phone Scoop (www.phonescoop.com). The sender thought you might be interested in the page linked above. From randy_94108 at yahoo.com Wed Feb 20 02:34:08 2013 From: randy_94108 at yahoo.com (Randy) Date: Tue, 19 Feb 2013 18:34:08 -0800 (PST) Subject: Check this out T-Mobile Launches GoSmart Prepaid Service Nationally on Phone Scoop In-Reply-To: Message-ID: <1361327648.54116.YahooMailClassic@web184702.mail.ne1.yahoo.com> Merlin is back; especially for Jay...:-) ./Randy --- On Tue, 2/19/13, Jonathan Rogers wrote: > From: Jonathan Rogers > Subject: Re: Check this out T-Mobile Launches GoSmart Prepaid Service Nationally on Phone Scoop > To: "Grant Ridder" > Cc: "nanog at nanog.org" > Date: Tuesday, February 19, 2013, 5:58 PM > An email from nobody? WHAT IS THIS > SORCERY?!? > > --JR > > > On Tue, Feb 19, 2013 at 8:50 PM, Grant Ridder wrote: > > > haha i love the header: > > > > Received: (from nobody at localhost) > > > > On Tue, Feb 19, 2013 at 7:48 PM, Jay Ashworth > wrote: > > > > > Check this out: > > > > > > http://www.phonescoop.com/articles/article.php?a=11946 > > > > > > This email was sent via Phone Scoop > (www.phonescoop.com). The sender > > > thought you might be interested in the page linked > above. > > > > > > > > > From george.herbert at gmail.com Wed Feb 20 02:35:30 2013 From: george.herbert at gmail.com (George Herbert) Date: Tue, 19 Feb 2013 18:35:30 -0800 Subject: Check this out T-Mobile Launches GoSmart Prepaid Service Nationally on Phone Scoop In-Reply-To: References: <201302200148.r1K1mIXH028050@web2.phonescoop.com> Message-ID: All in favor of phonescoop being blacklisted from nanog? Anyone? Anyone? Buehler? On Tue, Feb 19, 2013 at 5:50 PM, Grant Ridder wrote: > haha i love the header: > > Received: (from nobody at localhost) > > On Tue, Feb 19, 2013 at 7:48 PM, Jay Ashworth wrote: > >> Check this out: >> >> http://www.phonescoop.com/articles/article.php?a=11946 >> >> This email was sent via Phone Scoop (www.phonescoop.com). The sender >> thought you might be interested in the page linked above. >> >> -- -george william herbert george.herbert at gmail.com From jharper at well.com Wed Feb 20 03:15:36 2013 From: jharper at well.com (Jeff Harper) Date: Tue, 19 Feb 2013 19:15:36 -0800 (PST) Subject: TelePacific a good choice? Message-ID: <1132441074.4967.1361330136747.JavaMail.root@zimbra.well.com> Hiya, We're looking at TelePacific as a possible solution for some of our transit needs. If you have an honest experience with them, positive or negative, I'd like to hear from you. Simply email me off line with your experiences, thanks! Jeff Harper, CCIE (W) | www.well.com ip access-list extended jeff permit tcp any any eq intelligence deny tcp any any eq stupid-people From pauldotwall at gmail.com Wed Feb 20 03:37:42 2013 From: pauldotwall at gmail.com (Paul WALL) Date: Tue, 19 Feb 2013 22:37:42 -0500 Subject: TelePacific a good choice? In-Reply-To: <1132441074.4967.1361330136747.JavaMail.root@zimbra.well.com> References: <1132441074.4967.1361330136747.JavaMail.root@zimbra.well.com> Message-ID: The lack of IPv6 implementation: http://bgp.he.net/AS14265#_asinfo should be the only feedback you need. On 2/19/13, Jeff Harper wrote: > Hiya, > > We're looking at TelePacific as a possible solution for some of our transit > needs. If you have an honest experience with them, positive or negative, > I'd like to hear from you. > > Simply email me off line with your experiences, thanks! > > Jeff Harper, CCIE (W) | www.well.com > ip access-list extended jeff > permit tcp any any eq intelligence > deny tcp any any eq stupid-people > > > From eyeronic.design at gmail.com Wed Feb 20 04:10:05 2013 From: eyeronic.design at gmail.com (Mike Hale) Date: Tue, 19 Feb 2013 20:10:05 -0800 Subject: TelePacific a good choice? In-Reply-To: References: <1132441074.4967.1361330136747.JavaMail.root@zimbra.well.com> Message-ID: I've used them at a previous employer, mainly for PRI termination but also for some transit and colo services. They were decent. Didn't have any major complaints. If IPv6 is important for you...per what Paul said, they probably wouldn't be your best choice. If IPv6 doesn't matter to you, they're good enough. On Tue, Feb 19, 2013 at 7:37 PM, Paul WALL wrote: > The lack of IPv6 implementation: > > http://bgp.he.net/AS14265#_asinfo > > should be the only feedback you need. > > On 2/19/13, Jeff Harper wrote: >> Hiya, >> >> We're looking at TelePacific as a possible solution for some of our transit >> needs. If you have an honest experience with them, positive or negative, >> I'd like to hear from you. >> >> Simply email me off line with your experiences, thanks! >> >> Jeff Harper, CCIE (W) | www.well.com >> ip access-list extended jeff >> permit tcp any any eq intelligence >> deny tcp any any eq stupid-people >> >> >> > -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 From ngqbao at gmail.com Wed Feb 20 04:21:09 2013 From: ngqbao at gmail.com (Bao Nguyen) Date: Tue, 19 Feb 2013 20:21:09 -0800 Subject: switch 10G standalone TOR, core to DC In-Reply-To: <511A6395.1060507@foobar.org> References: <5107B226.4020700@interia.pl> <5108F643.80504@interia.pl> <51090B30.6070504@xip.at> <51090F6F.1050601@interia.pl> <5113E0D6.7050108@gmx.com> <511A506F.2050603@interia.pl> <511A6395.1060507@foobar.org> Message-ID: Anyone have worked with the switching vendor Quanta for their 10ge switching as TOR? [1] Their spec looked interesting and they are quiet cheap. [1] http://www.quantaqct.com/en/01_product/02_detail.php?mid=30&sid=114&id=116&qs=63 -bn 0216331C On Tue, Feb 12, 2013 at 7:45 AM, Nick Hilliard wrote: > On 12/02/2013 14:23, Piotr wrote: > > shared 9 MB packet buffer > > pool that is allocated dynamically to ports that are congested > > > > 9MB is a standard size of port buffers.. > > That's pretty standard for a cut-thru ToR switch of this style. Cut-thru > switches generally need a lot less packet buffer space than store-n-forward > switches. Also, ToR boxes tend not to have complex qos requirements. > > Having said that, you need to be careful deploying small-buffer boxes. If > you're not careful, you will end up with bad packet loss. > > Nick > > > > From peter.phaal at gmail.com Wed Feb 20 06:09:24 2013 From: peter.phaal at gmail.com (Peter Phaal) Date: Tue, 19 Feb 2013 22:09:24 -0800 Subject: switch 10G standalone TOR, core to DC In-Reply-To: References: <5107B226.4020700@interia.pl> <5108F643.80504@interia.pl> <51090B30.6070504@xip.at> <51090F6F.1050601@interia.pl> <5113E0D6.7050108@gmx.com> <511A506F.2050603@interia.pl> <511A6395.1060507@foobar.org> Message-ID: On Tue, Feb 19, 2013 at 8:21 PM, Bao Nguyen wrote: > Anyone have worked with the switching vendor Quanta for their 10ge switching as > TOR? [1] Their spec looked interesting and they are quiet cheap. > > > [1] > http://www.quantaqct.com/en/01_product/02_detail.php?mid=30&sid=114&id=116&qs=63 > > > -bn > 0216331C > Based on the specs, the Quanta switches look like they use Broadcom merchant silicon and should have similar performance to other switches based on the same chipset: http://blog.sflow.com/2011/12/merchant-silicon.html While many vendors use merchant silicon, there is variability in firmware, exposed features, CLI etc. From kyle.creyts at gmail.com Wed Feb 20 06:10:37 2013 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Tue, 19 Feb 2013 22:10:37 -0800 Subject: NYT covers China cyberthreat In-Reply-To: <94bf868f-e631-49ca-b5c8-b1ed0f9333f2@email.android.com> References: <94bf868f-e631-49ca-b5c8-b1ed0f9333f2@email.android.com> Message-ID: quite a bit of coverage lately from the media. http://online.wsj.com/article/SB10001424127887323764804578313101135258708.html http://www.bbc.co.uk/news/world-asia-pacific-21505803 http://www.npr.org/2013/02/19/172373133/report-links-cyber-attacks-on-u-s-to-chinas-military http://www.businessweek.com/articles/2013-02-14/a-chinese-hackers-identity-unmasked On Mon, Feb 18, 2013 at 7:23 PM, Jay Ashworth wrote: > > http://www.nytimes.com/2013/02/19/technology/chinas-army-is-seen-as-tied-to-hacking-against-us.html?pagewanted=all > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From randy at psg.com Wed Feb 20 06:39:42 2013 From: randy at psg.com (Randy Bush) Date: Wed, 20 Feb 2013 15:39:42 +0900 Subject: NYT covers China cyberthreat In-Reply-To: References: <94bf868f-e631-49ca-b5c8-b1ed0f9333f2@email.android.com> Message-ID: boys and girls, all the cyber-capable countries are cyber-culpable. you can bet that they are all snooping and attacking eachother, the united states no less than the rest. news at eleven. randy From zaid at zaidali.com Wed Feb 20 06:43:02 2013 From: zaid at zaidali.com (Zaid Ali Kahn) Date: Tue, 19 Feb 2013 22:43:02 -0800 Subject: NYT covers China cyberthreat In-Reply-To: References: <94bf868f-e631-49ca-b5c8-b1ed0f9333f2@email.android.com> Message-ID: <368EBC27-77B2-447A-A1F6-49CA9729C6B1@zaidali.com> We have done our part to China as well along with other countries in state sponsored "hacking". This is more of news amusement rather than news worthy. Question here should be how much of this is another effort to get a "kill switch" type bill back. Zaid On Feb 19, 2013, at 10:10 PM, Kyle Creyts wrote: > quite a bit of coverage lately from the media. > > http://online.wsj.com/article/SB10001424127887323764804578313101135258708.html > http://www.bbc.co.uk/news/world-asia-pacific-21505803 > http://www.npr.org/2013/02/19/172373133/report-links-cyber-attacks-on-u-s-to-chinas-military > http://www.businessweek.com/articles/2013-02-14/a-chinese-hackers-identity-unmasked > > On Mon, Feb 18, 2013 at 7:23 PM, Jay Ashworth wrote: >> >> http://www.nytimes.com/2013/02/19/technology/chinas-army-is-seen-as-tied-to-hacking-against-us.html?pagewanted=all >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > > > > -- > Kyle Creyts > > Information Assurance Professional > BSidesDetroit Organizer > From wbailey at satelliteintelligencegroup.com Wed Feb 20 07:04:48 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 20 Feb 2013 07:04:48 +0000 Subject: NYT covers China cyberthreat In-Reply-To: <368EBC27-77B2-447A-A1F6-49CA9729C6B1@zaidali.com> References: <94bf868f-e631-49ca-b5c8-b1ed0f9333f2@email.android.com> , <368EBC27-77B2-447A-A1F6-49CA9729C6B1@zaidali.com> Message-ID: An Internet kill switch is a nightmare. We can't even figure out how to run a relay radio system for national emergencies.. Now we are going to assume the people who were owned can somehow shut off communications? We as Americans have plenty of things we have done halfass.. I hope an Internet kill switch doesn't end up being one of them. Build your own private networks, you can't get rooted if someone can't knock. Simple as that. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Zaid Ali Kahn Date: 02/19/2013 10:44 PM (GMT-08:00) To: Kyle Creyts Cc: nanog at nanog.org Subject: Re: NYT covers China cyberthreat We have done our part to China as well along with other countries in state sponsored "hacking". This is more of news amusement rather than news worthy. Question here should be how much of this is another effort to get a "kill switch" type bill back. Zaid On Feb 19, 2013, at 10:10 PM, Kyle Creyts wrote: > quite a bit of coverage lately from the media. > > http://online.wsj.com/article/SB10001424127887323764804578313101135258708.html > http://www.bbc.co.uk/news/world-asia-pacific-21505803 > http://www.npr.org/2013/02/19/172373133/report-links-cyber-attacks-on-u-s-to-chinas-military > http://www.businessweek.com/articles/2013-02-14/a-chinese-hackers-identity-unmasked > > On Mon, Feb 18, 2013 at 7:23 PM, Jay Ashworth wrote: >> >> http://www.nytimes.com/2013/02/19/technology/chinas-army-is-seen-as-tied-to-hacking-against-us.html?pagewanted=all >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > > > > -- > Kyle Creyts > > Information Assurance Professional > BSidesDetroit Organizer > From sneddon at gmail.com Wed Feb 20 07:06:12 2013 From: sneddon at gmail.com (Dan Sneddon) Date: Tue, 19 Feb 2013 23:06:12 -0800 Subject: switch 10G standalone TOR, core to DC In-Reply-To: References: <5107B226.4020700@interia.pl> <5108F643.80504@interia.pl> <51090B30.6070504@xip.at> <51090F6F.1050601@interia.pl> <5113E0D6.7050108@gmx.com> <511A506F.2050603@interia.pl> <511A6395.1060507@foobar.org> Message-ID: <93F9E49DA6D1418CB1908A84319D533C@gmail.com> I have fairly extensive experience with the Quanta LY2 10GE switches, and they work very well for some environments. Here are some basic impressions: - Broadcom Trident chipset - Similar performance to other Trident switches (ideally line rate, but small buffers) - Cisco-like configuration interface (similar, not the same) - Custom Linux kernel and OS - Basic look-and-feel, but so far the quality has not been a disappointment - Decent support for topologies with no Spanning-Tree - Good compatibility with SFP+ transceivers, direct connections, and optics from various sources. - Basic feature set (OSPF/RIP, but no BGP) - Somewhat limited troubleshooting and debug tools One very pleasant aspect of working with Quanta is that they are very responsive to feature requests, often working closely with customers. On the other hand, their release schedules are somewhat non-specific. I've been waiting for full MLAG support for a while (it's supposedly right around the corner). They are particularly convenient if you are putting them at the top of racks full of Quanta servers, since they have logistics and full-rack staging/shipping. I wish they had better MIB support, BGP, scriptability, and policy-based routing, but they don't. They are cheap enough, however, that you may be able to get two LY2 switches for the price of one of some of their competitors. -- Dan Sneddon On Tuesday, February 19, 2013 at 8:21 PM, Bao Nguyen wrote: > Anyone have worked with the switching vendor Quanta for their 10ge switching as > TOR? [1] Their spec looked interesting and they are quiet cheap. > > > [1] > http://www.quantaqct.com/en/01_product/02_detail.php?mid=30&sid=114&id=116&qs=63 > > > -bn > 0216331C > From surfer at mauigateway.com Wed Feb 20 08:02:35 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 20 Feb 2013 00:02:35 -0800 Subject: NYT covers China cyberthreat Message-ID: <20130220000235.87B48FE5@m0005297.ppops.net> Be sure to read the source: intelreport.mandiant.com/Mandiant_APT1_Report.pdf I'm only part way through, but I find it hard to believe that only micro$loth computers are used as the attack OS. Maybe I haven't gotten far enough through report to find the part where they use the *nix boxes? scott From surfer at mauigateway.com Wed Feb 20 08:21:43 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 20 Feb 2013 00:21:43 -0800 Subject: NYT covers China cyberthreat Message-ID: <20130220002143.87B48F61@m0005297.ppops.net> --- calin.chiorean at secdisk.net wrote: From: "calin.chiorean" :: when all tools are available for windows os, you just have to compile them. ------------------------------------------------- They're not all available for m$. scott ---- On Wed, 20 Feb 2013 09:02:35 +0100 Scott Weeks wrote ---- >Be sure to read the source: > >intelreport.mandiant.com/Mandiant_APT1_Report.pdf > >I'm only part way through, but I find it hard to believe that >only micro$loth computers are used as the attack OS. Maybe I >haven't gotten far enough through report to find the part >where they use the *nix boxes? From wbailey at satelliteintelligencegroup.com Wed Feb 20 08:24:10 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 20 Feb 2013 08:24:10 +0000 Subject: NYT covers China cyberthreat In-Reply-To: <20130220002143.87B48F61@m0005297.ppops.net> References: <20130220002143.87B48F61@m0005297.ppops.net> Message-ID: They are when you have a college full of programmers. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Scott Weeks Date: 02/20/2013 12:23 AM (GMT-08:00) To: nanog at nanog.org Subject: Re: NYT covers China cyberthreat --- calin.chiorean at secdisk.net wrote: From: "calin.chiorean" :: when all tools are available for windows os, you just have to compile them. ------------------------------------------------- They're not all available for m$. scott ---- On Wed, 20 Feb 2013 09:02:35 +0100 Scott Weeks wrote ---- >Be sure to read the source: > >intelreport.mandiant.com/Mandiant_APT1_Report.pdf > >I'm only part way through, but I find it hard to believe that >only micro$loth computers are used as the attack OS. Maybe I >haven't gotten far enough through report to find the part >where they use the *nix boxes? From surfer at mauigateway.com Wed Feb 20 08:36:47 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 20 Feb 2013 00:36:47 -0800 Subject: NYT covers China cyberthreat Message-ID: <20130220003647.87B48F3C@m0005297.ppops.net> >I'm only part way through, but I find it hard to believe that >only micro$loth computers are used as the attack OS. Maybe I --- calin.chiorean at secdisk.net wrote: From: "calin.chiorean" :: when all tools are available for windows os, you just have to compile them. ------------------------------------------------- From: Scott Weeks ::: They're not all available for m$. --- wbailey at satelliteintelligencegroup.com wrote: From: Warren Bailey They are when you have a college full of programmers. -------------------------------------------------- Please elaborate. I didn't follow that. scott From wbailey at satelliteintelligencegroup.com Wed Feb 20 08:39:24 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 20 Feb 2013 08:39:24 +0000 Subject: NYT covers China cyberthreat In-Reply-To: <1766323899.249246.1361349370142.JavaMail.sas1@[172.29.251.236]> References: <20130220002143.87B48F61@m0005297.ppops.net> , <1766323899.249246.1361349370142.JavaMail.sas1@[172.29.251.236]> Message-ID: <90a5uej6g87xabqy1a7v354q.1361349560902@email.android.com> They don't have 20 brains, they have a country full. I was in Beijing last year, it was eye opening to the see the state of affairs there. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: "calin.chiorean" Date: 02/20/2013 12:36 AM (GMT-08:00) To: Warren Bailey Cc: surfer at mauigateway.com,nanog at nanog.org Subject: Re: NYT covers China cyberthreat IMO, if we stick to the document and they are organized in military style, then a person who collect information, should focus only on that particular phase. That person is an operator, he or she should not be keep busy remembering long CLI commands. The scope is to deliver ASAP. No matter how much I like CLI and to put my fingers into text mode, I have to admit that point and click in windows is an easier and faster method to achieve the task I did mention. As Warren mention, if you have 20 "brains" it's easy to put those people port a tool from *nix to other platform and have the other 500 operators run it in windows. It's just a matter of good sense and "business" effectiveness :) Maybe I misinterpret information, but this is how I see things. Cheers, Calin ---- On Wed, 20 Feb 2013 09:24:10 +0100 Warren Bailey wrote ---- > They are when you have a college full of programmers. > > > From my Android phone on T-Mobile. The first nationwide 4G network. > > > > -------- Original message -------- > From: Scott Weeks > Date: 02/20/2013 12:23 AM (GMT-08:00) > To: nanog at nanog.org > Subject: Re: NYT covers China cyberthreat > > > > --- calin.chiorean at secdisk.net wrote: > From: "calin.chiorean" > > > :: when all tools are available for windows os, you just have to compile them. > > ------------------------------------------------- > > > They're not all available for m$. > > scott > > > > > > > ---- On Wed, 20 Feb 2013 09:02:35 +0100 Scott Weeks wrote ---- > >Be sure to read the source: > > > >intelreport.mandiant.com/Mandiant_APT1_Report.pdf > > > >I'm only part way through, but I find it hard to believe that > >only micro$loth computers are used as the attack OS. Maybe I > >haven't gotten far enough through report to find the part > >where they use the *nix boxes? > > > > From ops.lists at gmail.com Wed Feb 20 08:45:09 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 20 Feb 2013 14:15:09 +0530 Subject: NYT covers China cyberthreat In-Reply-To: <20130220003647.87B48F3C@m0005297.ppops.net> References: <20130220003647.87B48F3C@m0005297.ppops.net> Message-ID: Part of the entire 'chinese l337 hxx0r spy' 1st complex is apparently the local equivalent of a community college, where the passing out assignment is probably something on the lines of 'get me a dump of the dalai lama's email'. --srs (htc one x) On 20-Feb-2013 2:08 PM, "Scott Weeks" wrote: > > > >I'm only part way through, but I find it hard to believe that > >only micro$loth computers are used as the attack OS. Maybe I > > > --- calin.chiorean at secdisk.net wrote: > From: "calin.chiorean" > > > :: when all tools are available for windows os, you just have to compile > them. > > ------------------------------------------------- > > > From: Scott Weeks > > ::: They're not all available for m$. > > > > --- wbailey at satelliteintelligencegroup.com wrote: > From: Warren Bailey > > They are when you have a college full of programmers. > -------------------------------------------------- > > > > Please elaborate. I didn't follow that. > > > scott > > > From surfer at mauigateway.com Wed Feb 20 08:45:44 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 20 Feb 2013 00:45:44 -0800 Subject: NYT covers China cyberthreat Message-ID: <20130220004544.87B490EF@m0005297.ppops.net> --- calin.chiorean at secdisk.net wrote: From: "calin.chiorean" IMO, if we stick to the document and they are organized in military style, then a person who collect information, should focus only on that particular phase. That person is an operator, he or she should not be keep busy remembering long CLI commands. The scope is to deliver ASAP. ----------------------------------------- What's that randy says? >;-) I can only hope you're right, but my point was to bring suspicion to the report itself for (possibly; I'm only on page 19) saying that m$ is the only attacking OS. -------------------------------------- No matter how much I like CLI and to put my fingers into text mode, I have to admit that point and click in windows is an easier and faster method to achieve the task I did mention. As Warren mention, --------------------------------------- bzzzzzt. Wrong answer. Please study more. Next! scott From surfer at mauigateway.com Wed Feb 20 08:48:34 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 20 Feb 2013 00:48:34 -0800 Subject: NYT covers China cyberthreat Message-ID: <20130220004834.87B490FF@m0005297.ppops.net> --- calin.chiorean at secdisk.net wrote: From: "calin.chiorean" It was just an example :-) to point out the scale of developers vs operators. -------------------------------------------- You'd be surprised at how much better brains are than brawn on these things... ;-) scott From randy at psg.com Wed Feb 20 08:52:14 2013 From: randy at psg.com (Randy Bush) Date: Wed, 20 Feb 2013 17:52:14 +0900 Subject: NYT covers China cyberthreat In-Reply-To: References: <20130220003647.87B48F3C@m0005297.ppops.net> Message-ID: > Part of the entire 'chinese l337 hxx0r spy' 1st complex is apparently > the local equivalent of a community college, where the passing out > assignment is probably something on the lines of 'get me a dump of the > dalai lama's email'. american education is behind in many things. this is but one. randy From wbailey at satelliteintelligencegroup.com Wed Feb 20 08:55:45 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 20 Feb 2013 08:55:45 +0000 Subject: NYT covers China cyberthreat In-Reply-To: <20130220004834.87B490FF@m0005297.ppops.net> References: <20130220004834.87B490FF@m0005297.ppops.net> Message-ID: Have you been to The Great Wall? That statement does not apply in the PRC. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Scott Weeks Date: 02/20/2013 12:54 AM (GMT-08:00) To: nanog at nanog.org Subject: Re: NYT covers China cyberthreat --- calin.chiorean at secdisk.net wrote: From: "calin.chiorean" It was just an example :-) to point out the scale of developers vs operators. -------------------------------------------- You'd be surprised at how much better brains are than brawn on these things... ;-) scott From surfer at mauigateway.com Wed Feb 20 09:08:57 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 20 Feb 2013 01:08:57 -0800 Subject: NYT covers China cyberthreat Message-ID: <20130220010857.87B4907C@m0005297.ppops.net> --- calin.chiorean at secdisk.net wrote: From: "calin.chiorean" It was just an example :-) to point out the scale of developers vs operators. -------------------------------------------- :: You'd be surprised at how much better brains are than brawn :: on these things... ;-) --- wbailey at satelliteintelligencegroup.com wrote: Have you been to The Great Wall? That statement does not apply in the PRC. ---------------------------------------------------- It would be interesting, I suppose, to see what can massively parallel better. brains or brawn :) That's what I'm saying. If this is done by m$ toolage only, as the report seems to say, on page 4, for example: "817 of the 832 (98%) IP addresses logging into APT1 controlled systems using Remote Desktop resolved back to China." Then they have missed the more interesting part of the puzzle, I believe. scott ps. If you gottem both, well that's a whole other thingie. From thegameiam at yahoo.com Wed Feb 20 11:55:18 2013 From: thegameiam at yahoo.com (David Barak) Date: Wed, 20 Feb 2013 06:55:18 -0500 Subject: NYT covers China cyberthreat In-Reply-To: References: <94bf868f-e631-49ca-b5c8-b1ed0f9333f2@email.android.com> <368EBC27-77B2-447A-A1F6-49CA9729C6B1@zaidali.com> Message-ID: Don't be lulled into complacency by a private network: all it takes is one thumb-drive or rogue AP and you have a back door. Private networks reduce but do not eliminate attackable surface. David Barak Sent from a mobile device, please forgive autocorrection. On Feb 20, 2013, at 2:04 AM, Warren Bailey wrote: > An Internet kill switch is a nightmare. We can't even figure out how to run a relay radio system for national emergencies.. Now we are going to assume the people who were owned can somehow shut off communications? > > We as Americans have plenty of things we have done halfass.. I hope an Internet kill switch doesn't end up being one of them. Build your own private networks, you can't get rooted if someone can't knock. Simple as that. > > > From my Android phone on T-Mobile. The first nationwide 4G network. > > > > -------- Original message -------- > From: Zaid Ali Kahn > Date: 02/19/2013 10:44 PM (GMT-08:00) > To: Kyle Creyts > Cc: nanog at nanog.org > Subject: Re: NYT covers China cyberthreat > > > We have done our part to China as well along with other countries in state sponsored "hacking". This is more of news amusement rather than news worthy. Question here should be how much of this is another effort to get a "kill switch" type bill back. > > Zaid > > On Feb 19, 2013, at 10:10 PM, Kyle Creyts wrote: > >> quite a bit of coverage lately from the media. >> >> http://online.wsj.com/article/SB10001424127887323764804578313101135258708.html >> http://www.bbc.co.uk/news/world-asia-pacific-21505803 >> http://www.npr.org/2013/02/19/172373133/report-links-cyber-attacks-on-u-s-to-chinas-military >> http://www.businessweek.com/articles/2013-02-14/a-chinese-hackers-identity-unmasked >> >> On Mon, Feb 18, 2013 at 7:23 PM, Jay Ashworth wrote: >>> >>> http://www.nytimes.com/2013/02/19/technology/chinas-army-is-seen-as-tied-to-hacking-against-us.html?pagewanted=all >>> -- >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> >> >> >> >> -- >> Kyle Creyts >> >> Information Assurance Professional >> BSidesDetroit Organizer >> > > > From rs at seastrom.com Wed Feb 20 12:59:53 2013 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 20 Feb 2013 07:59:53 -0500 Subject: Check this out T-Mobile Launches GoSmart Prepaid Service Nationally on Phone Scoop In-Reply-To: (George Herbert's message of "Tue, 19 Feb 2013 18:35:30 -0800") References: <201302200148.r1K1mIXH028050@web2.phonescoop.com> Message-ID: <867gm3p2d2.fsf@seastrom.com> If only there were some kind of method for Jay to publish which addresses are actually authorized to send mail on behalf of baylink.com (which could then be leveraged by sc1.nanog.org to turn the recommended soft fail into a hard fail and stop this kind of silliness cold)... Billet:~ rs$ dig +short baylink.com. txt Billet:~ rs$ dig +short baylink.com. spf Billet:~ rs$ -r George Herbert writes: > All in favor of phonescoop being blacklisted from nanog? Anyone? > Anyone? Buehler? > > > > On Tue, Feb 19, 2013 at 5:50 PM, Grant Ridder wrote: >> haha i love the header: >> >> Received: (from nobody at localhost) >> >> On Tue, Feb 19, 2013 at 7:48 PM, Jay Ashworth wrote: >> >>> Check this out: >>> >>> http://www.phonescoop.com/articles/article.php?a=11946 >>> >>> This email was sent via Phone Scoop (www.phonescoop.com). The sender >>> thought you might be interested in the page linked above. >>> >>> > > > > -- > -george william herbert > george.herbert at gmail.com From mihai at ploiesti.rdsnet.ro Wed Feb 20 07:28:04 2013 From: mihai at ploiesti.rdsnet.ro (Mihai Necsa) Date: Wed, 20 Feb 2013 09:28:04 +0200 Subject: bidirectional fiber inline amps. In-Reply-To: <489EAE655F69A246A2CBF4197BFD25111784805A@exchange.corp.fpu-tn.com> References: <489EAE655F69A246A2CBF4197BFD25111784805A@exchange.corp.fpu-tn.com> Message-ID: <51247B04.7080507@ploiesti.rdsnet.ro> specifications in lenght are for kids, adults use budgets :-) bx-d bx-u form cisco have a budget of 16dBmW (max), power form -3 to -9dBm and sensivity to -19dB. So if the fiber is under -10dB (this means roughly 10/0.25dB per km SM att) you might see the light at 40km, I have a stable link for 37km whith stock bx-d bx-u On 02/19/2013 11:15 PM, Eric J Esslinger wrote: > Didn't see those. Thanks. Idiot moment for me. > > __________________________ > Eric Esslinger > Information Services Manager - Fayetteville Public Utilities > http://www.fpu-tn.com/ > (931)433-1522 ext 165 > > > >> -----Original Message----- >> From: Jared Mauch [mailto:jared at puck.nether.net] >> Sent: Tuesday, February 19, 2013 2:43 PM >> To: Eric J Esslinger >> Cc: 'nanog at nanog.org' >> Subject: Re: bidirectional fiber inline amps. >> >> >> >> On Feb 19, 2013, at 3:30 PM, Eric J Esslinger wrote: >> >>> Due to some bundle size restrictions, we are looking at converting >>> some runs over to use bi-directional fiber sfp's (the Cisco >> version is >>> GLC-BX-D/GLC-BX-U). However a couple of our runs are >> farther than the >>> spec 6.2 miles. Is anyone aware of a vendor that makes an inline >>> bidirectional amp for this sort of application? I did some >> digging but >>> either they do not exist or my google fu is weak today. >> >> So you really just want the 20km optics: >> >> GLC-BX-U20 >> GLC-BX-D20 >> >> Most places also make 40km and 80km optics of the same sort. >> >> - Jared >> > > This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited. > > -- Mihai NECSA rcs&rds Ploiesti From calin.chiorean at secdisk.net Wed Feb 20 08:10:55 2013 From: calin.chiorean at secdisk.net (calin.chiorean) Date: Wed, 20 Feb 2013 09:10:55 +0100 Subject: NYT covers China cyberthreat In-Reply-To: <20130220000235.87B48FE5@m0005297.ppops.net> References: <20130220000235.87B48FE5@m0005297.ppops.net> Message-ID: <1587878806.245116.1361347855913.JavaMail.sas1@[172.29.251.236]> If I didn't miss any part of the report, no *nix is mentioned. I'm a *nix fan, but why they (when I say they, I mean an attacker, not necessary the one in this document) should complicate their life, when all tools are available for windows os, you just have to compile them. Cheers, Calin ---- On Wed, 20 Feb 2013 09:02:35 +0100 Scott Weeks wrote ---- > > > >Be sure to read the source: > >intelreport.mandiant.com/Mandiant_APT1_Report.pdf > >I'm only part way through, but I find it hard to believe that >only micro$loth computers are used as the attack OS. Maybe I >haven't gotten far enough through report to find the part >where they use the *nix boxes? > >scott > > From calin.chiorean at secdisk.net Wed Feb 20 08:36:10 2013 From: calin.chiorean at secdisk.net (calin.chiorean) Date: Wed, 20 Feb 2013 09:36:10 +0100 Subject: NYT covers China cyberthreat In-Reply-To: References: <20130220002143.87B48F61@m0005297.ppops.net> Message-ID: <1766323899.249246.1361349370142.JavaMail.sas1@[172.29.251.236]> IMO, if we stick to the document and they are organized in military style, then a person who collect information, should focus only on that particular phase. That person is an operator, he or she should not be keep busy remembering long CLI commands. The scope is to deliver ASAP. No matter how much I like CLI and to put my fingers into text mode, I have to admit that point and click in windows is an easier and faster method to achieve the task I did mention. As Warren mention, if you have 20 "brains" it's easy to put those people port a tool from *nix to other platform and have the other 500 operators run it in windows. It's just a matter of good sense and "business" effectiveness :) Maybe I misinterpret information, but this is how I see things. Cheers, Calin ---- On Wed, 20 Feb 2013 09:24:10 +0100 Warren Bailey wrote ---- > They are when you have a college full of programmers. > > > From my Android phone on T-Mobile. The first nationwide 4G network. > > > > -------- Original message -------- > From: Scott Weeks > Date: 02/20/2013 12:23 AM (GMT-08:00) > To: nanog at nanog.org > Subject: Re: NYT covers China cyberthreat > > > > --- calin.chiorean at secdisk.net wrote: > From: "calin.chiorean" > > > :: when all tools are available for windows os, you just have to compile them. > > ------------------------------------------------- > > > They're not all available for m$. > > scott > > > > > > > ---- On Wed, 20 Feb 2013 09:02:35 +0100 Scott Weeks wrote ---- > >Be sure to read the source: > > > >intelreport.mandiant.com/Mandiant_APT1_Report.pdf > > > >I'm only part way through, but I find it hard to believe that > >only micro$loth computers are used as the attack OS. Maybe I > >haven't gotten far enough through report to find the part > >where they use the *nix boxes? > > > > From calin.chiorean at secdisk.net Wed Feb 20 08:43:46 2013 From: calin.chiorean at secdisk.net (calin.chiorean) Date: Wed, 20 Feb 2013 09:43:46 +0100 Subject: NYT covers China cyberthreat In-Reply-To: <90a5uej6g87xabqy1a7v354q.1361349560902@email.android.com> References: <20130220002143.87B48F61@m0005297.ppops.net> , <1766323899.249246.1361349370142.JavaMail.sas1@[172.29.251.236]> <90a5uej6g87xabqy1a7v354q.1361349560902@email.android.com> Message-ID: <1370133330.250696.1361349826312.JavaMail.sas1@[172.29.251.236]> ::: They don't have 20 brains, they have a country full It was just an example :-) to point out the scale of developers vs operators. Calin ---- On Wed, 20 Feb 2013 09:39:24 +0100 Warren Bailey wrote ---- > They don't have 20 brains, they have a country full. I was in Beijing last year, it was eye opening to the see the state of affairs there. > > > > > From my Android phone on T-Mobile. The first nationwide 4G network. > > > > > -------- Original message -------- > From: "calin.chiorean" > Date: 02/20/2013 12:36 AM (GMT-08:00) > To: Warren Bailey > Cc: surfer at mauigateway.com,nanog at nanog.org > Subject: Re: NYT covers China cyberthreat > > > > IMO, if we stick to the document and they are organized in military style, then a person who collect information, should focus only on that particular phase. That person is an operator, he or she should not be keep busy remembering long CLI commands. The scope is to deliver ASAP. > > No matter how much I like CLI and to put my fingers into text mode, I have to admit that point and click in windows is an easier and faster method to achieve the task I did mention. As Warren mention, if you have 20 "brains" it's easy to put those people port a tool from *nix to other platform and have the other 500 operators run it in windows. It's just a matter of good sense and "business" effectiveness :) > > Maybe I misinterpret information, but this is how I see things. > > Cheers, > Calin > > > ---- On Wed, 20 Feb 2013 09:24:10 +0100 Warren Bailey wrote ---- > > > They are when you have a college full of programmers. > > > > > > From my Android phone on T-Mobile. The first nationwide 4G network. > > > > > > > > -------- Original message -------- > > From: Scott Weeks > > Date: 02/20/2013 12:23 AM (GMT-08:00) > > To: nanog at nanog.org > > Subject: Re: NYT covers China cyberthreat > > > > > > > > --- calin.chiorean at secdisk.net wrote: > > From: "calin.chiorean" > > > > > > :: when all tools are available for windows os, you just have to compile them. > > > > ------------------------------------------------- > > > > > > They're not all available for m$. > > > > scott > > > > > > > > > > > > > > ---- On Wed, 20 Feb 2013 09:02:35 +0100 Scott Weeks wrote ---- > > >Be sure to read the source: > > > > > >intelreport.mandiant.com/Mandiant_APT1_Report.pdf > > > > > >I'm only part way through, but I find it hard to believe that > > >only micro$loth computers are used as the attack OS. Maybe I > > >haven't gotten far enough through report to find the part > > >where they use the *nix boxes? > > > > > > > > > > > > > From rsk at gsp.org Wed Feb 20 15:22:12 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 20 Feb 2013 10:22:12 -0500 Subject: Check this out T-Mobile Launches GoSmart Prepaid Service Nationally on Phone Scoop In-Reply-To: <867gm3p2d2.fsf@seastrom.com> References: <201302200148.r1K1mIXH028050@web2.phonescoop.com> <867gm3p2d2.fsf@seastrom.com> Message-ID: <20130220152212.GA11455@gsp.org> On Wed, Feb 20, 2013 at 07:59:53AM -0500, Robert E. Seastrom wrote: > If only there were some kind of method for Jay to publish which > addresses are actually authorized to send mail on behalf of [snip] SPF is snake-oil. Here's something that works (salt to taste for the MTA of your choice): Connect:phonescoop.com ERROR:5.7.1:"550 Mail refused, known forgery source" From:phonescoop.com ERROR:5.7.1:"550 Mail refused, known forgery source" ---rsk From froztbyte at froztbyte.net Wed Feb 20 15:48:17 2013 From: froztbyte at froztbyte.net (JP Viljoen) Date: Wed, 20 Feb 2013 17:48:17 +0200 Subject: Check this out T-Mobile Launches GoSmart Prepaid Service Nationally on Phone Scoop In-Reply-To: <20130220152212.GA11455@gsp.org> References: <201302200148.r1K1mIXH028050@web2.phonescoop.com> <867gm3p2d2.fsf@seastrom.com> <20130220152212.GA11455@gsp.org> Message-ID: <793DCF87-1BA2-4EED-819E-4E4C09A55D2A@froztbyte.net> On 20 Feb 2013, at 5:22 PM, Rich Kulawiec wrote: > On Wed, Feb 20, 2013 at 07:59:53AM -0500, Robert E. Seastrom wrote: >> If only there were some kind of method for Jay to publish which >> addresses are actually authorized to send mail on behalf of [snip] > > SPF is snake-oil. Here's something that works (salt to taste for > the MTA of your choice): > > Connect:phonescoop.com ERROR:5.7.1:"550 Mail refused, known forgery source" > From:phonescoop.com ERROR:5.7.1:"550 Mail refused, known forgery source" Because putting things into a file on your server, instead of some distributed mechanism we could refer to, makes that much more sense. Did you guys see this /etc/hosts thing? It's awesome! I DON'T EVEN HAVE TO RUN A DNS SERVER!! *flamesuit* -J From oscar.vives at gmail.com Wed Feb 20 16:40:49 2013 From: oscar.vives at gmail.com ( .) Date: Wed, 20 Feb 2013 17:40:49 +0100 Subject: NYT covers China cyberthreat In-Reply-To: <94bf868f-e631-49ca-b5c8-b1ed0f9333f2@email.android.com> References: <94bf868f-e631-49ca-b5c8-b1ed0f9333f2@email.android.com> Message-ID: This is a improvement over some russian spies, that have the passwords written down in a piece of paper. http://www.networkworld.com/news/2010/063010-russian-spy-ring.html?hpg1=bn <> Windows XP crapines, slowing down russian spies :D My password at home is "don't be the low hanging fruit". Every time that I read on the news that USA is funding this or that cracking group I get a bit angry. Thats a world where is best to not put money. More like direct Interpol to stop mafias profiting from it, to remove money from it. The least thing we want is a "cyber arms race". But if you don't want one, don't start one. -- -- ?in del ?ensaje. From jra at baylink.com Wed Feb 20 17:13:25 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 20 Feb 2013 12:13:25 -0500 (EST) Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: Message-ID: <21410540.6654.1361380405540.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Warren Bailey" > We as Americans have plenty of things we have done halfass.. I hope an > Internet kill switch doesn't end up being one of them. Build your own > private networks, you can't get rooted if someone can't knock. Simple > as that. Well, Warren, I once had a discussion with someone about whether dedicated DS-1 to tie your SCADA network together were "secure enough" and they asked me: "Does it run through a DACS? Where can you program the DACS from?" Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Wed Feb 20 17:15:21 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 20 Feb 2013 12:15:21 -0500 (EST) Subject: NYT covers China cyberthreat In-Reply-To: Message-ID: <15838105.6656.1361380521041.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Randy Bush" > > Part of the entire 'chinese l337 hxx0r spy' 1st complex is > > apparently > > the local equivalent of a community college, where the passing out > > assignment is probably something on the lines of 'get me a dump of > > the dalai lama's email'. > > american education is behind in many things. this is but one. So true, Randy. But I think the underlying point here was more "when you do these things on the scale that nation-states do them, the result is different in type, not merely in degree". Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Wed Feb 20 17:21:41 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 20 Feb 2013 12:21:41 -0500 (EST) Subject: Check this out T-Mobile Launches GoSmart Prepaid Service Nationally on Phone Scoop In-Reply-To: <793DCF87-1BA2-4EED-819E-4E4C09A55D2A@froztbyte.net> Message-ID: <25138065.6660.1361380901351.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "JP Viljoen" [ Rich K wrote: ] > > On Wed, Feb 20, 2013 at 07:59:53AM -0500, Robert E. Seastrom wrote: > >> If only there were some kind of method for Jay to publish which > >> addresses are actually authorized to send mail on behalf of [snip] > > > > SPF is snake-oil. Here's something that works (salt to taste for > > the MTA of your choice): > > > > Connect:phonescoop.com ERROR:5.7.1:"550 Mail refused, known forgery > > source" > > From:phonescoop.com ERROR:5.7.1:"550 Mail refused, known forgery > > source" > > Because putting things into a file on your server, instead of some > distributed mechanism we could refer to, makes that much more sense. > Did you guys see this /etc/hosts thing? It's awesome! I DON'T EVEN > HAVE TO RUN A DNS SERVER!! > > *flamesuit* And you'll need the Nomex undies, cause what Rich was *recommending* had nothing to do with that. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From wbailey at satelliteintelligencegroup.com Wed Feb 20 17:47:27 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 20 Feb 2013 17:47:27 +0000 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: <21410540.6654.1361380405540.JavaMail.root@benjamin.baylink.com> Message-ID: If you are doing DS0 splitting on the DACS, you'll see that on the other end (it's not like channelized CAS ds1's or PRI's are difficult to look at now) assuming you have access to that. If the DACS is an issue, buy the DACS and lock it up. I was on a .mil project that used old school Coastcom DI III Mux with RLB cards and FXO/FXS cards, that DACS carried some pretty top notch traffic and the microwave network (licensed .gov band) brought it right back to the base that project was owned by. Security is expensive, because you cannot leverage a service provider model effectively around it. You can explain the billion dollars you spent on your global network of CRS-1's, but CRS-1's for a single application usually are difficult to swallow. I'm not saying that it isn't done EVER, I'm just saying there are ways to avoid your 1998 red hat box from rpc.statd exploitation - unplug aforementioned boxen from inter webs. If you created a LAN at your house, disabled all types of insertable media, and had a decent lock on your front door, it would be pretty difficult to own that network. Sure there are spy types that argue EMI emission from cable etc, but they solved that issue with their tin foil hats. We broadcast extremely sensitive information (financial, medical, etc) to probably 75% of the worlds population all day long, if you walk outside of your house today my signal will be broadcasting down upon sunny St. Petersburg, Florida. Satellite Communications are widely used, the signal is propagated (from GSO generally) over a relatively wide area and no one knows the better. And for those of you who say.. I CAN LOOK AT A SPEC AN TO FIND THE SIGNAL, MEASURE AND DEMODULATE! Take a look at spread spectrum TDMA operation - my signal to noise on my returns is often -4dB to -6dB c/n0 and spread at a factor of 4 to 8. They are expensive, but as far as the planet is concerned they are awgn. I guess it's my argument that if you do a good enough job blending a signal into the noise, you are much more likely to maintain secrecy. On 2/20/13 9:13 AM, "Jay Ashworth" wrote: >----- Original Message ----- >> From: "Warren Bailey" > >> We as Americans have plenty of things we have done halfass.. I hope an >> Internet kill switch doesn't end up being one of them. Build your own >> private networks, you can't get rooted if someone can't knock. Simple >> as that. > >Well, Warren, I once had a discussion with someone about whether dedicated >DS-1 to tie your SCADA network together were "secure enough" and they >asked >me: > >"Does it run through a DACS? Where can you program the DACS from?" > >Cheers, >-- jra >-- >Jay R. Ashworth Baylink >jra at baylink.com >Designer The Things I Think RFC >2100 >Ashworth & Associates http://baylink.pitas.com 2000 Land >Rover DII >St Petersburg FL USA #natog +1 727 647 >1274 > > From cb.list6 at gmail.com Wed Feb 20 18:04:43 2013 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 20 Feb 2013 10:04:43 -0800 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: <21410540.6654.1361380405540.JavaMail.root@benjamin.baylink.com> References: <21410540.6654.1361380405540.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, Feb 20, 2013 at 9:13 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Warren Bailey" > >> We as Americans have plenty of things we have done halfass.. I hope an >> Internet kill switch doesn't end up being one of them. Build your own >> private networks, you can't get rooted if someone can't knock. Simple >> as that. > > Well, Warren, I once had a discussion with someone about whether dedicated > DS-1 to tie your SCADA network together were "secure enough" and they asked > me: > > "Does it run through a DACS? Where can you program the DACS from?" > Did you open that PDF regarding DACS security ? http://money.cnn.com/2013/02/20/news/economy/hacking-infrastructure/index.html CB > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > From jamie at photon.com Wed Feb 20 18:05:04 2013 From: jamie at photon.com (Jamie Bowden) Date: Wed, 20 Feb 2013 18:05:04 +0000 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: References: <21410540.6654.1361380405540.JavaMail.root@benjamin.baylink.com> Message-ID: <465966A5F5B867419F604CD3E604C1E53B034021@PRA-DCA-MAIL.pra.ray.com> > From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] > If you are doing DS0 splitting on the DACS, you'll see that on the > other > end (it's not like channelized CAS ds1's or PRI's are difficult to look > at > now) assuming you have access to that. If the DACS is an issue, buy the > DACS and lock it up. I was on a .mil project that used old school > Coastcom > DI III Mux with RLB cards and FXO/FXS cards, that DACS carried some > pretty > top notch traffic and the microwave network (licensed .gov band) > brought > it right back to the base that project was owned by. Security is > expensive, because you cannot leverage a service provider model > effectively around it. You can explain the billion dollars you spent on > your global network of CRS-1's, but CRS-1's for a single application > usually are difficult to swallow. I'm not saying that it isn't done > EVER, > I'm just saying there are ways to avoid your 1998 red hat box from > rpc.statd exploitation - unplug aforementioned boxen from inter webs. Our connections to various .mil and others are private ds1's with full on end to end crypto over them. You can potentially kill our connections, but you're not snooping them or injecting traffic into them. Jamie From ahebert at pubnix.net Wed Feb 20 18:14:27 2013 From: ahebert at pubnix.net (Alain Hebert) Date: Wed, 20 Feb 2013 13:14:27 -0500 Subject: About private networks (Was Re: NYT covers China cyberthreat) In-Reply-To: <15838105.6656.1361380521041.JavaMail.root@benjamin.baylink.com> References: <15838105.6656.1361380521041.JavaMail.root@benjamin.baylink.com> Message-ID: <51251283.4060206@pubnix.net> ( Well I'm sure that there is a few hundrends of paper on this subject ) I have a few ideas but it involve: .Dark Fiber; . All devices at FIPS 140 level; . Tonnes of resin; . Wire mesh; . Fiber DB monitoring; . Cable Shield monitoring; . Single Encryption Key injection for the FIPS 140 devices; . Central Provisioning; . Kill switch for suspected segments; And a private fab because it would not be a good idea to sub-contract that to lets says... some Chinese outfit =D TLDR: Feasable, hella costly. PS: http://spybusters.blogspot.ca/2010/11/fiber-optics-easier-to-wiretap-than.html Enjoy this week end of the world news. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 From jared at compuwizz.net Wed Feb 20 18:16:26 2013 From: jared at compuwizz.net (Jared Geiger) Date: Wed, 20 Feb 2013 13:16:26 -0500 Subject: TelePacific a good choice? In-Reply-To: References: <1132441074.4967.1361330136747.JavaMail.root@zimbra.well.com> Message-ID: We have a customer who used them for IP transit at an office in San Francisco. They seemed to have issues with International peering. Traffic to Asia / Australia seemed to be bottlenecked. This was a year ago and the bottleneck was between TelePacific and Global Crossing at the time. The customer has moved to another provider and no longer has issues. ~Jared On Tue, Feb 19, 2013 at 11:10 PM, Mike Hale wrote: > I've used them at a previous employer, mainly for PRI termination but > also for some transit and colo services. > > They were decent. Didn't have any major complaints. > > If IPv6 is important for you...per what Paul said, they probably > wouldn't be your best choice. If IPv6 doesn't matter to you, they're > good enough. > > On Tue, Feb 19, 2013 at 7:37 PM, Paul WALL wrote: > > The lack of IPv6 implementation: > > > > http://bgp.he.net/AS14265#_asinfo > > > > should be the only feedback you need. > > > > On 2/19/13, Jeff Harper wrote: > >> Hiya, > >> > >> We're looking at TelePacific as a possible solution for some of our > transit > >> needs. If you have an honest experience with them, positive or > negative, > >> I'd like to hear from you. > >> > >> Simply email me off line with your experiences, thanks! > >> > >> Jeff Harper, CCIE (W) | www.well.com > >> ip access-list extended jeff > >> permit tcp any any eq intelligence > >> deny tcp any any eq stupid-people > >> > >> > >> > > > > > > -- > 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 > > From wbailey at satelliteintelligencegroup.com Wed Feb 20 18:21:37 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 20 Feb 2013 18:21:37 +0000 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: <465966A5F5B867419F604CD3E604C1E53B034021@PRA-DCA-MAIL.pra.ray.com> Message-ID: I did not approach the inline encryption units on purpose. Obviously anything that leaves .mil land not riding something blessed by DISA is going to have something like a KG on both ends. Generally Satellite systems use TRANSEC, though in our line of work it's an extremely expensive add-on to an otherwise decent security implementation. I'm not saying it can NEVER be owned, I'm just saying that 90% of the l33t hax0rs who are going to look to own something are doing so because it is somehow exposed to public infrastructure. If I were to put up an SCPC (single channel per carrier, synonymous to point to point circuits) circuit between point A and B, the persons looking to intercept my traffic would need to know quite a bit of information about my signals.. Origination Point, Destination Point, Modulation, Symbol Rates, Center Frequencies, PN codes, TRANSEC keys, IP lay out, etc. You won't hear me talk about how something is absolutely and completely secure, but you will hear me preach from the rooftops the application of technology that many people believe is outdated and abandoned. There is a reason media providers and MSO's still use Satellite to downlink video signals. The military is still heavily invested in this type of technology because you are able to completely bypass traditionally used infrastructure, and Utility companies are jumping on the band wagon as well. I know of several SCADA (massive power companies) networks that ride satellite completely for this reason. You can justify the cost and latency with the security of owning a network that is completely removed from the usual infrastructure. On 2/20/13 10:05 AM, "Jamie Bowden" wrote: >> From: Warren Bailey [mailto:wbailey at satelliteintelligencegroup.com] > > >> If you are doing DS0 splitting on the DACS, you'll see that on the >> other >> end (it's not like channelized CAS ds1's or PRI's are difficult to look >> at >> now) assuming you have access to that. If the DACS is an issue, buy the >> DACS and lock it up. I was on a .mil project that used old school >> Coastcom >> DI III Mux with RLB cards and FXO/FXS cards, that DACS carried some >> pretty >> top notch traffic and the microwave network (licensed .gov band) >> brought >> it right back to the base that project was owned by. Security is >> expensive, because you cannot leverage a service provider model >> effectively around it. You can explain the billion dollars you spent on >> your global network of CRS-1's, but CRS-1's for a single application >> usually are difficult to swallow. I'm not saying that it isn't done >> EVER, >> I'm just saying there are ways to avoid your 1998 red hat box from >> rpc.statd exploitation - unplug aforementioned boxen from inter webs. > >Our connections to various .mil and others are private ds1's with full on >end to end crypto over them. You can potentially kill our connections, >but you're not snooping them or injecting traffic into them. > >Jamie > From Valdis.Kletnieks at vt.edu Wed Feb 20 18:33:53 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 20 Feb 2013 13:33:53 -0500 Subject: NYT covers China cyberthreat In-Reply-To: Your message of "Wed, 20 Feb 2013 15:39:42 +0900." References: <94bf868f-e631-49ca-b5c8-b1ed0f9333f2@email.android.com> Message-ID: <8031.1361385233@turing-police.cc.vt.edu> On Wed, 20 Feb 2013 15:39:42 +0900, Randy Bush said: > boys and girls, all the cyber-capable countries are cyber-culpable. you > can bet that they are all snooping and attacking eachother, the united > states no less than the rest. news at eleven. The scary part is that so many things got hacked by a bunch of people who made the totally noob mistake of launching all their attacks from the same place.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jlewis at lewis.org Wed Feb 20 19:05:08 2013 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 20 Feb 2013 14:05:08 -0500 (EST) Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: <21410540.6654.1361380405540.JavaMail.root@benjamin.baylink.com> References: <21410540.6654.1361380405540.JavaMail.root@benjamin.baylink.com> Message-ID: On Wed, 20 Feb 2013, Jay Ashworth wrote: > Well, Warren, I once had a discussion with someone about whether dedicated > DS-1 to tie your SCADA network together were "secure enough" and they asked > me: > > "Does it run through a DACS? Where can you program the DACS from?" See thread: nanog impossible circuit Even your leased lines can have packets copied off or injected into them, apparently so easily it can be done by accident. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From owen at delong.com Wed Feb 20 19:18:29 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Feb 2013 11:18:29 -0800 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: References: Message-ID: <7730582D-EA89-4516-B38E-6ADF0051BCD9@delong.com> Many DACS have provision for "monitoring" circuits and feeding the data off to a third circuit in an undetectable manner. The DACS question wasn't about DACS owned by the people using the circuit, it was about DACS inside the circuit provider. When you buy a DS1 that goes through more than one CO in between two points, you're virtually guaranteed that it goes through one or more of {DS-3 Mux, Fiber Mux, DACS, etc.}. All of these are under the control of the circuit provider and not you. Owen On Feb 20, 2013, at 09:47 , Warren Bailey wrote: > If you are doing DS0 splitting on the DACS, you'll see that on the other > end (it's not like channelized CAS ds1's or PRI's are difficult to look at > now) assuming you have access to that. If the DACS is an issue, buy the > DACS and lock it up. I was on a .mil project that used old school Coastcom > DI III Mux with RLB cards and FXO/FXS cards, that DACS carried some pretty > top notch traffic and the microwave network (licensed .gov band) brought > it right back to the base that project was owned by. Security is > expensive, because you cannot leverage a service provider model > effectively around it. You can explain the billion dollars you spent on > your global network of CRS-1's, but CRS-1's for a single application > usually are difficult to swallow. I'm not saying that it isn't done EVER, > I'm just saying there are ways to avoid your 1998 red hat box from > rpc.statd exploitation - unplug aforementioned boxen from inter webs. > > If you created a LAN at your house, disabled all types of insertable > media, and had a decent lock on your front door, it would be pretty > difficult to own that network. Sure there are spy types that argue EMI > emission from cable etc, but they solved that issue with their tin foil > hats. We broadcast extremely sensitive information (financial, medical, > etc) to probably 75% of the worlds population all day long, if you walk > outside of your house today my signal will be broadcasting down upon sunny > St. Petersburg, Florida. Satellite Communications are widely used, the > signal is propagated (from GSO generally) over a relatively wide area and > no one knows the better. And for those of you who say.. I CAN LOOK AT A > SPEC AN TO FIND THE SIGNAL, MEASURE AND DEMODULATE! Take a look at spread > spectrum TDMA operation - my signal to noise on my returns is often -4dB > to -6dB c/n0 and spread at a factor of 4 to 8. They are expensive, but as > far as the planet is concerned they are awgn. I guess it's my argument > that if you do a good enough job blending a signal into the noise, you are > much more likely to maintain secrecy. > > On 2/20/13 9:13 AM, "Jay Ashworth" wrote: > >> ----- Original Message ----- >>> From: "Warren Bailey" >> >>> We as Americans have plenty of things we have done halfass.. I hope an >>> Internet kill switch doesn't end up being one of them. Build your own >>> private networks, you can't get rooted if someone can't knock. Simple >>> as that. >> >> Well, Warren, I once had a discussion with someone about whether dedicated >> DS-1 to tie your SCADA network together were "secure enough" and they >> asked >> me: >> >> "Does it run through a DACS? Where can you program the DACS from?" >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink >> jra at baylink.com >> Designer The Things I Think RFC >> 2100 >> Ashworth & Associates http://baylink.pitas.com 2000 Land >> Rover DII >> St Petersburg FL USA #natog +1 727 647 >> 1274 >> >> > > From jra at baylink.com Wed Feb 20 19:22:02 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 20 Feb 2013 14:22:02 -0500 (EST) Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: <7730582D-EA89-4516-B38E-6ADF0051BCD9@delong.com> Message-ID: <236723.6684.1361388122424.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > Many DACS have provision for "monitoring" circuits and feeding the > data off to a third circuit in an undetectable manner. > > The DACS question wasn't about DACS owned by the people using the > circuit, it was about DACS inside the circuit provider. When you buy a > DS1 that goes through more than one CO in between two points, you're > virtually guaranteed that it goes through one or more of {DS-3 Mux, > Fiber Mux, DACS, etc.}. All of these are under the control of the > circuit provider and not you. Correct, and they expand the attack surface in ways that even many network engineers may not consider unless prompted. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From wbailey at satelliteintelligencegroup.com Wed Feb 20 19:33:33 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 20 Feb 2013 19:33:33 +0000 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: <236723.6684.1361388122424.JavaMail.root@benjamin.baylink.com> Message-ID: Isn't this a strong argument to deploy and operate a network independent of the traditional switch circuit provider space? On 2/20/13 11:22 AM, "Jay Ashworth" wrote: >----- Original Message ----- >> From: "Owen DeLong" > >> Many DACS have provision for "monitoring" circuits and feeding the >> data off to a third circuit in an undetectable manner. >> >> The DACS question wasn't about DACS owned by the people using the >> circuit, it was about DACS inside the circuit provider. When you buy a >> DS1 that goes through more than one CO in between two points, you're >> virtually guaranteed that it goes through one or more of {DS-3 Mux, >> Fiber Mux, DACS, etc.}. All of these are under the control of the >> circuit provider and not you. > >Correct, and they expand the attack surface in ways that even many >network engineers may not consider unless prompted. > >Cheers, >-- jra >-- >Jay R. Ashworth Baylink >jra at baylink.com >Designer The Things I Think RFC >2100 >Ashworth & Associates http://baylink.pitas.com 2000 Land >Rover DII >St Petersburg FL USA #natog +1 727 647 >1274 > > From surfer at mauigateway.com Wed Feb 20 19:34:20 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 20 Feb 2013 11:34:20 -0800 Subject: NYT covers China cyberthreat Message-ID: <20130220113420.87B4C842@m0005297.ppops.net> --- Valdis.Kletnieks at vt.edu wrote: On Wed, 20 Feb 2013 15:39:42 +0900, Randy Bush said: > boys and girls, all the cyber-capable countries are cyber-culpable. you > can bet that they are all snooping and attacking eachother, the united > states no less than the rest. news at eleven. The scary part is that so many things got hacked by a bunch of people who made the totally noob mistake of launching all their attacks from the same place.... ------------------------------------------------ Maybe. The report says the following, but it doesn't make clear (I'm only on page 31, so I don't know if they do later in the report) if this is a small botnet, or individuals manning the 937 C&C servers: ?? APT1 controls thousands of systems in support of their computer intrusion activities. ?? In the last two years we have observed APT1 establish a minimum of 937 Command and Control (C2) servers hosted on 849 distinct IP addresses in 13 countries. The majority of these 849 unique IP addresses were registered to organizations in China (709), followed by the U.S. (109). ?? In the last three years we have observed APT1 use fully qualified domain names (FQDNs) resolving to 988 unique IP addresses. ?? Over a two-year period (January 2011 to January 2013) we confirmed 1,905 instances of APT1 actors logging into their attack infrastructure from 832 different IP addresses with Remote Desktop, a tool that provides a remote user with an interactive graphical interface to a system. ?? In the last several years we have confirmed 2,551 FQDNs attributed to APT1. ?? We observed 767 separate instances in which APT1 intruders used the ?HUC Packet Transmit Tool? or HTRAN to communicate between 614 distinct routable IP addresses and their victims? systems using their attack infrastructure. scott From owen at delong.com Wed Feb 20 19:39:09 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Feb 2013 11:39:09 -0800 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: References: Message-ID: If you have that option, I suppose that would be one way to solve it. I, rather, see it as a reason to: 1. Cryptographically secure links that may be carrying private data. 2. Rotate cryptographic keys (relatively) often on such links. YMMV, but I think encryption is a lot cheaper than building a telco. Especially over long distances. Owen On Feb 20, 2013, at 11:33 , Warren Bailey wrote: > Isn't this a strong argument to deploy and operate a network independent > of the traditional switch circuit provider space? > > On 2/20/13 11:22 AM, "Jay Ashworth" wrote: > >> ----- Original Message ----- >>> From: "Owen DeLong" >> >>> Many DACS have provision for "monitoring" circuits and feeding the >>> data off to a third circuit in an undetectable manner. >>> >>> The DACS question wasn't about DACS owned by the people using the >>> circuit, it was about DACS inside the circuit provider. When you buy a >>> DS1 that goes through more than one CO in between two points, you're >>> virtually guaranteed that it goes through one or more of {DS-3 Mux, >>> Fiber Mux, DACS, etc.}. All of these are under the control of the >>> circuit provider and not you. >> >> Correct, and they expand the attack surface in ways that even many >> network engineers may not consider unless prompted. >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink >> jra at baylink.com >> Designer The Things I Think RFC >> 2100 >> Ashworth & Associates http://baylink.pitas.com 2000 Land >> Rover DII >> St Petersburg FL USA #natog +1 727 647 >> 1274 >> >> > > From thegameiam at yahoo.com Wed Feb 20 19:48:29 2013 From: thegameiam at yahoo.com (David Barak) Date: Wed, 20 Feb 2013 11:48:29 -0800 (PST) Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: <236723.6684.1361388122424.JavaMail.root@benjamin.baylink.com> Message-ID: <1361389709.14531.YahooMailClassic@web31812.mail.mud.yahoo.com> --- On Wed, 2/20/13, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Owen DeLong" > > The DACS question wasn't about DACS owned by the people > using the > > circuit, it was about DACS inside the circuit provider. > When you buy a > > DS1 that goes through more than one CO in between two > points, you're > > virtually guaranteed that it goes through one or more > of {DS-3 Mux, > > Fiber Mux, DACS, etc.}. All of these are under the > control of the > > circuit provider and not you. > > Correct, and they expand the attack surface in ways that > even many > network engineers may not consider unless prompted. This is precisely the value of encryption on point to point links, preferably at the link layer rather than at the IP layer. When coupled with decent end-to-end application-layer encryption on top of that, the value proposition for sniffing traffic from the network drops a whole lot. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From jra at baylink.com Wed Feb 20 19:49:49 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 20 Feb 2013 19:49:49 GMT Subject: FCC Commits to Opening Up More 5GHz Airwaves Message-ID: <201302201949.r1KJnn1W032416@web2.phonescoop.com> Might this solve the "10MB problem" discussed on NANOG? Cheers, -- jra http://www.phonescoop.com/articles/article.php?a=11953 This email was sent via Phone Scoop (www.phonescoop.com). The sender thought you might be interested in the page linked above. From jbates at brightok.net Wed Feb 20 20:20:45 2013 From: jbates at brightok.net (Jack Bates) Date: Wed, 20 Feb 2013 14:20:45 -0600 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: References: <21410540.6654.1361380405540.JavaMail.root@benjamin.baylink.com> Message-ID: <5125301D.2090905@brightok.net> On 2/20/2013 1:05 PM, Jon Lewis wrote: > > See thread: nanog impossible circuit > > Even your leased lines can have packets copied off or injected into > them, apparently so easily it can be done by accident. > This is especially true with pseudo-wire and mpls. Most of my equipment can filter based mirror to alternative mpls circuits where I can drop packets into my analyzers. If I misconfigure, those packets could easily find themselves back on public networks. Jack From jra at baylink.com Wed Feb 20 20:34:02 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 20 Feb 2013 15:34:02 -0500 (EST) Subject: FCC Commits to Opening Up More 5GHz Airwaves In-Reply-To: <201302201949.r1KJnn1W032416@web2.phonescoop.com> Message-ID: <29024245.6688.1361392442286.JavaMail.root@benjamin.baylink.com> Oooh. We're getting even cleverer. No, this wasn't me either. Moderators: please put my address on moderation? Cheers, -- jr 'yes, this request really came from me :-)' a ----- Original Message ----- > From: "Jay Ashworth" > To: nanog at nanog.org > Sent: Wednesday, February 20, 2013 2:49:49 PM > Subject: FCC Commits to Opening Up More 5GHz Airwaves > Might this solve the "10MB problem" discussed on NANOG? > > Cheers, > -- jra > > http://www.phonescoop.com/articles/article.php?a=11953 > > This email was sent via Phone Scoop (www.phonescoop.com). The sender > thought you might be interested in the page linked above. -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From thomasammon at gmail.com Wed Feb 20 22:25:18 2013 From: thomasammon at gmail.com (Tom Ammon) Date: Wed, 20 Feb 2013 15:25:18 -0700 Subject: Anyone know of a good InfiniBand vendor in the US? In-Reply-To: References: <9137230821910144412@unknownmsgid> Message-ID: IPoIB looks more like an application than a network protocol to Infiniband. The IB fabric doesn't have a concept of broadcast, so ARP works much differently than it does in IPv4/ethernet world - basically an all-nodes multicast group handles the distribution of ARP messages. That said, the ib drivers that come with redhat/centos are pretty good, and you can always download the official OFED drivers from the OFA at https://www.openfabrics.org/linux-sources.html if the stuff in your linux distribution is missing something. I've set up IPoIB routers running 10G NICs on the ethernet side and QDR HCAs on the IB side, using quagga to plug in to the rest of my OSPF network, and it works fine. Basically you just need to set up quagga like you would if you were going to turn a linux box into an ethernet router and don't worry about the fact that it's actually IB on one side of the router - your network statements, etc., in OSPF in quagga won't change at all. You'll find that some things in IB have no equivalent to ethernet. For example, if you want to have gateway redundancy for traffic exiting the IB fabric, your first instinct will be to look for VRRP for IB, but you won't find it, because of the ARP differences I talked about above. To get around this you can set up linux-ha or some other type of heartbeat arrangement and bring up a virtual IP on the active gateway, which can be shifted over to the standby gateway when the ha scripts detect a problem. Some vendors also have proprietary solutions to this problem but they tend to be expensive. So, I'd say, read up on quagga and give that a try, and I think you'll find that as long as the IB drivers are up to snuff (the sminfo command returns valid results, etc.) it'll pretty much just work for you. I'm also happy to discuss more offline if you prefer. Tom Tom On Tue, Feb 19, 2013 at 5:55 PM, Jon Lewis wrote: > On Tue, 19 Feb 2013, Landon Stewart wrote: > > Oh by vendor I mean VAR I guess. Mostly I'm also wondering how an IB >> network handles IPoIB and how one uses IB with a gateway to layer 3 >> Ethernet switches or edge routers. If anyone has any resources that >> provide details on how this works and how ethernet VLANs are handled I'd >> appreciate it. >> > > My limited IB experience has been that the IB switch acts much like a dumb > ethernet switch, caring only about which IB hardware addresses are > reachable via which port. Routing between IPoIB and IP over ethernet can > be done by any host with interfaces on both networks and IP forwarding > enabled. In our setups, we've used IPoIB, but with 1918 addresses and not > routed beyond the IB network. > > ------------------------------**------------------------------**---------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/**pgpfor PGP public key_________ > > -- ----------------------------------------------------------------------------- Tom Ammon Network Engineer M: (801) 674-9273 tom at tomsbox.net ----------------------------------------------------------------------------- From deric.kwok2000 at gmail.com Wed Feb 20 22:44:35 2013 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Wed, 20 Feb 2013 17:44:35 -0500 Subject: can you share ipv6 addressallo cation Message-ID: Hi all I am searching information about ipv6 addressallocation for /32 Any experience and advice can be shared eg: loopback. peer to peer, Thank you so much From joelja at bogus.com Wed Feb 20 23:02:07 2013 From: joelja at bogus.com (joel jaeggli) Date: Wed, 20 Feb 2013 15:02:07 -0800 Subject: can you share ipv6 addressallo cation In-Reply-To: References: Message-ID: <512555EF.4070000@bogus.com> how you subnet a network operator is is fairly complex topic even if the principles are rather simple. http://tools.ietf.org/html/rfc5375.html includes among other things some case studies. there's quite a lot of source material from the various nog(s) where people have presented on their own experiences. http://www.getipv6.info/index.php/IPv6_Presentations_and_Documents On 2/20/13 2:44 PM, Deric Kwok wrote: > Hi all > > I am searching information about ipv6 addressallocation for /32 > > Any experience and advice can be shared > > eg: loopback. peer to peer, > > Thank you so much > From surfer at mauigateway.com Thu Feb 21 00:29:48 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 20 Feb 2013 16:29:48 -0800 Subject: NYT covers China cyberthreat Message-ID: <20130220162948.87B4F422@m0005297.ppops.net> --- Valdis.Kletnieks at vt.edu wrote: The scary part is that so many things got hacked by a bunch of people who made the totally noob mistake of launching all their attacks from the same place.... ------------------------------------------------ This all seems to be noobie stuff. There's nothing technically cool to see here. All they do is spear phishing and, once the link is clicked, put in a backdoor that uses commonly available tools. As I suspected earlier it's M$ against M$ only. The downside is nontechnical folks in positions of power often have sensitive data on their computers, only know M$ and don't have the knowledge to don't click on that "bank" email. Technically, it was 74 pages of yawn. Don't waste your time unless you're interested in how they found out where the attack was originating from and how they tied it to the .cn gov't. scott From ops.lists at gmail.com Thu Feb 21 01:20:23 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 21 Feb 2013 06:50:23 +0530 Subject: NYT covers China cyberthreat In-Reply-To: <20130220162948.87B4F422@m0005297.ppops.net> References: <20130220162948.87B4F422@m0005297.ppops.net> Message-ID: Net net - what we have here is, so far, relatively low tech exploits with a huge element of brute force, and the only innovation being in the delivery mechanism - very well crafted spear phishes They don't particularly need to hide in a location where they're literally bulletproof (considering how many crimes have the death penalty in china, said penalty being enforced by a bullet to the head and your family billed for the bullet, if I remember correctly) Now there's a light shone on it all, despite the official denial, you'll simply see this office building shift to an even more anonymous business park halfway across the country (or maybe inside an army base that people just can't wander into and photograph), and the exploits will simply start to cover their traces better. Sure they'll evolve - let them. The point here is that they're going to evolve anyway if we let them operate with impunity from a location where they're bulletproof. --srs On Thursday, February 21, 2013, Scott Weeks wrote: > > > --- Valdis.Kletnieks at vt.edu wrote: > The scary part is that so many things got hacked by a bunch of people > who made the totally noob mistake of launching all their attacks from > the same place.... > ------------------------------------------------ > > > This all seems to be noobie stuff. There's nothing technically cool > to see here. All they do is spear phishing and, once the link is > clicked, put in a backdoor that uses commonly available tools. As > I suspected earlier it's M$ against M$ only. > > The downside is nontechnical folks in positions of power often have > sensitive data on their computers, only know M$ and don't have the > knowledge to don't click on that "bank" email. > > Technically, it was 74 pages of yawn. Don't waste your time unless > you're interested in how they found out where the attack was > originating from and how they tied it to the .cn gov't. > > scott > > -- --srs (iPad) From jason at thebaughers.com Thu Feb 21 01:41:32 2013 From: jason at thebaughers.com (Jason Baugher) Date: Wed, 20 Feb 2013 19:41:32 -0600 Subject: FCC Commits to Opening Up More 5GHz Airwaves In-Reply-To: <29024245.6688.1361392442286.JavaMail.root@benjamin.baylink.com> References: <201302201949.r1KJnn1W032416@web2.phonescoop.com> <29024245.6688.1361392442286.JavaMail.root@benjamin.baylink.com> Message-ID: But how do we KNOW this really came from you? :) On Wed, Feb 20, 2013 at 2:34 PM, Jay Ashworth wrote: > Oooh. We're getting even cleverer. No, this wasn't me either. > > Moderators: please put my address on moderation? > > Cheers, > -- jr 'yes, this request really came from me :-)' a > > ----- Original Message ----- > > From: "Jay Ashworth" > > To: nanog at nanog.org > > Sent: Wednesday, February 20, 2013 2:49:49 PM > > Subject: FCC Commits to Opening Up More 5GHz Airwaves > > Might this solve the "10MB problem" discussed on NANOG? > > > > Cheers, > > -- jra > > > > http://www.phonescoop.com/articles/article.php?a=11953 > > > > This email was sent via Phone Scoop (www.phonescoop.com). The sender > > thought you might be interested in the page linked above. > > -- > Jay R. Ashworth Baylink > jra at baylink.com > Designer The Things I Think RFC > 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land > Rover DII > St Petersburg FL USA #natog +1 727 647 > 1274 > > From wbailey at satelliteintelligencegroup.com Thu Feb 21 01:34:13 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 21 Feb 2013 01:34:13 +0000 Subject: NYT covers China cyberthreat In-Reply-To: References: <20130220162948.87B4F422@m0005297.ppops.net>, Message-ID: I can't help but wonder what would happen if US Corporations simply blocked all inbound Chinese traffic. Sure it would hurt their business, but imagine what the Chinese people would do in response. It seems like China takes very little seriously until it goes mainstream. This is happening right now with their political system, they are attempting (publicly) to rid themselves of bad apples. I think this applies to the majority of the Internet dependant countries, people are ready to jump out of a window if facebook or Twitter is down. Imagine the revolt after every major US based provider stopped taking their calls, and data. I understand the implications, but I think this may be the only real way to spank them (I know the financial ramifications..) >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Suresh Ramasubramanian Date: 02/20/2013 5:22 PM (GMT-08:00) To: surfer at mauigateway.com Cc: nanog at nanog.org Subject: Re: NYT covers China cyberthreat Net net - what we have here is, so far, relatively low tech exploits with a huge element of brute force, and the only innovation being in the delivery mechanism - very well crafted spear phishes They don't particularly need to hide in a location where they're literally bulletproof (considering how many crimes have the death penalty in china, said penalty being enforced by a bullet to the head and your family billed for the bullet, if I remember correctly) Now there's a light shone on it all, despite the official denial, you'll simply see this office building shift to an even more anonymous business park halfway across the country (or maybe inside an army base that people just can't wander into and photograph), and the exploits will simply start to cover their traces better. Sure they'll evolve - let them. The point here is that they're going to evolve anyway if we let them operate with impunity from a location where they're bulletproof. --srs On Thursday, February 21, 2013, Scott Weeks wrote: > > > --- Valdis.Kletnieks at vt.edu wrote: > The scary part is that so many things got hacked by a bunch of people > who made the totally noob mistake of launching all their attacks from > the same place.... > ------------------------------------------------ > > > This all seems to be noobie stuff. There's nothing technically cool > to see here. All they do is spear phishing and, once the link is > clicked, put in a backdoor that uses commonly available tools. As > I suspected earlier it's M$ against M$ only. > > The downside is nontechnical folks in positions of power often have > sensitive data on their computers, only know M$ and don't have the > knowledge to don't click on that "bank" email. > > Technically, it was 74 pages of yawn. Don't waste your time unless > you're interested in how they found out where the attack was > originating from and how they tied it to the .cn gov't. > > scott > > -- --srs (iPad) From smb at cs.columbia.edu Thu Feb 21 01:43:45 2013 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 20 Feb 2013 20:43:45 -0500 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: <5125301D.2090905@brightok.net> References: <21410540.6654.1361380405540.JavaMail.root@benjamin.baylink.com> <5125301D.2090905@brightok.net> Message-ID: On Feb 20, 2013, at 3:20 PM, Jack Bates wrote: > On 2/20/2013 1:05 PM, Jon Lewis wrote: >> >> See thread: nanog impossible circuit >> >> Even your leased lines can have packets copied off or injected into them, apparently so easily it can be done by accident. >> > > This is especially true with pseudo-wire and mpls. Most of my equipment can filter based mirror to alternative mpls circuits where I can drop packets into my analyzers. If I misconfigure, those packets could easily find themselves back on public networks. > An amazing percentage of "private" lines are pseudowires, and neither you nor your telco salesdroid can know or tell; even the "real" circuits are routed through DACS, ATM switches, and the like. This is what link encryptors are all about; use them. (Way back when, we had a policy of using link encryptors on all overseas circuits -- there was a high enough probability of underwater fiber cuts, perhaps by fishing trawlers or "fishing trawlers", that our circuits mighty suddenly end up on a satellite link. And we were only worrying about commercial-grade security.) --Steve Bellovin, https://www.cs.columbia.edu/~smb From bzs at world.std.com Thu Feb 21 01:48:19 2013 From: bzs at world.std.com (Barry Shein) Date: Wed, 20 Feb 2013 20:48:19 -0500 Subject: NYT covers China cyberthreat In-Reply-To: <1587878806.245116.1361347855913.JavaMail.sas1@[172.29.251.236]> References: <20130220000235.87B48FE5@m0005297.ppops.net> <1587878806.245116.1361347855913.JavaMail.sas1@[172.29.251.236]> Message-ID: <20773.31971.352461.384037@world.std.com> Failure to understand reality is not reality's fault. On February 20, 2013 at 09:10 calin.chiorean at secdisk.net (calin.chiorean) wrote: > > If I didn't miss any part of the report, no *nix is mentioned. > > I'm a *nix fan, but why they (when I say they, I mean an attacker, not necessary the one in this document) should complicate their life, when all tools are available for windows os, you just have to compile them. > > Cheers, > Calin > > > ---- On Wed, 20 Feb 2013 09:02:35 +0100 Scott Weeks wrote ---- > > > > > > > > >Be sure to read the source: > > > >intelreport.mandiant.com/Mandiant_APT1_Report.pdf > > > >I'm only part way through, but I find it hard to believe that > >only micro$loth computers are used as the attack OS. Maybe I > >haven't gotten far enough through report to find the part > >where they use the *nix boxes? > > > >scott > > > > > -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From jra at baylink.com Thu Feb 21 01:52:45 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 20 Feb 2013 20:52:45 -0500 Subject: FCC Commits to Opening Up More 5GHz Airwaves In-Reply-To: References: <201302201949.r1KJnn1W032416@web2.phonescoop.com> <29024245.6688.1361392442286.JavaMail.root@benjamin.baylink.com> Message-ID: <018bde17-427a-45ef-bafd-b92a6044591d@email.android.com> That way lies madness and sweaty palms, Jason. But mostly you know because I haven't ever aimed such robots at the list in the 18 years I've been on it. -jra Jason Baugher wrote: >But how do we KNOW this really came from you? :) > > >On Wed, Feb 20, 2013 at 2:34 PM, Jay Ashworth wrote: > >> Oooh. We're getting even cleverer. No, this wasn't me either. >> >> Moderators: please put my address on moderation? >> >> Cheers, >> -- jr 'yes, this request really came from me :-)' a >> >> ----- Original Message ----- >> > From: "Jay Ashworth" >> > To: nanog at nanog.org >> > Sent: Wednesday, February 20, 2013 2:49:49 PM >> > Subject: FCC Commits to Opening Up More 5GHz Airwaves >> > Might this solve the "10MB problem" discussed on NANOG? >> > >> > Cheers, >> > -- jra >> > >> > http://www.phonescoop.com/articles/article.php?a=11953 >> > >> > This email was sent via Phone Scoop (www.phonescoop.com). The >sender >> > thought you might be interested in the page linked above. >> >> -- >> Jay R. Ashworth Baylink >> jra at baylink.com >> Designer The Things I Think >RFC >> 2100 >> Ashworth & Associates http://baylink.pitas.com 2000 Land >> Rover DII >> St Petersburg FL USA #natog +1 727 >647 >> 1274 >> >> -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From owen at delong.com Thu Feb 21 02:00:33 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Feb 2013 18:00:33 -0800 Subject: can you share ipv6 addressallo cation In-Reply-To: References: Message-ID: <56982C89-3F69-41BD-9097-C1E268519D3D@delong.com> First, if you are starting from a /32 and deciding how to carve it up from there, you are already approaching the problem backwards. The correct approach (general broad strokes) is to: 1. Identify your subnetting needs. A. Infrastructure addressing B. Internal IT needs within the company C. Customer network needs (usually best to count the Infrastructure and Internal IT as n*customers at this point when rolling this all up into a total number of subnets needed). D. Decide on a customer end-site subnet size (unless this is an exceptional case, /48 is a good number to use) 2. Identify the natural aggregation points in your network. 3. Identify the number of /48s (or whatever other size you decided in D) needed in your largest aggregation site. (This should be the sum of all subordinate end-user networks as well as any infrastructure networks, etc. Round that up to a nibble boundary ensuring at least a 25% free space. 4. Identify the total number of aggregation points at the hierarchy level identified in (3) above. 5. Round that up to a nibble boundary as well. 6. Make a request for the prefix size determined by taking the number in 1D (/48) and subtracting the number of bits identified in (3) and (5). e.g. your largest aggregation point serves 50,000 customer end sites and you have 196 such aggregation points. Each customer end-site is to receive a /48. 50,000 customer end-sites is 16-bits. To get a 25% min free, we must round up to 20. This count includes 2 customer end-sites to support ISP infrastructure and internal IT needs, respectively. 196 aggregation points is 8-bits. To get a 25% min free, we must round up to 12. 48-20=28-12=16 -- This network should request a /16 from their RIR. Notes: This is a severe oversimplification. Obviously more details will be required and the process must be adapted to each individual ISP's network topology and other considerations. Your first several iterations of addressing plan will be wrong. Accept it, deploy it, and expect to redo it a few times before you're completely happy with it. Plan big, deploy small the first few times so that you can learn lessons about the big plan while the deployments are still small. Owen On Feb 20, 2013, at 14:44 , Deric Kwok wrote: > Hi all > > I am searching information about ipv6 addressallocation for /32 > > Any experience and advice can be shared > > eg: loopback. peer to peer, > > Thank you so much From smb at cs.columbia.edu Thu Feb 21 02:07:07 2013 From: smb at cs.columbia.edu (Steven Bellovin) Date: Wed, 20 Feb 2013 21:07:07 -0500 Subject: NYT covers China cyberthreat In-Reply-To: <8031.1361385233@turing-police.cc.vt.edu> References: <94bf868f-e631-49ca-b5c8-b1ed0f9333f2@email.android.com> <8031.1361385233@turing-police.cc.vt.edu> Message-ID: <20C408D6-BDE1-4EDF-BE0A-F8E7DAE02633@cs.columbia.edu> On Feb 20, 2013, at 1:33 PM, valdis.kletnieks at vt.edu wrote: > On Wed, 20 Feb 2013 15:39:42 +0900, Randy Bush said: >> boys and girls, all the cyber-capable countries are cyber-culpable. you >> can bet that they are all snooping and attacking eachother, the united >> states no less than the rest. news at eleven. > > The scary part is that so many things got hacked by a bunch of people > who made the totally noob mistake of launching all their attacks from > the same place.... This strongly suggests that it's not their A-team, for whatever value of "their" you prefer. (My favorite mistake was some of them updating their Facebook pages when their work took them outside the Great Firewall.) They just don't show much in the way of good operational security. Aside: A few years ago, a non-US friend of mine mentioned a conversation he'd had with a cyber guy from his own country's military. According to this guy, about 130 countries had active military cyberwarfare units. I don't suppose that the likes of Ruritania has one, but I think it's a safe assumption that more or less every first and second world country, and not a few third world ones are in the list. The claim here is not not that China is engaging in cyberespionage. That would go under the heading of "I'm shocked, shocked to find that there's spying going on here." Rather, the issue that's being raised is the target: commercial firms, rather than the usual military and government secrets. That is what the US is saying goes beyond the usual rules of the game. In fact, the US has blamed not just China but also Russia, France, and Israel (see http://www.israelnationalnews.com/News/News.aspx/165108 -- and note that that's an Israeli news site) for such activities. France was notorious for that in the 1990s; there were many press reports of bugged first class seats on Air France, for example. The term for what's going on is "cyberexploitation", as opposed to "cyberwar". The US has never come out against it in principle, though it never likes it when aimed at the US. (Every other nation feels the same way about its companies and networks, of course.) For a good analysis of the legal aspects, see http://www.lawfareblog.com/2011/08/what-is-the-government%E2%80%99s-strategy-for-the-cyber-exploitation-threat/ --Steve Bellovin, https://www.cs.columbia.edu/~smb From owen at delong.com Thu Feb 21 02:07:05 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Feb 2013 18:07:05 -0800 Subject: FCC Commits to Opening Up More 5GHz Airwaves In-Reply-To: <018bde17-427a-45ef-bafd-b92a6044591d@email.android.com> References: <201302201949.r1KJnn1W032416@web2.phonescoop.com> <29024245.6688.1361392442286.JavaMail.root@benjamin.baylink.com> <018bde17-427a-45ef-bafd-b92a6044591d@email.android.com> Message-ID: <5A5E1387-C3AB-4620-ADAC-FFCA8415F35A@delong.com> "I've hacked JRA's private key and I approve this message." (just kidding, but someone had to say it.) Owen On Feb 20, 2013, at 17:52 , Jay Ashworth wrote: > That way lies madness and sweaty palms, Jason. > > But mostly you know because I haven't ever aimed such robots at the list in the 18 years I've been on it. > -jra > > Jason Baugher wrote: > >> But how do we KNOW this really came from you? :) >> >> >> On Wed, Feb 20, 2013 at 2:34 PM, Jay Ashworth wrote: >> >>> Oooh. We're getting even cleverer. No, this wasn't me either. >>> >>> Moderators: please put my address on moderation? >>> >>> Cheers, >>> -- jr 'yes, this request really came from me :-)' a >>> >>> ----- Original Message ----- >>>> From: "Jay Ashworth" >>>> To: nanog at nanog.org >>>> Sent: Wednesday, February 20, 2013 2:49:49 PM >>>> Subject: FCC Commits to Opening Up More 5GHz Airwaves >>>> Might this solve the "10MB problem" discussed on NANOG? >>>> >>>> Cheers, >>>> -- jra >>>> >>>> http://www.phonescoop.com/articles/article.php?a=11953 >>>> >>>> This email was sent via Phone Scoop (www.phonescoop.com). The >> sender >>>> thought you might be interested in the page linked above. >>> >>> -- >>> Jay R. Ashworth Baylink >>> jra at baylink.com >>> Designer The Things I Think >> RFC >>> 2100 >>> Ashworth & Associates http://baylink.pitas.com 2000 Land >>> Rover DII >>> St Petersburg FL USA #natog +1 727 >> 647 >>> 1274 >>> >>> > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. From jra at baylink.com Thu Feb 21 02:12:38 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 20 Feb 2013 21:12:38 -0500 Subject: FCC Commits to Opening Up More 5GHz Airwaves In-Reply-To: <5A5E1387-C3AB-4620-ADAC-FFCA8415F35A@delong.com> References: <201302201949.r1KJnn1W032416@web2.phonescoop.com> <29024245.6688.1361392442286.JavaMail.root@benjamin.baylink.com> <018bde17-427a-45ef-bafd-b92a6044591d@email.android.com> <5A5E1387-C3AB-4620-ADAC-FFCA8415F35A@delong.com> Message-ID: <299532e8-177a-4b4b-8dae-e965f32bba01@email.android.com> Oh, /I'm/ the Whacky Weekend thread this week? Thaaaanks. - jra Owen DeLong wrote: >"I've hacked JRA's private key and I approve this message." > >(just kidding, but someone had to say it.) > >Owen > >On Feb 20, 2013, at 17:52 , Jay Ashworth wrote: > >> That way lies madness and sweaty palms, Jason. >> >> But mostly you know because I haven't ever aimed such robots at the >list in the 18 years I've been on it. >> -jra >> >> Jason Baugher wrote: >> >>> But how do we KNOW this really came from you? :) >>> >>> >>> On Wed, Feb 20, 2013 at 2:34 PM, Jay Ashworth >wrote: >>> >>>> Oooh. We're getting even cleverer. No, this wasn't me either. >>>> >>>> Moderators: please put my address on moderation? >>>> >>>> Cheers, >>>> -- jr 'yes, this request really came from me :-)' a >>>> >>>> ----- Original Message ----- >>>>> From: "Jay Ashworth" >>>>> To: nanog at nanog.org >>>>> Sent: Wednesday, February 20, 2013 2:49:49 PM >>>>> Subject: FCC Commits to Opening Up More 5GHz Airwaves >>>>> Might this solve the "10MB problem" discussed on NANOG? >>>>> >>>>> Cheers, >>>>> -- jra >>>>> >>>>> http://www.phonescoop.com/articles/article.php?a=11953 >>>>> >>>>> This email was sent via Phone Scoop (www.phonescoop.com). The >>> sender >>>>> thought you might be interested in the page linked above. >>>> >>>> -- >>>> Jay R. Ashworth Baylink >>>> jra at baylink.com >>>> Designer The Things I Think > >>> RFC >>>> 2100 >>>> Ashworth & Associates http://baylink.pitas.com 2000 >Land >>>> Rover DII >>>> St Petersburg FL USA #natog +1 >727 >>> 647 >>>> 1274 >>>> >>>> >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From ops.lists at gmail.com Thu Feb 21 02:27:26 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 21 Feb 2013 07:57:26 +0530 Subject: NYT covers China cyberthreat In-Reply-To: <20C408D6-BDE1-4EDF-BE0A-F8E7DAE02633@cs.columbia.edu> References: <94bf868f-e631-49ca-b5c8-b1ed0f9333f2@email.android.com> <8031.1361385233@turing-police.cc.vt.edu> <20C408D6-BDE1-4EDF-BE0A-F8E7DAE02633@cs.columbia.edu> Message-ID: Very true. The objection is more that the exploits are aimed at civilian rather than (or, more accurately, as well as) military / government / beltway targets. Which makes the alleged chinese strategy rather more like financing jehadis to suicide bomb and shoot up hotels and train stations, rather than any sort of disciplined warfare or espionage. --srs (htc one x) On 21-Feb-2013 7:40 AM, "Steven Bellovin" wrote: > > On Feb 20, 2013, at 1:33 PM, valdis.kletnieks at vt.edu wrote: > > > On Wed, 20 Feb 2013 15:39:42 +0900, Randy Bush said: > >> boys and girls, all the cyber-capable countries are cyber-culpable. you > >> can bet that they are all snooping and attacking eachother, the united > >> states no less than the rest. news at eleven. > > > > The scary part is that so many things got hacked by a bunch of people > > who made the totally noob mistake of launching all their attacks from > > the same place.... > > > This strongly suggests that it's not their A-team, for whatever value of > "their" you prefer. (My favorite mistake was some of them updating their > Facebook pages when their work took them outside the Great Firewall.) They > just don't show much in the way of good operational security. > > Aside: A few years ago, a non-US friend of mine mentioned a conversation > he'd had with a cyber guy from his own country's military. According to > this guy, about 130 countries had active military cyberwarfare units. I > don't suppose that the likes of Ruritania has one, but I think it's a safe > assumption that more or less every first and second world country, and not > a few third world ones are in the list. > > The claim here is not not that China is engaging in cyberespionage. That > would go under the heading of "I'm shocked, shocked to find that there's > spying going on here." Rather, the issue that's being raised is the target: > commercial firms, rather than the usual military and government secrets. > That is what the US is saying goes beyond the usual rules of the game. In > fact, the US has blamed not just China but also Russia, France, and Israel > (see http://www.israelnationalnews.com/News/News.aspx/165108 -- and note > that that's an Israeli news site) for such activities. France was > notorious > for that in the 1990s; there were many press reports of bugged first class > seats on Air France, for example. > > The term for what's going on is "cyberexploitation", as opposed to > "cyberwar". > The US has never come out against it in principle, though it never likes it > when aimed at the US. (Every other nation feels the same way about its > companies and networks, of course.) For a good analysis of the legal > aspects, > see > http://www.lawfareblog.com/2011/08/what-is-the-government%E2%80%99s-strategy-for-the-cyber-exploitation-threat/ > > > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > > From jra at baylink.com Thu Feb 21 02:44:09 2013 From: jra at baylink.com (Jay Ashworth) Date: Thu, 21 Feb 2013 02:44:09 GMT Subject: T-Mobile Debuts Novel Network Management with GoSmart Message-ID: <201302210244.r1L2i9DZ001038@web2.phonescoop.com> Check this out. Cheers, -- jra http://www.phonescoop.com/articles/article.php?a=11956 This email was sent via Phone Scoop (www.phonescoop.com). The sender thought you might be interested in the page linked above. From dartonw at gmail.com Thu Feb 21 03:39:05 2013 From: dartonw at gmail.com (Darton Williams) Date: Wed, 20 Feb 2013 22:39:05 -0500 Subject: IPv6 Routes in L3 Message-ID: Anyone have visibility on Level 3 IPv6 routing? I'm unable to reach http://fedoraproject.org by their primary and ended up having to spoof a secondary in local DNS. Note that this is on HughesNet; multiple levels of support have been clueless or stumped. For the curious: [darton at dkw-vostro ~]$ dig -6 @google-public-dns-a.google.com -t aaaa www.fedoraproject.org ; <<>> DiG 9.9.2-P1-RedHat-9.9.2-3.P1.fc17 <<>> -6 @ google-public-dns-a.google.com -t aaaa www.fedoraproject.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21521 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.fedoraproject.org. IN AAAA ;; ANSWER SECTION: www.fedoraproject.org. 1200 IN CNAME wildcard.fedoraproject.org. wildcard.fedoraproject.org. 1200 IN AAAA 2607:f188::dead:beef:cafe:fed1 wildcard.fedoraproject.org. 1200 IN AAAA 2001:4178:2:1269::fed2 wildcard.fedoraproject.org. 1200 IN AAAA 2610:28:3090:3001:dead:beef:cafe:fed4 ;; Query time: 10 msec ;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888) ;; WHEN: Wed Feb 20 22:13:26 2013 ;; MSG SIZE rcvd: 163 Love the beefy theme there... fed2 is the only one I can't reach, and though the AAAA records are round-robin, fed2 appears to be the one to which HTTP requests get routed and tracing that takes me from Salt Lake to Munich by way of Paris before timing out: [darton at dkw-vostro ~]$ traceroute6 -N 64 fedoraproject.org traceroute to fedoraproject.org (2001:4178:2:1269::fed2), 30 hops max, 80 byte packets 1 2001:5b0:216e:9590:280:aeff:fe3f:4965 (2001:5b0:216e:9590:280:aeff:fe3f:4965) 24.672 ms 24.504 ms 24.506 ms 2 * * * 3 2001:5b0:21ff:fffa::100 (2001:5b0:21ff:fffa::100) 1079.945 ms 1237.825 ms 1290.435 ms 4 vlan122.car1.SaltLakeCity1.Level3.net (2001:1900:2100::d9d) 1341.274 ms 1409.308 ms 1411.624 ms 5 vl-11.car2.SaltLakeCity1.Level3.net (2001:1900:4:1::13e) 1489.445 ms 1508.739 ms 1733.181 ms 6 vl-4043.edge3.Denver1.Level3.net (2001:1900:4:1::142) 1578.809 ms 1639.417 ms 1641.692 ms 7 vl-4081.edge6.Denver1.Level3.net (2001:1900:4:1::32) 1641.783 ms vl-4080.edge6.Denver1.Level3.net (2001:1900:4:1::2e) 1691.372 ms vl-4081.edge6.Denver1.Level3.net (2001:1900:4:1::32) 1698.425 ms 8 vl-4042.edge1.Chicago2.Level3.net (2001:1900:4:1::36) 1745.349 ms 1745.056 ms 1744.322 ms 9 vl-4067.car1.Chicago1.Level3.net (2001:1900:4:1::1d) 1744.410 ms 1744.489 ms 1737.454 ms 10 vl-4061.car2.NewYork2.Level3.net (2001:1900:4:1::22) 1873.919 ms 1873.887 ms 1870.193 ms 11 vl-4080.car1.NewYork2.Level3.net (2001:1900:4:1::f1) 1766.868 ms 1766.506 ms 1765.284 ms 12 vl-4061.edge2.Washington1.Level3.net (2001:1900:4:1::105) 1767.345 ms 1767.463 ms 1767.493 ms 13 vl-4081.edge1.Washington1.Level3.net (2001:1900:4:1::d5) 1767.633 ms vl-4083.edge1.Washington1.Level3.net (2001:1900:4:1::dd) 1801.766 ms vl-4081.edge1.Washington1.Level3.net (2001:1900:4:1::d5) 1801.754 ms 14 vl-4086.edge3.Paris1.Level3.net (2001:1900:6:1::15) 1844.308 ms 1844.440 ms 1844.908 ms 15 vl-4081.edge4.Paris1.Level3.net (2001:1900:5:1::12e) 1844.358 ms 1844.415 ms vl-4080.edge4.Paris1.Level3.net (2001:1900:5:1::12a) 1843.473 ms 16 vl-4060.edge3.Frankfurt1.Level3.net (2001:1900:5:1::215) 1845.091 ms 1845.065 ms 1845.030 ms 17 vl-4043.car1.Munich1.Level3.net (2001:1900:5:1::25e) 1845.052 ms 1845.033 ms 1897.648 ms 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * fed4 is a different route: [darton at dkw-vostro ~]$ traceroute6 2610:28:3090:3001:dead:beef:cafe:fed4 traceroute to 2610:28:3090:3001:dead:beef:cafe:fed4 (2610:28:3090:3001:dead:beef:cafe:fed4), 30 hops max, 80 byte packets 1 2001:5b0:216e:9590:280:aeff:fe3f:4965 (2001:5b0:216e:9590:280:aeff:fe3f:4965) 15.410 ms 15.337 ms 15.269 ms 2 * * * 3 2001:5b0:21ff:fffa::100 (2001:5b0:21ff:fffa::100) 897.468 ms 915.494 ms 975.368 ms 4 vlan122.car1.SaltLakeCity1.Level3.net (2001:1900:2100::d9d) 1026.481 ms 1044.762 ms 1164.987 ms 5 vl-4046.edge5.LosAngeles1.Level3.net (2001:1900:4:1::279) 1198.366 ms 1406.782 ms 1504.377 ms 6 vl-60.edge1.LosAngeles9.Level3.net (2001:1900:12:1::d) 1602.064 ms 789.763 ms 646.960 ms 7 gblx-level3-10G.LosAngeles9.Level3.net (2001:1900:4:3::276) 702.353 ms 733.689 ms 902.689 ms 8 snvang.abilene.ucaid.edu (2001:504:d::bd) 966.739 ms 1006.089 ms 1090.304 ms 9 * * * 10 xe-1-0-2.60.rtr.atla.net.internet2.edu (2001:468:1:60::1) 1260.105 ms 1342.136 ms 1386.991 ms 11 chlt7600-gw-to-chltcrs-gw.ncren.net (2610:28:10c:5::2) 1439.616 ms 1550.497 ms 1630.215 ms 12 manningkid-to-chlt7600-gw.ncren.net (2610:28:10c:7::2) 1034.366 ms 1034.401 ms 1172.668 ms 13 2610:28:3090:23::2 (2610:28:3090:23::2) 1003.700 ms 1017.225 ms * 14 2610:28:3090:3001:dead:beef:cafe:fed4 (2610:28:3090:3001:dead:beef:cafe:fed4) 921.136 ms !X 832.055 ms !X 789.599 ms !X Any ideas/comparisons/insights appreciated. This is so far the only native IPv6 connection I have, despite having access to two datacenters and FiOS, so not much to compare it with. Shameful. Regards, Darton Williams ...Yeah, that guy. From dartonw at gmail.com Thu Feb 21 04:05:57 2013 From: dartonw at gmail.com (Darton Williams) Date: Wed, 20 Feb 2013 23:05:57 -0500 Subject: IPv6 Routes in L3 In-Reply-To: References: Message-ID: Sorry for the noise, I just looked at Level3 LG again (it returned unknown error messages the last time I tried this). Approximating the same route, their trace reaches fed2 and actually leaves the inter-VLAN whereas mine stops at hop 13 here. I'm guessing the !filtered at the destination is just ICMP. Traceroute results from Salt Lake City, UT to 2001:4178:2:1269::fed2 1 vl-11.car2.SaltLakeCity1.Level3.net (2001:1900:4:1::13E) 0 msec 0 msec 0 msec 2 vl-4043.edge3.Denver1.Level3.net (2001:1900:4:1::142) 56 msec 32 msec 8 msec 3 vl-4080.edge6.Denver1.Level3.net (2001:1900:4:1::2E) 8 msec 12 msec vl-4081.edge6.Denver1.Level3.net (2001:1900:4:1::32) 12 msec 4 vl-4042.edge1.Chicago2.Level3.net (2001:1900:4:1::36) 36 msec 36 msec 36 msec 5 vl-4067.car1.Chicago1.Level3.net (2001:1900:4:1::1D) 36 msec 36 msec 40 msec 6 vl-4061.car2.NewYork2.Level3.net (2001:1900:4:1::22) 88 msec 180 msec 204 msec 7 vl-4081.car1.NewYork2.Level3.net (2001:1900:4:1::F5) 60 msec 56 msec 56 msec 8 vl-4061.edge2.Washington1.Level3.net (2001:1900:4:1::105) 64 msec 60 msec 64 msec 9 vl-4080.edge1.Washington1.Level3.net (2001:1900:4:1::D1) 60 msec 60 msec 64 msec 10 vl-4086.edge3.Paris1.Level3.net (2001:1900:6:1::15) 160 msec 144 msec 144 msec 11 vl-4081.edge4.Paris1.Level3.net (2001:1900:5:1::12E) 140 msec vl-4080.edge4.Paris1.Level3.net (2001:1900:5:1::12A) 144 msec vl-4081.edge4.Paris1.Level3.net (2001:1900:5:1::12E) 140 msec 12 vl-4060.edge3.Frankfurt1.Level3.net (2001:1900:5:1::215) 152 msec 176 msec 148 msec 13 vl-4043.car1.Munich1.Level3.net (2001:1900:5:1::25E) 172 msec 184 msec 220 msec 14 2001:1900:5:2:2::302 156 msec 156 msec 156 msec 15 te9-1-c1.net.muc2.internetx.de (2001:4178:1::6) 160 msec 160 msec 160 msec 16 2001:4178:2:1269::FED2 !filtered !filtered !filtered On Wed, Feb 20, 2013 at 10:39 PM, Darton Williams wrote: > Anyone have visibility on Level 3 IPv6 routing? I'm unable to reach > http://fedoraproject.org by their primary and ended up having to spoof a > secondary in local DNS. Note that this is on HughesNet; multiple levels of > support have been clueless or stumped. > > For the curious: > > [darton at dkw-vostro ~]$ dig -6 @google-public-dns-a.google.com -t aaaa > www.fedoraproject.org > > ; <<>> DiG 9.9.2-P1-RedHat-9.9.2-3.P1.fc17 <<>> -6 @ > google-public-dns-a.google.com -t aaaa www.fedoraproject.org > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21521 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.fedoraproject.org. IN AAAA > > ;; ANSWER SECTION: > www.fedoraproject.org. 1200 IN CNAME wildcard.fedoraproject.org. > wildcard.fedoraproject.org. 1200 IN AAAA 2607:f188::dead:beef:cafe:fed1 > wildcard.fedoraproject.org. 1200 IN AAAA 2001:4178:2:1269::fed2 > wildcard.fedoraproject.org. 1200 IN AAAA > 2610:28:3090:3001:dead:beef:cafe:fed4 > > ;; Query time: 10 msec > ;; SERVER: 2001:4860:4860::8888#53(2001:4860:4860::8888) > ;; WHEN: Wed Feb 20 22:13:26 2013 > ;; MSG SIZE rcvd: 163 > > Love the beefy theme there... > > fed2 is the only one I can't reach, and though the AAAA records are > round-robin, fed2 appears to be the one to which HTTP requests get routed > and tracing that takes me from Salt Lake to Munich by way of Paris before > timing out: > > [darton at dkw-vostro ~]$ traceroute6 -N 64 fedoraproject.org > traceroute to fedoraproject.org (2001:4178:2:1269::fed2), 30 hops max, 80 > byte packets > 1 2001:5b0:216e:9590:280:aeff:fe3f:4965 > (2001:5b0:216e:9590:280:aeff:fe3f:4965) 24.672 ms 24.504 ms 24.506 ms > 2 * * * > 3 2001:5b0:21ff:fffa::100 (2001:5b0:21ff:fffa::100) 1079.945 ms > 1237.825 ms 1290.435 ms > 4 vlan122.car1.SaltLakeCity1.Level3.net (2001:1900:2100::d9d) 1341.274 > ms 1409.308 ms 1411.624 ms > 5 vl-11.car2.SaltLakeCity1.Level3.net (2001:1900:4:1::13e) 1489.445 ms > 1508.739 ms 1733.181 ms > 6 vl-4043.edge3.Denver1.Level3.net (2001:1900:4:1::142) 1578.809 ms > 1639.417 ms 1641.692 ms > 7 vl-4081.edge6.Denver1.Level3.net (2001:1900:4:1::32) 1641.783 ms > vl-4080.edge6.Denver1.Level3.net (2001:1900:4:1::2e) 1691.372 ms > vl-4081.edge6.Denver1.Level3.net (2001:1900:4:1::32) 1698.425 ms > 8 vl-4042.edge1.Chicago2.Level3.net (2001:1900:4:1::36) 1745.349 ms > 1745.056 ms 1744.322 ms > 9 vl-4067.car1.Chicago1.Level3.net (2001:1900:4:1::1d) 1744.410 ms > 1744.489 ms 1737.454 ms > 10 vl-4061.car2.NewYork2.Level3.net (2001:1900:4:1::22) 1873.919 ms > 1873.887 ms 1870.193 ms > 11 vl-4080.car1.NewYork2.Level3.net (2001:1900:4:1::f1) 1766.868 ms > 1766.506 ms 1765.284 ms > 12 vl-4061.edge2.Washington1.Level3.net (2001:1900:4:1::105) 1767.345 > ms 1767.463 ms 1767.493 ms > 13 vl-4081.edge1.Washington1.Level3.net (2001:1900:4:1::d5) 1767.633 ms > vl-4083.edge1.Washington1.Level3.net (2001:1900:4:1::dd) 1801.766 ms > vl-4081.edge1.Washington1.Level3.net (2001:1900:4:1::d5) 1801.754 ms > 14 vl-4086.edge3.Paris1.Level3.net (2001:1900:6:1::15) 1844.308 ms > 1844.440 ms 1844.908 ms > 15 vl-4081.edge4.Paris1.Level3.net (2001:1900:5:1::12e) 1844.358 ms > 1844.415 ms vl-4080.edge4.Paris1.Level3.net (2001:1900:5:1::12a) > 1843.473 ms > 16 vl-4060.edge3.Frankfurt1.Level3.net (2001:1900:5:1::215) 1845.091 ms > 1845.065 ms 1845.030 ms > 17 vl-4043.car1.Munich1.Level3.net (2001:1900:5:1::25e) 1845.052 ms > 1845.033 ms 1897.648 ms > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > > fed4 is a different route: > > [darton at dkw-vostro ~]$ traceroute6 2610:28:3090:3001:dead:beef:cafe:fed4 > traceroute to 2610:28:3090:3001:dead:beef:cafe:fed4 > (2610:28:3090:3001:dead:beef:cafe:fed4), 30 hops max, 80 byte packets > 1 2001:5b0:216e:9590:280:aeff:fe3f:4965 > (2001:5b0:216e:9590:280:aeff:fe3f:4965) 15.410 ms 15.337 ms 15.269 ms > 2 * * * > 3 2001:5b0:21ff:fffa::100 (2001:5b0:21ff:fffa::100) 897.468 ms 915.494 > ms 975.368 ms > 4 vlan122.car1.SaltLakeCity1.Level3.net (2001:1900:2100::d9d) 1026.481 > ms 1044.762 ms 1164.987 ms > 5 vl-4046.edge5.LosAngeles1.Level3.net (2001:1900:4:1::279) 1198.366 > ms 1406.782 ms 1504.377 ms > 6 vl-60.edge1.LosAngeles9.Level3.net (2001:1900:12:1::d) 1602.064 ms > 789.763 ms 646.960 ms > 7 gblx-level3-10G.LosAngeles9.Level3.net (2001:1900:4:3::276) 702.353 > ms 733.689 ms 902.689 ms > 8 snvang.abilene.ucaid.edu (2001:504:d::bd) 966.739 ms 1006.089 ms > 1090.304 ms > 9 * * * > 10 xe-1-0-2.60.rtr.atla.net.internet2.edu (2001:468:1:60::1) 1260.105 > ms 1342.136 ms 1386.991 ms > 11 chlt7600-gw-to-chltcrs-gw.ncren.net (2610:28:10c:5::2) 1439.616 ms > 1550.497 ms 1630.215 ms > 12 manningkid-to-chlt7600-gw.ncren.net (2610:28:10c:7::2) 1034.366 ms > 1034.401 ms 1172.668 ms > 13 2610:28:3090:23::2 (2610:28:3090:23::2) 1003.700 ms 1017.225 ms * > 14 2610:28:3090:3001:dead:beef:cafe:fed4 > (2610:28:3090:3001:dead:beef:cafe:fed4) 921.136 ms !X 832.055 ms !X > 789.599 ms !X > > Any ideas/comparisons/insights appreciated. This is so far the only native > IPv6 connection I have, despite having access to two datacenters and FiOS, > so not much to compare it with. Shameful. > > > > Regards, > > Darton Williams > > > ...Yeah, that guy. > From surfer at mauigateway.com Thu Feb 21 06:03:41 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 20 Feb 2013 22:03:41 -0800 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) Message-ID: <20130220220341.FAFFAADA@m0005297.ppops.net> --- smb at cs.columbia.edu wrote: From: Steven Bellovin An amazing percentage of "private" lines are pseudowires, and neither you nor your telco salesdroid can know or tell; even the "real" circuits are routed through DACS, ATM switches, and the like. This is what link encryptors are all about; use them. --------------------------------------------------------- I would sure be interested in hearing about hands-on operational experiences with encryptors. Recent experiences have left me with a sour taste in my mouth. blech! scott From richard at pedantictheory.com Thu Feb 21 07:29:45 2013 From: richard at pedantictheory.com (Richard Porter) Date: Thu, 21 Feb 2013 00:29:45 -0700 Subject: NYT covers China cyberthreat In-Reply-To: References: <94bf868f-e631-49ca-b5c8-b1ed0f9333f2@email.android.com> <8031.1361385233@turing-police.cc.vt.edu> <20C408D6-BDE1-4EDF-BE0A-F8E7DAE02633@cs.columbia.edu> Message-ID: When you really look at human behavior the thing that remains the same is core motives. The competition makes sense in that it is human nature to aggresse for resources. We are challenged in the "fact" that we 'want' to belong among the other five. This will never change but????. What is really a travesty here is that most of us have been saying "hey this is critical" and can now shift to "I told you so"? in that if you did what we said to do 1 ? 5 ?. 10 ? years ago .. you would have "mitigated" this risk.. Basically, genetically we have not changed, so what behavior would suggest that (even with the introduction of faster calculators).. why would we change? Just means we would do X faster ??. This is my first comment to the list.. please flame me privately to save the list :) *** or publicly who think I should really be spanked!!! *** Regards, Richard On Feb 20, 2013, at 7:27 PM, Suresh Ramasubramanian wrote: > Very true. The objection is more that the exploits are aimed at civilian > rather than (or, more accurately, as well as) military / government / > beltway targets. > > Which makes the alleged chinese strategy rather more like financing jehadis > to suicide bomb and shoot up hotels and train stations, rather than any > sort of disciplined warfare or espionage. > > --srs (htc one x) > On 21-Feb-2013 7:40 AM, "Steven Bellovin" wrote: > >> >> On Feb 20, 2013, at 1:33 PM, valdis.kletnieks at vt.edu wrote: >> >>> On Wed, 20 Feb 2013 15:39:42 +0900, Randy Bush said: >>>> boys and girls, all the cyber-capable countries are cyber-culpable. you >>>> can bet that they are all snooping and attacking eachother, the united >>>> states no less than the rest. news at eleven. >>> >>> The scary part is that so many things got hacked by a bunch of people >>> who made the totally noob mistake of launching all their attacks from >>> the same place.... >> >> >> This strongly suggests that it's not their A-team, for whatever value of >> "their" you prefer. (My favorite mistake was some of them updating their >> Facebook pages when their work took them outside the Great Firewall.) They >> just don't show much in the way of good operational security. >> >> Aside: A few years ago, a non-US friend of mine mentioned a conversation >> he'd had with a cyber guy from his own country's military. According to >> this guy, about 130 countries had active military cyberwarfare units. I >> don't suppose that the likes of Ruritania has one, but I think it's a safe >> assumption that more or less every first and second world country, and not >> a few third world ones are in the list. >> >> The claim here is not not that China is engaging in cyberespionage. That >> would go under the heading of "I'm shocked, shocked to find that there's >> spying going on here." Rather, the issue that's being raised is the target: >> commercial firms, rather than the usual military and government secrets. >> That is what the US is saying goes beyond the usual rules of the game. In >> fact, the US has blamed not just China but also Russia, France, and Israel >> (see http://www.israelnationalnews.com/News/News.aspx/165108 -- and note >> that that's an Israeli news site) for such activities. France was >> notorious >> for that in the 1990s; there were many press reports of bugged first class >> seats on Air France, for example. >> >> The term for what's going on is "cyberexploitation", as opposed to >> "cyberwar". >> The US has never come out against it in principle, though it never likes it >> when aimed at the US. (Every other nation feels the same way about its >> companies and networks, of course.) For a good analysis of the legal >> aspects, >> see >> http://www.lawfareblog.com/2011/08/what-is-the-government%E2%80%99s-strategy-for-the-cyber-exploitation-threat/ >> >> >> >> >> --Steve Bellovin, https://www.cs.columbia.edu/~smb >> >> >> >> >> >> >> From wbailey at satelliteintelligencegroup.com Thu Feb 21 07:35:14 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 21 Feb 2013 07:35:14 +0000 Subject: NYT covers China cyberthreat In-Reply-To: Message-ID: The only spanking that has been going on nanog lately is Jay using his email to keep us up to date on current news. I am going to call it a night, and look for a SCUD fired from Florida in the morning. ;) On 2/20/13 11:29 PM, "Richard Porter" wrote: >When you really look at human behavior the thing that remains the same is >core motives. The competition makes sense in that it is human nature to >aggresse for resources. We are challenged in the "fact" that we 'want' to >belong among the other five. This will never change but????. > >What is really a travesty here is that most of us have been saying "hey >this is critical" and can now shift to "I told you so"? in that if you >did what we said to do 1 ? 5 ?. 10 ? years ago .. you would have >"mitigated" this risk.. > >Basically, genetically we have not changed, so what behavior would >suggest that (even with the introduction of faster calculators).. why >would we change? Just means we would do X faster ??. > >This is my first comment to the list.. please flame me privately to save >the list :) *** or publicly who think I should really be spanked!!! *** > > >Regards, >Richard > > > >On Feb 20, 2013, at 7:27 PM, Suresh Ramasubramanian >wrote: > >> Very true. The objection is more that the exploits are aimed at civilian >> rather than (or, more accurately, as well as) military / government / >> beltway targets. >> >> Which makes the alleged chinese strategy rather more like financing >>jehadis >> to suicide bomb and shoot up hotels and train stations, rather than any >> sort of disciplined warfare or espionage. >> >> --srs (htc one x) >> On 21-Feb-2013 7:40 AM, "Steven Bellovin" wrote: >> >>> >>> On Feb 20, 2013, at 1:33 PM, valdis.kletnieks at vt.edu wrote: >>> >>>> On Wed, 20 Feb 2013 15:39:42 +0900, Randy Bush said: >>>>> boys and girls, all the cyber-capable countries are cyber-culpable. >>>>>you >>>>> can bet that they are all snooping and attacking eachother, the >>>>>united >>>>> states no less than the rest. news at eleven. >>>> >>>> The scary part is that so many things got hacked by a bunch of people >>>> who made the totally noob mistake of launching all their attacks from >>>> the same place.... >>> >>> >>> This strongly suggests that it's not their A-team, for whatever value >>>of >>> "their" you prefer. (My favorite mistake was some of them updating >>>their >>> Facebook pages when their work took them outside the Great Firewall.) >>>They >>> just don't show much in the way of good operational security. >>> >>> Aside: A few years ago, a non-US friend of mine mentioned a >>>conversation >>> he'd had with a cyber guy from his own country's military. According >>>to >>> this guy, about 130 countries had active military cyberwarfare units. >>>I >>> don't suppose that the likes of Ruritania has one, but I think it's a >>>safe >>> assumption that more or less every first and second world country, and >>>not >>> a few third world ones are in the list. >>> >>> The claim here is not not that China is engaging in cyberespionage. >>>That >>> would go under the heading of "I'm shocked, shocked to find that >>>there's >>> spying going on here." Rather, the issue that's being raised is the >>>target: >>> commercial firms, rather than the usual military and government >>>secrets. >>> That is what the US is saying goes beyond the usual rules of the game. >>> In >>> fact, the US has blamed not just China but also Russia, France, and >>>Israel >>> (see http://www.israelnationalnews.com/News/News.aspx/165108 -- and >>>note >>> that that's an Israeli news site) for such activities. France was >>> notorious >>> for that in the 1990s; there were many press reports of bugged first >>>class >>> seats on Air France, for example. >>> >>> The term for what's going on is "cyberexploitation", as opposed to >>> "cyberwar". >>> The US has never come out against it in principle, though it never >>>likes it >>> when aimed at the US. (Every other nation feels the same way about its >>> companies and networks, of course.) For a good analysis of the legal >>> aspects, >>> see >>> >>>http://www.lawfareblog.com/2011/08/what-is-the-government%E2%80%99s-stra >>>tegy-for-the-cyber-exploitation-threat/ >>> >>> >>> >>> >>> --Steve Bellovin, https://www.cs.columbia.edu/~smb >>> >>> >>> >>> >>> >>> >>> > > > From ops.lists at gmail.com Thu Feb 21 07:47:44 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 21 Feb 2013 13:17:44 +0530 Subject: NYT covers China cyberthreat In-Reply-To: References: Message-ID: On Thursday, February 21, 2013, Warren Bailey wrote: > The only spanking that has been going on nanog lately is Jay using his > email to keep us up to date on current news. I am going to call it a > night, and look for a SCUD fired from Florida in the morning. ;) > > Nanog setting their list server up to mandate that envelope from matches header from should take care of this .. I see the envelope being whatever, nobody at server.example.com type stuff more often than not, in all these forwarded articles that are supposed to be coming from Jay's account. --srs -- --srs (iPad) From calin.chiorean at secdisk.net Thu Feb 21 08:28:32 2013 From: calin.chiorean at secdisk.net (calin.chiorean) Date: Thu, 21 Feb 2013 09:28:32 +0100 Subject: NYT covers China cyberthreat In-Reply-To: <20130220162948.87B4F422@m0005297.ppops.net> References: <20130220162948.87B4F422@m0005297.ppops.net> Message-ID: <680428915.440216.1361435312222.JavaMail.sas1@[172.29.249.242]> ::This all seems to be noobie stuff. There's nothing technically cool ::to see here You mean the report or the activity? You seem "upset" that they are using M$ only(target and source). They steal data!!! From whom to steal? From a guru that spend minimum 8 hours a day in from of *nix? Why to put so much effort to steal information from that guy, when there are thousands of people out there with vulnerable and easy to break M$. They aren't looking to do something cool, but just a regular, plain old thief stuff. Targeting M$ users if easy, involve less resources and it's "business" profitable. You need to look at this action from business perspective. IMO, why to spend hours to break something (like *nix systems) that you don't even know if it contains valuable information. This is more like sniffing around to find something useful and not targeting exact system. Somebody here mentioned that this unit is not their top unit. I'm sure that it's not. Maybe it was meant to be found. Cheers, Calin ---- On Thu, 21 Feb 2013 01:29:48 +0100 Scott Weeks wrote ---- > > >--- Valdis.Kletnieks at vt.edu wrote: >The scary part is that so many things got hacked by a bunch of people >who made the totally noob mistake of launching all their attacks from >the same place.... >------------------------------------------------ > > >This all seems to be noobie stuff. There's nothing technically cool >to see here. All they do is spear phishing and, once the link is >clicked, put in a backdoor that uses commonly available tools. As >I suspected earlier it's M$ against M$ only. > >The downside is nontechnical folks in positions of power often have >sensitive data on their computers, only know M$ and don't have the >knowledge to don't click on that "bank" email. > >Technically, it was 74 pages of yawn. Don't waste your time unless >you're interested in how they found out where the attack was >originating from and how they tied it to the .cn gov't. > >scott > > From kyle.creyts at gmail.com Thu Feb 21 10:25:54 2013 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Thu, 21 Feb 2013 02:25:54 -0800 Subject: NYT covers China cyberthreat In-Reply-To: <680428915.440216.1361435312222.JavaMail.sas1@172.29.249.242> References: <20130220162948.87B4F422@m0005297.ppops.net> <680428915.440216.1361435312222.JavaMail.sas1@172.29.249.242> Message-ID: The focus on platform here is ridiculous; can someone explain how platform of attacker or target is extremely relevant? Since when did people fail to see that we have plenty of inter-platform tools and services, and plenty of tools for either platform built with the express purpose of interaction with the other? Just because you learned to code/operate on/for/with/from a *nix doesn't mean that teams of Chinese coders can't make a tool that gets the job done on/for/with/from a Windows box. Many people write many softwares of diverse purpose and use for many platforms. Platform is, as far as I can tell, moot in this discussion. Feel free to enlighten me. Consider the US's indignation over the targeting of civillian or corporate intellectual property and the shifting of reality from preconceived expectation. I have had it explained to me as a purely ideological difference between the US and China. Simply put: just because we might find it immoral for state-sponsored espionage to feed stolen IP into the private sector, doesn't mean that China will feel the same; to some, it is perceived as nationalistic, another way the government helps to strengthen the nation. For another example of this, an acquaintance once told me about the process of getting internationally standardized technologies approved for deployment in China; the process that was described to me involved giving China the standards-based spec that had been drafted and approved, being told that for deployment, they would have to improve upon it in a laundry list of ways to bring it some 5-10 years ahead of the spec, and THEN it would be allowed to be deployed. Whenever you have enough new players, or the game goes on long enough, the rules end up changing. On Thu, Feb 21, 2013 at 12:28 AM, calin.chiorean wrote: > > ::This all seems to be noobie stuff. There's nothing technically cool > ::to see here > > You mean the report or the activity? > > You seem "upset" that they are using M$ only(target and source). They steal data!!! From whom to steal? From a guru that spend minimum 8 hours a day in from of *nix? > Why to put so much effort to steal information from that guy, when there are thousands of people out there with vulnerable and easy to break M$. > > They aren't looking to do something cool, but just a regular, plain old thief stuff. Targeting M$ users if easy, involve less resources and it's "business" profitable. You need to look at this action from business perspective. > > IMO, why to spend hours to break something (like *nix systems) that you don't even know if it contains valuable information. This is more like sniffing around to find something useful and not targeting exact system. > > Somebody here mentioned that this unit is not their top unit. I'm sure that it's not. Maybe it was meant to be found. > > Cheers, > Calin > > > ---- On Thu, 21 Feb 2013 01:29:48 +0100 Scott Weeks wrote ---- > >> >> >>--- Valdis.Kletnieks at vt.edu wrote: >>The scary part is that so many things got hacked by a bunch of people >>who made the totally noob mistake of launching all their attacks from >>the same place.... >>------------------------------------------------ >> >> >>This all seems to be noobie stuff. There's nothing technically cool >>to see here. All they do is spear phishing and, once the link is >>clicked, put in a backdoor that uses commonly available tools. As >>I suspected earlier it's M$ against M$ only. >> >>The downside is nontechnical folks in positions of power often have >>sensitive data on their computers, only know M$ and don't have the >>knowledge to don't click on that "bank" email. >> >>Technically, it was 74 pages of yawn. Don't waste your time unless >>you're interested in how they found out where the attack was >>originating from and how they tied it to the .cn gov't. >> >>scott >> >> > > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From stephen at sprunk.org Thu Feb 21 11:35:26 2013 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 21 Feb 2013 05:35:26 -0600 Subject: NYT covers China cyberthreat In-Reply-To: References: <20130220162948.87B4F422@m0005297.ppops.net> <680428915.440216.1361435312222.JavaMail.sas1@172.29.249.242> Message-ID: <5126067E.8050202@sprunk.org> On 21-Feb-13 04:25, Kyle Creyts wrote: > For another example of this, an acquaintance once told me about the process of getting internationally standardized technologies approved for deployment in China; the process that was described to me involved giving China the standards-based spec that had been drafted and approved, being told that for deployment, they would have to improve upon it in a laundry list of ways to bring it some 5-10 years ahead of the spec, and THEN it would be allowed to be deployed. My recent experience doing exactly this at $EMPLOYER doesn't match this story at all. The main problem, as with several other "second world" countries, is that the standards you must comply with are only in the local language and you must make your submission in the local language as well. However, if you have a local technical presence, you can often get software approval (or a formal notice of exemption--even for products that contain "dangerous" features like encryption) in a matter of days or even hours. If you don't, it can drag on for months. Hardware testing can be even worse because it must be performed in their labs and can cost tens of thousands of dollars, but at least that doesn't have to be repeated each time you publish a new version of code. In contrast, "first world" countries generally publish their standards in, and accept submissions in, English. They also tend not to care about software features, just hardware. The standards tend to be shared across countries (eg. EU/EFTA and US/Canada), or at least they accept test results from third-party labs that can test for all such countries at the same time. As a result, many vendors simply don't bother going past that group--or do it so infrequently that they don't gain the institutional knowledge of how to navigate the approval processes in the other group successfully and with minimal effort/cost. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2381 bytes Desc: S/MIME Cryptographic Signature URL: From mfidelman at meetinghouse.net Thu Feb 21 12:23:46 2013 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 21 Feb 2013 07:23:46 -0500 Subject: NYT covers China cyberthreat In-Reply-To: <20130220113420.87B4C842@m0005297.ppops.net> References: <20130220113420.87B4C842@m0005297.ppops.net> Message-ID: <512611D2.7040700@meetinghouse.net> Scott Weeks wrote: > Be sure to read the source: > > intelreport.mandiant.com/Mandiant_APT1_Report.pdf Anybody happen to notice that the report sounds awfully like the scenario laid out in Tom Clancy's latest book, "Threat Vector?" -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From rsk at gsp.org Thu Feb 21 16:00:24 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 21 Feb 2013 11:00:24 -0500 Subject: NYT covers China cyberthreat In-Reply-To: References: <20130220162948.87B4F422@m0005297.ppops.net> Message-ID: <20130221160024.GA19523@gsp.org> On Thu, Feb 21, 2013 at 01:34:13AM +0000, Warren Bailey wrote: > I can't help but wonder what would happen if US Corporations simply > blocked all inbound Chinese traffic. Sure it would hurt their business, > but imagine what the Chinese people would do in response. Would it hurt their business? Really? Well, if they're eBay, probably. If they're Joe's Fill Dirt and Croissants in Omaha, then probably not, because nobody, NOBODY in China is ever actually going to purchase a truckload of dirt or a tasty croissant from Joe. So would it actually matter if they couldn't get to Joe's web site or Joe's mail server or especially Joe's VPN server? Probably not. Nobody in Peru, Egypt, or Romania is likely to be buying from Joe any time soon either. This is why I've been using geoblocking at the network and host levels for over a decade, and it works. But it does require that you make an effort to study and understand your own traffic patterns as well as your organizational requirements. [1] I use it on a country-by-country basis (thank you ipdeny.com) and on a service-by-service basis: a particular host might allow http from anywhere, but ssh only from the country it's in. I also deny selected networks access to selected services, e.g., Amazon's cloud doesn't get access to port 25 because of the non-stop spam and Amazon's refusal to do anything about it. Anything on the Spamhaus DROP or EDROP lists (thank you Spamhaus) is not part of my view of the Internet. And so on. Combined, all this achieves lossless compression of abusive traffic. This is not a security fix, per se; any services that are vulnerable are still vulnerable. But it does cut down on the attack surface as measured along one axis, which in turn reduces the scope of some problems and renders them more tractable to other approaches. An even better approach, when appropriate, is to block everything and then only enable access selectively. This is a particularly good idea when defending things like ssh. Do you *really* need to allow incoming ssh from the entire planet? Or could "the US, Canada, the UK and Germany" suffice? If so, then why aren't you enforcing that? Do you really think it's a good idea to give someone with a 15-million member global botnet 3 or 5 or 10 brute-force attempts *per bot* before fail2ban or similar kicks in? I don't. I think 0 attempts per most bots is a much better idea. Let 'em eat packet drops while they try to figure out which subset of bots can even *reach* your ssh server. Which brings me to the NYTimes, and the alleged hacking by the Chinese. Why, given that the NYTimes apparently handed wads of cash over to various consulting firms, did none of those firms get the NYTimes to make a first-order attempt at solving this problem? Why in the world was anything in their corporate infrastructure accessible from the 2410 networks and 143,067,136 IP addresses in China? Who signed off on THAT? (Yes, yes, I *know* that the NYTimes has staff there, some permanently and some transiently. A one-off solution crafted for this use case would suffice. I've done it. It's not hard. And I doubt that it would need to work for more than, what, a few dozen of the NYTimes' 7500 employees? Clone and customize for Rio, Paris, Moscow, and other locations. This isn't hard either. Oh, and lock it out of everything that a field reporter/editor/photographer doesn't need, e.g., there is absolutely no way someone coming in through one of those should be able to reach the subscriber database.) Two more notes: first, blocking inbound traffic is usually not enough. Blocks should almost always be bidirectional. [2] This is especially important for things like the DROP/EDROP lists, because then spam payloads, phishes, malware, etc. won't be able to phone home quite so readily, and while your users will still be able to click on links that lead to bad things...they won't get there. Second, this may sound complex. It's not. I handle my needs with make, rsync, a little shell, a little perl, and other similar tools, but clearly you could do the same thing with any system configuration management setup. And with proper logging, it's not hard to discover the mistakes and edge cases, to apply suitable fixes and temporary point exceptions, and so on. ---rsk [1] 'Now, your typical IT executive, when I discuss this concept with him or her, will stand up and say something like, "That sounds great, but our enterprise network is really complicated. Knowing about all the different apps that we rely on would be impossible! What you're saying sounds reasonable until you think about it and realize how absurd it is!" To which I respond, "How can you call yourself a 'Chief Technology Officer' if you have no idea what your technology is doing?" A CTO isn't going to know detail about every application on the network, but if you haven't got a vague idea what's going on it's impossible to do capacity planning, disaster planning, security planning, or virtually any of the things in a CTO's charter.' --- Marcus Ranum [2] "We were so concerned with getting out that we never stopped to consider what we might be letting in, until it was too late." Let's see who recognizes that one. ;-) From jbates at brightok.net Thu Feb 21 16:23:20 2013 From: jbates at brightok.net (Jack Bates) Date: Thu, 21 Feb 2013 10:23:20 -0600 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: <20130220220341.FAFFAADA@m0005297.ppops.net> References: <20130220220341.FAFFAADA@m0005297.ppops.net> Message-ID: <512649F8.5000303@brightok.net> On 2/21/2013 12:03 AM, Scott Weeks wrote: > I would sure be interested in hearing about hands-on operational > experiences with encryptors. Recent experiences have left me > with a sour taste in my mouth. blech! > > scott > > Agreed. I've generally skipped the line side and stuck with L3 side encryption for the same reason. Jack From morrowc.lists at gmail.com Thu Feb 21 16:35:03 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 21 Feb 2013 11:35:03 -0500 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) In-Reply-To: <512649F8.5000303@brightok.net> References: <20130220220341.FAFFAADA@m0005297.ppops.net> <512649F8.5000303@brightok.net> Message-ID: On Thu, Feb 21, 2013 at 11:23 AM, Jack Bates wrote: > On 2/21/2013 12:03 AM, Scott Weeks wrote: >> >> I would sure be interested in hearing about hands-on operational >> experiences with encryptors. Recent experiences have left me >> with a sour taste in my mouth. blech! >> >> scott >> >> > > Agreed. I've generally skipped the line side and stuck with L3 side > encryption for the same reason. and... some (most?) line-side encryptors light the line up fullspeed between the encryptors... if they are also attempting to suppress traffic analysis... so that can be costly if you don't own the whole pipe :) From wbailey at satelliteintelligencegroup.com Thu Feb 21 16:41:42 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Thu, 21 Feb 2013 16:41:42 +0000 Subject: Network security on multiple levels (was Re: NYT covers China cyberthreat) Message-ID: Not to mention, the KG units are dot government only.. For obvious reasons. From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Christopher Morrow Date: 02/21/2013 8:37 AM (GMT-08:00) To: Jack Bates Cc: nanog at nanog.org Subject: Re: Network security on multiple levels (was Re: NYT covers China cyberthreat) On Thu, Feb 21, 2013 at 11:23 AM, Jack Bates wrote: > On 2/21/2013 12:03 AM, Scott Weeks wrote: >> >> I would sure be interested in hearing about hands-on operational >> experiences with encryptors. Recent experiences have left me >> with a sour taste in my mouth. blech! >> >> scott >> >> > > Agreed. I've generally skipped the line side and stuck with L3 side > encryption for the same reason. and... some (most?) line-side encryptors light the line up fullspeed between the encryptors... if they are also attempting to suppress traffic analysis... so that can be costly if you don't own the whole pipe :) From SNaslund at medline.com Thu Feb 21 17:47:44 2013 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 21 Feb 2013 11:47:44 -0600 Subject: NYT covers China cyberthreat In-Reply-To: <20130221160024.GA19523@gsp.org> References: <20130220162948.87B4F422@m0005297.ppops.net> <20130221160024.GA19523@gsp.org> Message-ID: <2A76E400AC84B845AAC35AA19F8E7A5D0E81134F@MUNEXBE1.medline.com> > I can't help but wonder what would happen if US Corporations simply > blocked all inbound Chinese traffic. Sure it would hurt their > business, but imagine what the Chinese people would do in response First thing is the Chinese government would rejoice since they don't want their citizens on our networks (except the ones they recruit for cyber warfare, they can get other address ranges for those guys). Second thing is someone will make a ton of money bouncing Chinese traffic through somewhere else (and someone will create a SPAMHAUS like service to detect that, and so on, and so on, and so on) Third thing is all the companies that do business in and around China would be screaming because tons of them use VPNs that are sourced from Chinese IP address space. Some people even like to travel and access things back home, you know weird stuff, like email, news, music, videos. One of the biggest problems with geoblocking is that often the addresses do not reveal the true source of the traffic. If you block everything from China, you miss attacks sourced from China that are bouncing through bot networks with hosts worldwide. Remember Tor, it is built to defeat just that sort of security by obscuring source locations. Corporations also often have egress points to the Internet in countries other than the one the user is in. If you block everything from China, then you are locking out any of your own personnel that travel Internationally or any of your customers that travel. Who here has not surfed the web from a hotel room on business. Anyone with malicious intent has a zillion ways to bypass that sort of security. Obscuring your source address is child's play. The management of the geoblocking will not be worth the minimal protection it provides. Trying to locate someone by address is a complete PITA in my opinion. If you go to Europe you will often get sent to the wrong Google sites because they attempt to locate you instead of just letting you put in the correct URL (if you are in the UK, it is not that hard to include .co.uk in your URL. I have been in the UK and gotten Google Germany and Google Spain for no apparent reason (except that carriers in Europe have addresses from all over the place because of mergers, alliances, and all sort of other arrangements). Blocking networks by service will also be a management nightmare since addresses often change and new blocks get assigned and companies offer different services. Who manages all of that and who is going to tell you when something changes (the answer is nobody, you will know when stuff breaks). If my network security guy had enough time to keep track of all of Amazon's address space and what services they are offering this week and all the services they host in their datacenters, I would fire him for having that much time on his hands. Can you keep track of all the stuff coming from Akamai and where all their servers are at on a continuing basis? Cloud services will make blocking by service nearly impossible since the network can reconfigure at any time. I would love to see this implementation in a large corporate or government network. What a huge game of whack a mole that is. Seems to me that the time would be much better spent tuning up firewalls and securing hosts properly. I think geoblocking gives you nothing but a false sense of security. I also believe that if you see an attack coming from China in particular it is because they WANT you to know it is coming from China. I would think any state sponsor conducting a very serious attack would conceal themselves better than that. I also believe that a lot of attacks that look like they are coming from China are actually coming from elsewhere. Think about this, if I am a hacker in the US, attacking a US victim, it would be a big advantage to look like I was coming from China because it almost guarantees no attempt to prosecute or track me down since everyone in this business knows that if it comes out of China you can't do anything about it. I would not be surprised to find out China is letting their capabilities be known just to remind everyone of what the implications of messing with them is. Remember Doctor Strangelove, "what good is a doomsday bomb if you don't tell anyone about it ?!?!?" Steven Naslund -----Original Message----- From: Rich Kulawiec [mailto:rsk at gsp.org] Sent: Thursday, February 21, 2013 10:00 AM To: nanog at nanog.org Subject: Re: NYT covers China cyberthreat On Thu, Feb 21, 2013 at 01:34:13AM +0000, Warren Bailey wrote: > I can't help but wonder what would happen if US Corporations simply > blocked all inbound Chinese traffic. Sure it would hurt their > business, but imagine what the Chinese people would do in response. Would it hurt their business? Really? Well, if they're eBay, probably. If they're Joe's Fill Dirt and Croissants in Omaha, then probably not, because nobody, NOBODY in China is ever actually going to purchase a truckload of dirt or a tasty croissant from Joe. So would it actually matter if they couldn't get to Joe's web site or Joe's mail server or especially Joe's VPN server? Probably not. Nobody in Peru, Egypt, or Romania is likely to be buying from Joe any time soon either. This is why I've been using geoblocking at the network and host levels for over a decade, and it works. But it does require that you make an effort to study and understand your own traffic patterns as well as your organizational requirements. [1] I use it on a country-by-country basis (thank you ipdeny.com) and on a service-by-service basis: a particular host might allow http from anywhere, but ssh only from the country it's in. I also deny selected networks access to selected services, e.g., Amazon's cloud doesn't get access to port 25 because of the non-stop spam and Amazon's refusal to do anything about it. Anything on the Spamhaus DROP or EDROP lists (thank you Spamhaus) is not part of my view of the Internet. And so on. Combined, all this achieves lossless compression of abusive traffic. This is not a security fix, per se; any services that are vulnerable are still vulnerable. But it does cut down on the attack surface as measured along one axis, which in turn reduces the scope of some problems and renders them more tractable to other approaches. An even better approach, when appropriate, is to block everything and then only enable access selectively. This is a particularly good idea when defending things like ssh. Do you *really* need to allow incoming ssh from the entire planet? Or could "the US, Canada, the UK and Germany" suffice? If so, then why aren't you enforcing that? Do you really think it's a good idea to give someone with a 15-million member global botnet 3 or 5 or 10 brute-force attempts *per bot* before fail2ban or similar kicks in? I don't. I think 0 attempts per most bots is a much better idea. Let 'em eat packet drops while they try to figure out which subset of bots can even *reach* your ssh server. Which brings me to the NYTimes, and the alleged hacking by the Chinese. Why, given that the NYTimes apparently handed wads of cash over to various consulting firms, did none of those firms get the NYTimes to make a first-order attempt at solving this problem? Why in the world was anything in their corporate infrastructure accessible from the 2410 networks and 143,067,136 IP addresses in China? Who signed off on THAT? (Yes, yes, I *know* that the NYTimes has staff there, some permanently and some transiently. A one-off solution crafted for this use case would suffice. I've done it. It's not hard. And I doubt that it would need to work for more than, what, a few dozen of the NYTimes' 7500 employees? Clone and customize for Rio, Paris, Moscow, and other locations. This isn't hard either. Oh, and lock it out of everything that a field reporter/editor/photographer doesn't need, e.g., there is absolutely no way someone coming in through one of those should be able to reach the subscriber database.) Two more notes: first, blocking inbound traffic is usually not enough. Blocks should almost always be bidirectional. [2] This is especially important for things like the DROP/EDROP lists, because then spam payloads, phishes, malware, etc. won't be able to phone home quite so readily, and while your users will still be able to click on links that lead to bad things...they won't get there. Second, this may sound complex. It's not. I handle my needs with make, rsync, a little shell, a little perl, and other similar tools, but clearly you could do the same thing with any system configuration management setup. And with proper logging, it's not hard to discover the mistakes and edge cases, to apply suitable fixes and temporary point exceptions, and so on. ---rsk [1] 'Now, your typical IT executive, when I discuss this concept with him or her, will stand up and say something like, "That sounds great, but our enterprise network is really complicated. Knowing about all the different apps that we rely on would be impossible! What you're saying sounds reasonable until you think about it and realize how absurd it is!" To which I respond, "How can you call yourself a 'Chief Technology Officer' if you have no idea what your technology is doing?" A CTO isn't going to know detail about every application on the network, but if you haven't got a vague idea what's going on it's impossible to do capacity planning, disaster planning, security planning, or virtually any of the things in a CTO's charter.' --- Marcus Ranum [2] "We were so concerned with getting out that we never stopped to consider what we might be letting in, until it was too late." Let's see who recognizes that one. ;-) From surfer at mauigateway.com Thu Feb 21 18:17:39 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 21 Feb 2013 10:17:39 -0800 Subject: NYT covers China cyberthreat Message-ID: <20130221101739.FB02AB0C@m0005299.ppops.net> --- calin.chiorean at secdisk.net wrote: From: "calin.chiorean" :: This all seems to be noobie stuff. There's nothing technically cool :: to see here >> You mean the report or the activity? The activity. >> You seem "upset" that they are using M$ only(target and >> source). I'm not upset. I'm pointing out what Steven Bellovin said in just a few words: "This strongly suggests that it's not their A-team..." This is a technical mailing list where cutting edge stuff is discussed. The compromise was not using cutting edge stuff and, so, is a big for this list. The report was mainly for reporters. That's why they had the omg sound byte bullet points at the top. It's also why they had to explain several low level things in detail. >> Maybe it was meant to be found. That is a definite possibility. scott From mfidelman at meetinghouse.net Thu Feb 21 18:39:13 2013 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Thu, 21 Feb 2013 13:39:13 -0500 Subject: NYT covers China cyberthreat In-Reply-To: <20130221101739.FB02AB0C@m0005299.ppops.net> References: <20130221101739.FB02AB0C@m0005299.ppops.net> Message-ID: <512669D1.9060507@meetinghouse.net> Scott Weeks wrote: > > --- calin.chiorean at secdisk.net wrote: > >>> You seem "upset" that they are using M$ only(target and >>> source). > I'm not upset. I'm pointing out what Steven Bellovin said > in just a few words: "This strongly suggests that it's not > their A-team..." > > This is a technical mailing list where cutting edge stuff > is discussed. The compromise was not using cutting edge > stuff and, so, is a big for this list. > Not to be pedantic, but I thought the list was about network operations - and as much (or more) about practice, than about "cutting edge stuff." (Well maybe a little pedantic.) From an operational point of view, unless I'm an exceptionally high-value target, I'm more likely to be threatened by the B-team (or C-team), than the A-team (recognizing, of course, that what the A-team is doing today, is what the script kiddies will be doing tomorrow). Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From surfer at mauigateway.com Thu Feb 21 19:11:17 2013 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 21 Feb 2013 11:11:17 -0800 Subject: NYT covers China cyberthreat Message-ID: <20130221111117.FB02A3F5@m0005299.ppops.net> --- kyle.creyts at gmail.com wrote: From: Kyle Creyts The focus on platform here is ridiculous; can someone explain how platform of attacker or target is extremely relevant? Since when did ---------------------------------------------- It implies their skillset. Here's something I just saw that says it better than I can... http://www.forbes.com/sites/andygreenberg/2013/02/21/the-shanghai-army-unit-that-hacked-115-u-s-targets-likely-wasnt-even-chinas-a-team/2/ scott From smb at cs.columbia.edu Thu Feb 21 20:05:33 2013 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 21 Feb 2013 15:05:33 -0500 Subject: NYT covers China cyberthreat In-Reply-To: <20C408D6-BDE1-4EDF-BE0A-F8E7DAE02633@cs.columbia.edu> References: <94bf868f-e631-49ca-b5c8-b1ed0f9333f2@email.android.com> <8031.1361385233@turing-police.cc.vt.edu> <20C408D6-BDE1-4EDF-BE0A-F8E7DAE02633@cs.columbia.edu> Message-ID: <0D12C797-ADF3-4002-BC70-8BC10FE29E4E@cs.columbia.edu> On Feb 20, 2013, at 9:07 PM, Steven Bellovin wrote: > > On Feb 20, 2013, at 1:33 PM, valdis.kletnieks at vt.edu wrote: > >> On Wed, 20 Feb 2013 15:39:42 +0900, Randy Bush said: >>> boys and girls, all the cyber-capable countries are cyber-culpable. you >>> can bet that they are all snooping and attacking eachother, the united >>> states no less than the rest. news at eleven. >> >> The scary part is that so many things got hacked by a bunch of people >> who made the totally noob mistake of launching all their attacks from >> the same place.... > > > This strongly suggests that it's not their A-team, for whatever value of > "their" you prefer. (My favorite mistake was some of them updating their > Facebook pages when their work took them outside the Great Firewall.) They > just don't show much in the way of good operational security. Mandiant apparently feels the same way: http://www.forbes.com/sites/andygreenberg/2013/02/21/the-shanghai-army-unit-that-hacked-115-u-s-targets-likely-wasnt-even-chinas-a-team/ --Steve Bellovin, https://www.cs.columbia.edu/~smb From Valdis.Kletnieks at vt.edu Thu Feb 21 20:55:20 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 21 Feb 2013 15:55:20 -0500 Subject: bgp for ipv6 question In-Reply-To: Your message of "Thu, 14 Feb 2013 13:18:24 -0800." <48BD6E36-A9B8-43E8-ACAE-86B97E4BE344@delong.com> References: <3DEBAB6A-63EA-48ED-B6FB-8CF30A920918@puck.nether.net> <1360875490.2832.1.camel@karl> <48BD6E36-A9B8-43E8-ACAE-86B97E4BE344@delong.com> Message-ID: <13982.1361480120@turing-police.cc.vt.edu> On Thu, 14 Feb 2013 13:18:24 -0800, Owen DeLong said: > On Feb 14, 2013, at 12:58 , Karl Auer wrote: > > On Thu, 2013-02-14 at 08:08 -0500, Jared Mauch wrote: > >> I recommend keeping your network as congruent between IPv4 and IPv6 as possible, with dual-stack. > > Why? > For one thing, doing otherwise violates the principle of least astonishment. Amen to that. Not too long ago, I blew about 3 hours trying to debug an odd networking issue on my laptop - finally tracked it down to the fact that my IPv4 default route was pointing out the ethernet on the docking station, but IPv6 was defaulting to the wireless card. Took a while because I knew *damned* well that Fedora had long ago included my patch to allow specifying a preference metric for multiple interfaces, and that I had set it to prefer the ethernet when both were connected. Turns out that the patch worked just fine for v4, but nobody ever carried it forward for v6.... (I probably should cook up a patch for the v6 side.. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jbates at brightok.net Thu Feb 21 20:58:25 2013 From: jbates at brightok.net (Jack Bates) Date: Thu, 21 Feb 2013 14:58:25 -0600 Subject: NYT covers China cyberthreat In-Reply-To: <20130221101739.FB02AB0C@m0005299.ppops.net> References: <20130221101739.FB02AB0C@m0005299.ppops.net> Message-ID: <51268A71.4080803@brightok.net> On 2/21/2013 12:17 PM, Scott Weeks wrote: > > I'm not upset. I'm pointing out what Steven Bellovin said > in just a few words: "This strongly suggests that it's not > their A-team..." > > The A-team doesn't get caught and detailed. The purpose of the other teams is to detect easy targets, handle easy jobs, and create lots of noise for the A-team to hide in. Hacking has always had a lot in common with magic. Misdirection is a useful tool. Jack From peter.phaal at gmail.com Thu Feb 21 21:04:11 2013 From: peter.phaal at gmail.com (Peter Phaal) Date: Thu, 21 Feb 2013 13:04:11 -0800 Subject: Anyone know of a good InfiniBand vendor in the US? In-Reply-To: References: <9137230821910144412@unknownmsgid> Message-ID: I wanted to bring attention to the following draft proposal from Mellanox to export traffic information from InfiniBand switches: http://sflow.org/draft_sflow_infiniband.txt If you are an InfiniBand user, this is a great opportunity to think about the types of metrics that you woud want from your switches in order to better understand performance. The operational sensibility that the NANOG audience brings is particularly valuable. Comments on the proposal are welcome on the sFlow discussion group: http://groups.google.com/group/sflow On Wed, Feb 20, 2013 at 2:25 PM, Tom Ammon wrote: > IPoIB looks more like an application than a network protocol to Infiniband. > The IB fabric doesn't have a concept of broadcast, so ARP works much > differently than it does in IPv4/ethernet world - basically an all-nodes > multicast group handles the distribution of ARP messages. That said, the ib > drivers that come with redhat/centos are pretty good, and you can always > download the official OFED drivers from the OFA at > https://www.openfabrics.org/linux-sources.html if the stuff in your linux > distribution is missing something. > > I've set up IPoIB routers running 10G NICs on the ethernet side and QDR > HCAs on the IB side, using quagga to plug in to the rest of my OSPF > network, and it works fine. Basically you just need to set up quagga like > you would if you were going to turn a linux box into an ethernet router and > don't worry about the fact that it's actually IB on one side of the router > - your network statements, etc., in OSPF in quagga won't change at all. > > You'll find that some things in IB have no equivalent to ethernet. For > example, if you want to have gateway redundancy for traffic exiting the IB > fabric, your first instinct will be to look for VRRP for IB, but you won't > find it, because of the ARP differences I talked about above. To get around > this you can set up linux-ha or some other type of heartbeat arrangement > and bring up a virtual IP on the active gateway, which can be shifted over > to the standby gateway when the ha scripts detect a problem. Some vendors > also have proprietary solutions to this problem but they tend to be > expensive. > > So, I'd say, read up on quagga and give that a try, and I think you'll find > that as long as the IB drivers are up to snuff (the sminfo command returns > valid results, etc.) it'll pretty much just work for you. I'm also happy to > discuss more offline if you prefer. > > Tom > > Tom > > > On Tue, Feb 19, 2013 at 5:55 PM, Jon Lewis wrote: > >> On Tue, 19 Feb 2013, Landon Stewart wrote: >> >> Oh by vendor I mean VAR I guess. Mostly I'm also wondering how an IB >>> network handles IPoIB and how one uses IB with a gateway to layer 3 >>> Ethernet switches or edge routers. If anyone has any resources that >>> provide details on how this works and how ethernet VLANs are handled I'd >>> appreciate it. >>> >> >> My limited IB experience has been that the IB switch acts much like a dumb >> ethernet switch, caring only about which IB hardware addresses are >> reachable via which port. Routing between IPoIB and IP over ethernet can >> be done by any host with interfaces on both networks and IP forwarding >> enabled. In our setups, we've used IPoIB, but with 1918 addresses and not >> routed beyond the IB network. >> >> ------------------------------**------------------------------**---------- >> Jon Lewis, MCP :) | I route >> Senior Network Engineer | therefore you are >> Atlantic Net | >> _________ http://www.lewis.org/~jlewis/**pgpfor PGP public key_________ >> >> > > > -- > ----------------------------------------------------------------------------- > Tom Ammon > Network Engineer > M: (801) 674-9273 > tom at tomsbox.net > ----------------------------------------------------------------------------- From randy at psg.com Thu Feb 21 22:11:31 2013 From: randy at psg.com (Randy Bush) Date: Fri, 22 Feb 2013 07:11:31 +0900 Subject: bird rib dump Message-ID: a friend trying to see if bird will be better than quagga for bgp recording can not see how to get rib dumps, as opposed to just updates. what are we missing? randy From reichert at numachi.com Thu Feb 21 22:55:40 2013 From: reichert at numachi.com (Brian Reichert) Date: Thu, 21 Feb 2013 17:55:40 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs Message-ID: <20130221225540.GA99258@numachi.com> I'm trying to nail down some terminology for doc purposes. The issue: most resources on the net freely describe a fully-qualified domian name ('FQDN') as to exclude the root domain; i.e, they exclude the trailing dot as mandated by some RFCs such as RFC 1535: http://www.ietf.org/rfc/rfc1535.txt An absolute "rooted" FQDN is of the format {name}{.} A non "rooted" domain name is of the format {name} I'm trying to come up with some human-facing terminology that names these two forms: "a.b.c." "a.b.c" Many resources on the net use the term 'rooted domain name' for the former, but they're collectively ambigious about what the other form should be called. Does anyone here have any solid advice, or can point me to a resource that would call out useful conventions? This was all fueled by Microsoft's client code apparently stripping the root domain from PTR record results; I'm separately trying to track down why that's occuring... -- Brian Reichert BSD admin/developer at large From ops.lists at gmail.com Fri Feb 22 00:41:21 2013 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 22 Feb 2013 06:11:21 +0530 Subject: NYT covers China cyberthreat In-Reply-To: <51268A71.4080803@brightok.net> References: <20130221101739.FB02AB0C@m0005299.ppops.net> <51268A71.4080803@brightok.net> Message-ID: And so their bush league by itself was responsible for all the penetrations that mandiant says they did? Which shows that they don't have to be particularly smart, just a bit smarter than their average spear phish or other attack's victim. On Friday, February 22, 2013, Jack Bates wrote: > On 2/21/2013 12:17 PM, Scott Weeks wrote: > >> >> I'm not upset. I'm pointing out what Steven Bellovin said >> in just a few words: "This strongly suggests that it's not >> their A-team..." >> >> >> > The A-team doesn't get caught and detailed. The purpose of the other teams > is to detect easy targets, handle easy jobs, and create lots of noise for > the A-team to hide in. Hacking has always had a lot in common with magic. > Misdirection is a useful tool. > > Jack > > -- --srs (iPad) From watanabe at mfeed.ad.jp Fri Feb 22 01:18:41 2013 From: watanabe at mfeed.ad.jp (Eiichiro Watanabe) Date: Fri, 22 Feb 2013 10:18:41 +0900 Subject: bird rib dump In-Reply-To: References: Message-ID: <5126C771.1010105@mfeed.ad.jp> bird supposedly doesn't support rib dumps at this time. Randy Bush wrote (2013/02/22 7:11): > a friend trying to see if bird will be better than quagga for bgp > recording can not see how to get rib dumps, as opposed to just updates. > what are we missing? > > randy > > > -- ################################################### Eiichiro Watanabe Internet Multifeed Co. e-mail: watanabe at mfeed.ad.jp From morrowc.lists at gmail.com Fri Feb 22 02:27:28 2013 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 21 Feb 2013 21:27:28 -0500 Subject: NYT covers China cyberthreat In-Reply-To: <51268A71.4080803@brightok.net> References: <20130221101739.FB02AB0C@m0005299.ppops.net> <51268A71.4080803@brightok.net> Message-ID: On Thu, Feb 21, 2013 at 3:58 PM, Jack Bates wrote: > The A-team doesn't get caught and detailed no, the A-team has BA Baraccus... he pities the fool who gets caught and detailed... the last thing BA detailed was his black van. From Valdis.Kletnieks at vt.edu Fri Feb 22 03:54:51 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 21 Feb 2013 22:54:51 -0500 Subject: NYT covers China cyberthreat In-Reply-To: Your message of "Fri, 22 Feb 2013 06:11:21 +0530." References: <20130221101739.FB02AB0C@m0005299.ppops.net> <51268A71.4080803@brightok.net> Message-ID: <4993.1361505291@turing-police.cc.vt.edu> On Fri, 22 Feb 2013 06:11:21 +0530, Suresh Ramasubramanian said: > And so their bush league by itself was responsible for all the penetrations > that mandiant says they did? Which shows that they don't have to be > particularly smart, just a bit smarter than their average spear phish or > other attack's victim. As I said - that's the scary part. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From marka at isc.org Fri Feb 22 05:57:42 2013 From: marka at isc.org (Mark Andrews) Date: Fri, 22 Feb 2013 16:57:42 +1100 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: Your message of "Thu, 21 Feb 2013 17:55:40 CDT." <20130221225540.GA99258@numachi.com> References: <20130221225540.GA99258@numachi.com> Message-ID: <20130222055742.DE65A2FF4D49@drugs.dv.isc.org> In message <20130221225540.GA99258 at numachi.com>, Brian Reichert writes: > I'm trying to nail down some terminology for doc purposes. > > The issue: most resources on the net freely describe a fully-qualified > domian name ('FQDN') as to exclude the root domain; i.e, they exclude > the trailing dot as mandated by some RFCs such as RFC 1535: RFC 1535 is Informational. It has no status to mandate anything. > http://www.ietf.org/rfc/rfc1535.txt > > An absolute "rooted" FQDN is of the format {name}{.} A non > "rooted" domain name is of the format {name} > > I'm trying to come up with some human-facing terminology that names > these two forms: > > "a.b.c." > "a.b.c" > > Many resources on the net use the term 'rooted domain name' for the > former, but they're collectively ambigious about what the other > form should be called. > > Does anyone here have any solid advice, or can point me to a resource > that would call out useful conventions? > > This was all fueled by Microsoft's client code apparently stripping > the root domain from PTR record results; I'm separately trying to > track down why that's occuring... RFC 952 as modified by RFC 1123 describe the legal syntax of a hostname. There is no trailing period. > -- > Brian Reichert > BSD admin/developer at large > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From kauer at biplane.com.au Fri Feb 22 06:19:03 2013 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 22 Feb 2013 17:19:03 +1100 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130222055742.DE65A2FF4D49@drugs.dv.isc.org> References: <20130221225540.GA99258@numachi.com> <20130222055742.DE65A2FF4D49@drugs.dv.isc.org> Message-ID: <1361513943.28479.437.camel@karl> On Fri, 2013-02-22 at 16:57 +1100, Mark Andrews wrote: > RFC 952 as modified by RFC 1123 describe the legal syntax of a hostname. > There is no trailing period. No - but a trailing period is a (common?) way to indicate that the name as given is complete, so in a lot of contexts a trailing period is at least not illegal, and is often usefully meaningful. The best example is inside zone files, where a trailing period indicates that the origin should not be appended. It's used (by the resolver library?) to indicate that any domain search suffixes should not be attempted. In Firefox (and probably other browsers) it indicates that the browser should not try common suffixes like ".com" if the hostname provided does not resolve. It's a convention common enough and useful enough that I can see why people would want a handy term for it. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 From kemp at network-services.uoregon.edu Fri Feb 22 08:56:20 2013 From: kemp at network-services.uoregon.edu (John Kemp) Date: Fri, 22 Feb 2013 00:56:20 -0800 Subject: bird rib dump In-Reply-To: <5126C771.1010105@mfeed.ad.jp> References: <5126C771.1010105@mfeed.ad.jp> Message-ID: <512732B4.9070400@network-services.uoregon.edu> Uh, I'm looking at this in the source below in sysdep/unix/log.c and it looks like it is there. I assume you want "mrtdump protocols messages" The manual for Global options it says this: mrtdump "filename" Set MRTdump file name. This option must be specified to allow MRTdump feature. Default: no dump file. mrtdump protocols all|off|{ states, messages } Set global defaults of MRTdump options. See mrtdump in the following section. Default: off. /jgk > 359 void > 360 mrt_dump_message(struct proto *p, u16 type, u16 subtype, byte > *buf, u32 len) > 361 { > 362 /* Prepare header */ > 363 put_u32(buf+0, now_real); > 364 put_u16(buf+4, type); > 365 put_u16(buf+6, subtype); > 366 put_u32(buf+8, len - MRTDUMP_HDR_LENGTH); > 367 > 368 if (p->cf->global->mrtdump_file != -1) > 369 write(p->cf->global->mrtdump_file, buf, len); > 370 } On 2/21/13 5:18 PM, Eiichiro Watanabe wrote: > bird supposedly doesn't support rib dumps at this time. > > Randy Bush wrote (2013/02/22 7:11): >> a friend trying to see if bird will be better than quagga for bgp >> recording can not see how to get rib dumps, as opposed to just updates. >> what are we missing? >> >> randy >> >> >> > > From kemp at network-services.uoregon.edu Fri Feb 22 09:22:17 2013 From: kemp at network-services.uoregon.edu (John Kemp) Date: Fri, 22 Feb 2013 01:22:17 -0800 Subject: bird rib dump In-Reply-To: <512732B4.9070400@network-services.uoregon.edu> References: <5126C771.1010105@mfeed.ad.jp> <512732B4.9070400@network-services.uoregon.edu> Message-ID: <512738C9.9000504@network-services.uoregon.edu> Ah, you said rib. Did look at the code a bit more. It looks like there is a "dump routes" command. Might try that. Here it says "birdc" can do some stuff... http://bird.network.cz/?get_doc&f=bird-4.html dump resources|sockets|interfaces|neighbors|attributes|routes|protocols and show route [[for] prefix|IP] [table sym] [filter f|where c] [(export|preexport) p] [protocol p] [options] /jgk On 2/22/13 12:56 AM, John Kemp wrote: > Uh, > > I'm looking at this in the source below in sysdep/unix/log.c > and it looks like it is there. I assume you want "mrtdump protocols > messages" > The manual for Global options it says this: > > mrtdump "filename" > Set MRTdump file name. This option must be specified to allow MRTdump > feature. Default: no dump file. > > mrtdump protocols all|off|{ states, messages } > Set global defaults of MRTdump options. See mrtdump in the following > section. Default: off. > > /jgk > >> 359 void >> 360 mrt_dump_message(struct proto *p, u16 type, u16 subtype, byte >> *buf, u32 len) >> 361 { >> 362 /* Prepare header */ >> 363 put_u32(buf+0, now_real); >> 364 put_u16(buf+4, type); >> 365 put_u16(buf+6, subtype); >> 366 put_u32(buf+8, len - MRTDUMP_HDR_LENGTH); >> 367 >> 368 if (p->cf->global->mrtdump_file != -1) >> 369 write(p->cf->global->mrtdump_file, buf, len); >> 370 } > > > > On 2/21/13 5:18 PM, Eiichiro Watanabe wrote: >> bird supposedly doesn't support rib dumps at this time. >> >> Randy Bush wrote (2013/02/22 7:11): >>> a friend trying to see if bird will be better than quagga for bgp >>> recording can not see how to get rib dumps, as opposed to just updates. >>> what are we missing? >>> >>> randy >>> >>> >>> >> > From oscar.vives at gmail.com Fri Feb 22 11:08:43 2013 From: oscar.vives at gmail.com ( .) Date: Fri, 22 Feb 2013 12:08:43 +0100 Subject: NYT covers China cyberthreat In-Reply-To: <51268A71.4080803@brightok.net> References: <20130221101739.FB02AB0C@m0005299.ppops.net> <51268A71.4080803@brightok.net> Message-ID: On 21 February 2013 21:58, Jack Bates wrote: ... > > The A-team doesn't get caught and detailed. The purpose of the other teams > is to detect easy targets, handle easy jobs, and create lots of noise for > the A-team to hide in. Hacking has always had a lot in common with magic. > Misdirection is a useful tool. > > Jack > Or theres only a B-team, and the china government is as corrupted and infective as the USA one. -- -- ?in del ?ensaje. From tvhawaii at shaka.com Fri Feb 22 05:14:47 2013 From: tvhawaii at shaka.com (Michael Painter) Date: Thu, 21 Feb 2013 19:14:47 -1000 Subject: NYT covers China cyberthreat References: <20130221101739.FB02AB0C@m0005299.ppops.net> <51268A71.4080803@brightok.net> <4993.1361505291@turing-police.cc.vt.edu> Message-ID: ----- Original Message ----- From: To: "Suresh Ramasubramanian" Cc: Sent: Thursday, February 21, 2013 5:54 PM Subject: Re: NYT covers China cyberthreat And since it's Wacky Friday somewhere: http://arstechnica.com/security/2013/02/how-anonymous-accidentally-helped-expose-two-chinese-hackers/ From jra at baylink.com Fri Feb 22 16:52:34 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 22 Feb 2013 11:52:34 -0500 (EST) Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130222055742.DE65A2FF4D49@drugs.dv.isc.org> Message-ID: <24339470.6878.1361551954109.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Andrews" > RFC 952 as modified by RFC 1123 describe the legal syntax of a > hostname. There is no trailing period. May someone create a "com" subdomain in a DNS domain you have to work in, Mark. Or *course* the trailing dot matters, even if only due to the behavior of DNS resolvers. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From fjblas at arcos.inf.uc3m.es Fri Feb 22 15:50:54 2013 From: fjblas at arcos.inf.uc3m.es (Javier Garcia Blas) Date: Fri, 22 Feb 2013 16:50:54 +0100 Subject: Call For Papers: EuroMPI 2013 co-located Workshops Message-ID: <20130222155054.GA29374@piojito.arcos.inf.uc3m.es> Dear Sir or Madam, (We apologize if you receive multiple copies of this message) ------------------------------------------------------------ Recent Advances in Message Passing Interface. 20th European MPI Users' Group Meeting (EuroMPI 2013) EuroMPI 2013 is being held in cooperation with SIGHPC Madrid, Spain, September 15-18, 2013 www.eurompi2013.org ================================================= WORKSHOPS ================================================= EuroMPI 2013 workshops are a major part of the EuroMPI week-long family of events. They provide the MPI community an opportunity to explore special topics, and the goal of the workshops is to present work that is more preliminary and cutting-edge or that has more practical content than the more mature research presented in the main conference. Proceedings of the workshops are published by the ACM Digital Library and are distributed at the conference. The workshops schedule by day will be announced when the full program of workshops is complete. IMUDI SPECIAL SESSION ON IMPROVING MPI USER AND DEVELOPER INTERACTION ===================================================================== The IMUDI special session, to be held as a full-day meeting at the EuroMPI 2013 conference in Madrid, Spain, focuses on bringing together the MPI end-user and MPI implementor communities through discussions on MPI usage experiences, techniques, and optimizations. This meeting will focus on evaluating the MPI standard from the perspective of the MPI end-user (application and library developers) and address concerns and insights of MPI implementors and vendors. Unlike workshops associated with other conferences, the IMUDI session is still considered to be a part of the Euro MPI conference. Submissions will be reviewed separately to facilitate bringing together research publications falling into these "special focus" areas. Important Dates --------------- Submission of full and short papers: March 29th, 2013. Author Notification: June 1st, 2013. Camera Ready papers due: June 15th, 2013. More info at: http://press.mcs.anl.gov/imudi/ E2HPC2 2013: ENERGY-EFFICIENT HIGH PERFORMANCE COMPUTING & COMMUNICATION WORKSHOP ================================================================================= The first Energy-Efficient High Performance Computing & Communication workshop will be co-located with EuroMPI 2013 in Madrid. Energy-awareness is now a main topic for HPC systems. The goal of this workshop is to discuss latest researches on the impact and possibles leverages of communications for such systems. E2HPC2 solicits original and non-published or under-review articles on the field of energy-aware communication in HPC environment. This workshop is co-located with EuroMPI as MPI is the main communication interface in those environments. Important Dates --------------- Submission of full papers: March 29th, 2013 Author notification: May 11th, 2013 Camera Ready papers due: June 15th, 2013 More info at: http://www.irit.fr/~Georges.Da-Costa/e2hpc2.html PBIO 2013: INTERNATIONAL WORKSHOP ON PARALLELISM IN BIOINFORMATICS ================================================================== In Bioinformatics, we can find a variety of problems which are affected by huge processing times and memory consumption, due to the large size of biological data sets and the inherent complexity of biological problems. In fact, Bioinformatics is one of the most exciting research areas in which Parallelism finds application. Successful examples are mpiBLAST or ClustalW-MPI, among many others. In conclusion, Bioinformatics allows and encourages the application of many different parallelism-based technologies. The focus of this workshop is on MPI-based approaches, but we welcome any technique based on: multicore and cluster computing, supercomputing, grid computing, cloud computing, hardware accelerators as GPUs, FPGAs, or Cell processors, etc. Important Dates --------------- Submission Deadline: March 29th, 2013 Acceptation Notification: May 11th, 2013 Camera-Ready Submission: June 15th, 2013 More info at: http://arco.unex.es/mavega/pbio2013/ ______________________________________________________________________________________________ From reichert at numachi.com Fri Feb 22 17:17:10 2013 From: reichert at numachi.com (Brian Reichert) Date: Fri, 22 Feb 2013 12:17:10 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <1361513943.28479.437.camel@karl> References: <20130221225540.GA99258@numachi.com> <20130222055742.DE65A2FF4D49@drugs.dv.isc.org> <1361513943.28479.437.camel@karl> Message-ID: <20130222171710.GB99258@numachi.com> On Fri, Feb 22, 2013 at 05:19:03PM +1100, Karl Auer wrote: > It's a convention common enough and useful enough that I can see why > people would want a handy term for it. The core issue I'm trying to resolve surrounds the generation of a CSR. We're trying automate this process for a network appliance my employer sells. When our appliance generates a CSR for itself, among the steps is to get a PTR record; by convention (or otherwise) these are rooted domain names. When we generate a CSR, we're choosing to include the rooted domain name, as well as the other form (for now, I guess it should be called a FQDN, the version without the trailing dot). The resulting issued certificate has both forms in the SubjectAltName field, and this allows both hostname forms to be used to establish an SSL connection to our server. They are considered distinct for the Subject verification phase. It's come to my attention that some commercial certificate vendors think that having multiple hostnames in the SAN list costs more money; go figure. Our customers then have to go through some soul-searching to pare down the list of hostnames in the SAN in the CSR. There's some understandable questions about why we include both forms, and whether or not they are necessary. We need to document our policies and recommendations, and I'm trying to establish the vocabulary. Hence my original question. Irrespective of the state of RFCs, there are competing conventions, and ambiguous terminology. And I was seeking guidance. :) I do appreciate the feedback provided thus far. > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) > http://www.biplane.com.au/kauer > http://www.biplane.com.au/blog -- Brian Reichert BSD admin/developer at large From jra at baylink.com Fri Feb 22 17:41:33 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 22 Feb 2013 12:41:33 -0500 (EST) Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130222171710.GB99258@numachi.com> Message-ID: <7446004.6892.1361554893925.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brian Reichert" > The core issue I'm trying to resolve surrounds the generation of a > CSR. We're trying automate this process for a network appliance > my employer sells. > > When our appliance generates a CSR for itself, among the steps is > to get a PTR record; by convention (or otherwise) these are rooted > domain names. > > When we generate a CSR, we're choosing to include the rooted domain > name, as well as the other form (for now, I guess it should be > called a FQDN, the version without the trailing dot). > > The resulting issued certificate has both forms in the SubjectAltName > field, and this allows both hostname forms to be used to establish > an SSL connection to our server. They are considered distinct for > the Subject verification phase. My snap reaction is to say that nothing should ever be *trying* to compare a rooted F.Q.D.N. against a certificate; it is, as has been noted, merely command line/entry field shorthand to tell the local resolver where to quit; applications should all be stripping that trailing dot. Do you have evidence that the extra AltName with the trailing dot is operationally necessary? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From asullivan at dyn.com Fri Feb 22 18:01:49 2013 From: asullivan at dyn.com (Andrew Sullivan) Date: Fri, 22 Feb 2013 13:01:49 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130222055742.DE65A2FF4D49@drugs.dv.isc.org> References: <20130221225540.GA99258@numachi.com> <20130222055742.DE65A2FF4D49@drugs.dv.isc.org> Message-ID: <20130222180149.GL455@dyn.com> On Fri, Feb 22, 2013 at 04:57:42PM +1100, Mark Andrews wrote: > > RFC 952 as modified by RFC 1123 describe the legal syntax of a hostname. > There is no trailing period. Mark is of course correct about this, but it doesn't fully help. The basic problem is (as always) the confusion about the difference between a hostname and a fully-qualified domain name, which so happens to be also a hostname. Whether we like it or not, this ambiguity is no longer something that can be resolved. What you have to do is know whether you are dealing with a hostname (no final dot, because the hostname syntax doesn't use it), a domain name relative to the root (no final dot, because implicitly you're not using the search path; it is nearly impossible to tell the difference between this and a host name), a domain name relative to something else, relying on your search path (bad, evil, and wrong, just stop it or you get what you deserve), or an actually fully-qualified domain name (final dot). The second of these is about to get harder to distinguish from the third, because of the new gTLD programme at ICANN. I wish there were a neat answer to the problem. There isn't. A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From jabley at hopcount.ca Fri Feb 22 18:07:40 2013 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 22 Feb 2013 14:07:40 -0400 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130222180149.GL455@dyn.com> References: <20130221225540.GA99258@numachi.com> <20130222055742.DE65A2FF4D49@drugs.dv.isc.org> <20130222180149.GL455@dyn.com> Message-ID: <668253EE-8629-4A87-9205-4064534D3C33@hopcount.ca> On 2013-02-22, at 14:01, Andrew Sullivan wrote: > On Fri, Feb 22, 2013 at 04:57:42PM +1100, Mark Andrews wrote: >> >> RFC 952 as modified by RFC 1123 describe the legal syntax of a hostname. >> There is no trailing period. > > Mark is of course correct about this, but it doesn't fully help. > > The basic problem is (as always) the confusion about the difference > between a hostname and a fully-qualified domain name, which so happens > to be also a hostname. Actually, I think the problem is the confusion between a label string terminated in a dot (to indicate that no search domain should be appended) and a label string not so-terminated (which might mean that a search domain is attempted, depending on local configuration). There is no simple terminology to distinguish between the two cases that I am aware of. I think the original question's context was how to format a CN in a CSR. I believe the most useful answer is "single CN, fully-qualified domain name with no trailing dot". The terminology "root zone" or "root domain" to explain the trailing dot is misleading and unhelpful, I find. Joe From jra at baylink.com Fri Feb 22 18:20:57 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 22 Feb 2013 13:20:57 -0500 (EST) Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <668253EE-8629-4A87-9205-4064534D3C33@hopcount.ca> Message-ID: <30463315.6898.1361557257187.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joe Abley" > Actually, I think the problem is the confusion between a label string > terminated in a dot (to indicate that no search domain should be > appended) and a label string not so-terminated (which might mean that > a search domain is attempted, depending on local configuration). In fact, Joe, I think it's distinguishing your second case from "a label string which is intended to reference a rooted FQDN, but the user did not specify the trailing dot -- and yet still does not want a search path applied"... which is 99.9999% of the time outside of large corporate and college campuses, and only 99.9% of the time, otherwise. :-) > The terminology "root zone" or "root domain" to explain the trailing > dot is misleading and unhelpful, I find. No, what's *really* unhelpful and misleading is the people who say that it is the *dot* which specifies the name of the root, rather than the null labelstring which *follows* that dot (which is what it actually is, and I'll save everyone's stomach linings by not saying the words "alternate root" here. :-) Cheers, -- jr 'new intercalations on every message for authentication' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jabley at hopcount.ca Fri Feb 22 18:25:13 2013 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 22 Feb 2013 14:25:13 -0400 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <30463315.6898.1361557257187.JavaMail.root@benjamin.baylink.com> References: <30463315.6898.1361557257187.JavaMail.root@benjamin.baylink.com> Message-ID: <4229AA2A-1735-4E2B-9739-89A364610C89@hopcount.ca> Jay, On 2013-02-22, at 14:20, Jay Ashworth wrote: >> Actually, I think the problem is the confusion between a label string >> terminated in a dot (to indicate that no search domain should be >> appended) and a label string not so-terminated (which might mean that >> a search domain is attempted, depending on local configuration). > > In fact, Joe, I think it's distinguishing your second case from "a label > string which is intended to reference a rooted FQDN, but the user did not > specify the trailing dot -- and yet still does not want a search path > applied"... That's the same as my second case. "rooted FQDN" is also not well-defined outside this thread. I don't think just adopting the terminology unilaterally is going to make it so. >> The terminology "root zone" or "root domain" to explain the trailing >> dot is misleading and unhelpful, I find. > > No, what's *really* unhelpful and misleading is the people who say that > it is the *dot* which specifies the name of the root, The dot doesn't specify the name of the root. That's why it's confusing. > rather than the > null labelstring which *follows* that dot (which is what it actually > is, and I'll save everyone's stomach linings by not saying the words > "alternate root" here. :-) There is no null label string following the dot in a fully-qualified domain name, in this context. You're confusing the presentation of domain names with wire-format encoding of domain names. Joe From cscora at apnic.net Fri Feb 22 18:32:57 2013 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 Feb 2013 04:32:57 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201302221832.r1MIWvl7012215@thyme.rand.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 23 Feb, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 443622 Prefixes after maximum aggregation: 182606 Deaggregation factor: 2.43 Unique aggregates announced to Internet: 218011 Total ASes present in the Internet Routing Table: 43375 Prefixes per ASN: 10.23 Origin-only ASes present in the Internet Routing Table: 34205 Origin ASes announcing only one prefix: 15949 Transit ASes present in the Internet Routing Table: 5771 Transit-only ASes present in the Internet Routing Table: 136 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 30 Max AS path prepend of ASN ( 28730) 25 Prefixes from unregistered ASNs in the Routing Table: 387 Unregistered ASNs in the Routing Table: 144 Number of 32-bit ASNs allocated by the RIRs: 3775 Number of 32-bit ASNs visible in the Routing Table: 3399 Prefixes from 32-bit ASNs in the Routing Table: 9376 Special use prefixes present in the Routing Table: 17 Prefixes being announced from unallocated address space: 190 Number of addresses announced to Internet: 2617460108 Equivalent to 156 /8s, 3 /16s and 69 /24s Percentage of available address space announced: 70.7 Percentage of allocated address space announced: 70.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.3 Total number of prefixes smaller than registry allocations: 156638 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 106390 Total APNIC prefixes after maximum aggregation: 33025 APNIC Deaggregation factor: 3.22 Prefixes being announced from the APNIC address blocks: 107470 Unique aggregates announced from the APNIC address blocks: 43851 APNIC Region origin ASes present in the Internet Routing Table: 4811 APNIC Prefixes per ASN: 22.34 APNIC Region origin ASes announcing only one prefix: 1235 APNIC Region transit ASes present in the Internet Routing Table: 815 Average APNIC Region AS path length visible: 4.6 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table: 432 Number of APNIC addresses announced to Internet: 718525056 Equivalent to 42 /8s, 211 /16s and 210 /24s Percentage of available APNIC address space announced: 84.0 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 156143 Total ARIN prefixes after maximum aggregation: 79021 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 156769 Unique aggregates announced from the ARIN address blocks: 71334 ARIN Region origin ASes present in the Internet Routing Table: 15482 ARIN Prefixes per ASN: 10.13 ARIN Region origin ASes announcing only one prefix: 5853 ARIN Region transit ASes present in the Internet Routing Table: 1610 Average ARIN Region AS path length visible: 4.1 Max ARIN Region AS path length visible: 27 Number of ARIN region 32-bit ASNs visible in the Routing Table: 18 Number of ARIN addresses announced to Internet: 1076416640 Equivalent to 64 /8s, 40 /16s and 208 /24s Percentage of available ARIN address space announced: 56.9 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 23/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 53/8, 54/8, 55/8, 56/8, 57/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 100/8, 104/8, 107/8, 108/8, 128/8, 129/8, 130/8, 131/8, 132/8, 134/8, 135/8, 136/8, 137/8, 138/8, 139/8, 140/8, 142/8, 143/8, 144/8, 146/8, 147/8, 148/8, 149/8, 152/8, 155/8, 156/8, 157/8, 158/8, 159/8, 160/8, 161/8, 162/8, 164/8, 165/8, 166/8, 167/8, 168/8, 169/8, 170/8, 172/8, 173/8, 174/8, 184/8, 192/8, 198/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 113911 Total RIPE prefixes after maximum aggregation: 58893 RIPE Deaggregation factor: 1.93 Prefixes being announced from the RIPE address blocks: 117124 Unique aggregates announced from the RIPE address blocks: 75274 RIPE Region origin ASes present in the Internet Routing Table: 17078 RIPE Prefixes per ASN: 6.86 RIPE Region origin ASes announcing only one prefix: 8146 RIPE Region transit ASes present in the Internet Routing Table: 2779 Average RIPE Region AS path length visible: 5.0 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 2197 Number of RIPE addresses announced to Internet: 653652580 Equivalent to 38 /8s, 245 /16s and 242 /24s Percentage of available RIPE address space announced: 95.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 196608-199679 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 141/8, 145/8, 151/8, 176/8, 178/8, 185/8, 188/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 47067 Total LACNIC prefixes after maximum aggregation: 9148 LACNIC Deaggregation factor: 5.15 Prefixes being announced from the LACNIC address blocks: 50872 Unique aggregates announced from the LACNIC address blocks: 23614 LACNIC Region origin ASes present in the Internet Routing Table: 1831 LACNIC Prefixes per ASN: 27.78 LACNIC Region origin ASes announcing only one prefix: 532 LACNIC Region transit ASes present in the Internet Routing Table: 345 Average LACNIC Region AS path length visible: 4.8 Max LACNIC Region AS path length visible: 27 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 745 Number of LACNIC addresses announced to Internet: 123295272 Equivalent to 7 /8s, 89 /16s and 86 /24s Percentage of available LACNIC address space announced: 73.5 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8, 191/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 10595 Total AfriNIC prefixes after maximum aggregation: 2461 AfriNIC Deaggregation factor: 4.31 Prefixes being announced from the AfriNIC address blocks: 11197 Unique aggregates announced from the AfriNIC address blocks: 3767 AfriNIC Region origin ASes present in the Internet Routing Table: 602 AfriNIC Prefixes per ASN: 18.60 AfriNIC Region origin ASes announcing only one prefix: 183 AfriNIC Region transit ASes present in the Internet Routing Table: 131 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 25 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 7 Number of AfriNIC addresses announced to Internet: 45216512 Equivalent to 2 /8s, 177 /16s and 243 /24s Percentage of available AfriNIC address space announced: 44.9 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 154/8, 196/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2936 11558 925 Korea Telecom (KIX) 17974 2495 824 85 PT TELEKOMUNIKASI INDONESIA 7545 1827 301 89 TPG Internet Pty Ltd 4755 1692 382 189 TATA Communications formerly 9829 1424 1140 43 BSNL National Internet Backbo 9583 1207 90 499 Sify Limited 7552 1161 1070 12 Vietel Corporation 4808 1116 2057 321 CNCGROUP IP network: China169 9498 1063 310 75 BHARTI Airtel Ltd. 24560 1047 385 160 Bharti Airtel Ltd., Telemedia Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3057 3695 98 bellsouth.net, inc. 7029 2168 1265 210 Windstream Communications Inc 18566 2080 382 185 Covad Communications 22773 1991 2931 127 Cox Communications, Inc. 1785 1960 677 125 PaeTec Communications, Inc. 20115 1694 1610 619 Charter Communications 4323 1605 1140 398 Time Warner Telecom 30036 1349 289 678 Mediacom Communications Corp 7018 1310 10552 860 AT&T WorldNet Services 11492 1207 221 334 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8402 1825 544 16 Corbina telecom 2118 1115 97 13 EUnet/RELCOM Autonomous Syste 34984 1058 232 204 BILISIM TELEKOM 13188 840 99 22 Educational Network 12479 829 783 68 Uni2 Autonomous System 31148 762 39 20 FreeNet ISP 20940 748 253 591 Akamai Technologies European 6830 712 2313 433 UPC Distribution Services 8551 711 367 39 Bezeq International 34744 681 185 39 SC GVM SISTEM 2003 SRL Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 28573 2410 1330 84 NET Servicos de Comunicao S.A 10620 2320 398 224 TVCABLE BOGOTA 7303 1681 1147 207 Telecom Argentina Stet-France 6503 1387 435 67 AVANTEL, S.A. 8151 1379 2818 395 UniNet S.A. de C.V. 14754 938 127 75 Telgua S. A. 18881 781 716 18 Global Village Telecom 27947 778 86 100 Telconet S.A 3816 685 306 85 Empresa Nacional de Telecomun 7738 613 1242 34 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 36998 1285 80 4 MOBITEL 24863 897 274 36 LINKdotNET AS number 6713 535 615 23 Itissalat Al-MAGHRIB 8452 529 958 13 TEDATA 24835 342 80 8 RAYA Telecom - Egypt 3741 266 906 224 The Internet Solution 12258 193 28 67 Vodacom Internet Company 15706 191 32 6 Sudatel Internet Exchange Aut 29975 191 667 21 Vodacom 16637 186 696 90 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3057 3695 98 bellsouth.net, inc. 4766 2936 11558 925 Korea Telecom (KIX) 17974 2495 824 85 PT TELEKOMUNIKASI INDONESIA 28573 2410 1330 84 NET Servicos de Comunicao S.A 10620 2320 398 224 TVCABLE BOGOTA 7029 2168 1265 210 Windstream Communications Inc 18566 2080 382 185 Covad Communications 22773 1991 2931 127 Cox Communications, Inc. 1785 1960 677 125 PaeTec Communications, Inc. 7545 1827 301 89 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 17974 2495 2410 PT TELEKOMUNIKASI INDONESIA 28573 2410 2326 NET Servicos de Comunicao S.A 10620 2320 2096 TVCABLE BOGOTA 4766 2936 2011 Korea Telecom (KIX) 7029 2168 1958 Windstream Communications Inc 18566 2080 1895 Covad Communications 22773 1991 1864 Cox Communications, Inc. 1785 1960 1835 PaeTec Communications, Inc. 8402 1825 1809 Corbina telecom 7545 1827 1738 TPG Internet Pty Ltd Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 30031 UNALLOCATED 12.27.122.0/24 7018 AT&T WorldNet Servic 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic 23502 UNALLOCATED 12.44.44.0/24 7018 AT&T WorldNet Servic 17300 UNALLOCATED 12.45.103.0/24 209 Qwest 17300 UNALLOCATED 12.45.110.0/24 701 UUNET Technologies, 16476 UNALLOCATED 12.46.27.0/24 7018 AT&T WorldNet Servic 14764 UNALLOCATED 12.108.237.0/24 7018 AT&T WorldNet Servic 33649 UNALLOCATED 12.111.112.0/24 19029 New Edge Networks 26064 UNALLOCATED 12.149.37.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 128.0.0.0/24 2876 Jump Management SRL 128.0.16.0/21 43568 RIPE Network Coordination Cen 128.0.24.0/21 41794 Altline LLC 128.0.60.0/23 57417 INTERNET TASMANIA SRL 128.0.62.0/23 57417 INTERNET TASMANIA SRL 128.0.72.0/21 23456 32-bit ASN transition 128.0.80.0/20 52041 Timer LTD 128.0.96.0/21 12886 LEWTelNet GmbH 128.0.104.0/23 51848 FOP Gabidullina Ludmila Nikol 128.0.106.0/24 23456 32-bit ASN transition Complete listing at http://thyme.rand.apnic.net/current/data-dsua Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.222.80.0/21 37110 Moztel LDA 62.12.96.0/19 38478 SunnyVision Limited 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.185.224.0/24 27431 JTL Networks Inc. 64.185.225.0/24 27431 JTL Networks Inc. 64.185.226.0/24 27431 JTL Networks Inc. 64.185.227.0/24 27431 JTL Networks Inc. 64.185.228.0/24 27431 JTL Networks Inc. 64.185.229.0/24 27431 JTL Networks Inc. Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:17 /9:13 /10:29 /11:88 /12:247 /13:483 /14:867 /15:1557 /16:12575 /17:6593 /18:10942 /19:21753 /20:31257 /21:33443 /22:45742 /23:41149 /24:232590 /25:1386 /26:1752 /27:859 /28:184 /29:60 /30:15 /31:0 /32:21 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 18566 2030 2080 Covad Communications 6389 1755 3057 bellsouth.net, inc. 7029 1556 2168 Windstream Communications Inc 8402 1551 1825 Corbina telecom 22773 1304 1991 Cox Communications, Inc. 36998 1279 1285 MOBITEL 30036 1240 1349 Mediacom Communications Corp 11492 1169 1207 Cable One 1785 1039 1960 PaeTec Communications, Inc. 7011 954 1199 Citizens Utilities Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:681 2:723 3:3 4:13 5:752 6:3 8:500 12:1931 13:3 14:745 15:11 16:3 17:8 20:24 23:241 24:1801 27:1461 31:1130 32:54 33:2 34:5 36:11 37:1291 38:853 39:2 40:141 41:2664 42:178 44:3 46:1762 47:1 49:611 50:660 52:12 54:28 55:7 57:28 58:1074 59:559 60:259 61:1321 62:1025 63:2026 64:4308 65:2176 66:4270 67:2037 68:1124 69:3261 70:861 71:523 72:1886 74:2548 75:415 76:291 77:1091 78:1043 79:573 80:1223 81:970 82:627 83:542 84:557 85:1158 86:476 87:930 88:378 89:1752 90:265 91:5428 92:621 93:1736 94:2075 95:1585 96:494 97:336 98:1040 99:52 100:30 101:309 103:2156 105:519 106:133 107:206 108:511 109:1767 110:852 111:1014 112:490 113:737 114:687 115:931 116:876 117:792 118:974 119:1269 120:371 121:702 122:1725 123:1188 124:1315 125:1311 128:539 129:199 130:316 131:641 132:327 133:143 134:261 135:62 136:221 137:236 138:341 139:167 140:218 141:314 142:525 143:376 144:477 145:88 146:529 147:347 148:711 149:350 150:165 151:403 152:400 153:191 154:29 155:370 156:243 157:391 158:263 159:709 160:335 161:422 162:369 163:203 164:573 165:447 166:437 167:574 168:1008 169:131 170:1022 171:164 172:4 173:1551 174:579 175:424 176:1121 177:1685 178:1743 180:1374 181:234 182:1185 183:329 184:641 185:251 186:2286 187:1296 188:1928 189:1512 190:6621 192:6357 193:5664 194:4508 195:3493 196:1314 197:909 198:4158 199:5223 200:6071 201:2199 202:8917 203:8732 204:4486 205:2561 206:2792 207:2815 208:4068 209:3521 210:2902 211:1555 212:1977 213:1921 214:902 215:91 216:5215 217:1581 218:601 219:326 220:1265 221:549 222:326 223:463 End of report From jra at baylink.com Fri Feb 22 18:39:21 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 22 Feb 2013 13:39:21 -0500 (EST) Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <4229AA2A-1735-4E2B-9739-89A364610C89@hopcount.ca> Message-ID: <18234239.6902.1361558361117.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joe Abley" > > In fact, Joe, I think it's distinguishing your second case from "a label > > string which is intended to reference a rooted FQDN, but the user did not > > specify the trailing dot -- and yet still does not want a search path > > applied"... > > That's the same as my second case. > > "rooted FQDN" is also not well-defined outside this thread. I don't > think just adopting the terminology unilaterally is going to make it > so. It isn't? I knew what he meant immediately, without having to read the rest of the sentence: an ascii represenation of a fully qualified hostname with a period at the end. > >> The terminology "root zone" or "root domain" to explain the trailing > >> dot is misleading and unhelpful, I find. > > > > No, what's *really* unhelpful and misleading is the people who say > > that it is the *dot* which specifies the name of the root, > > The dot doesn't specify the name of the root. That's why it's > confusing. Oh: we're in violent agreement. :-) > > rather than the > > null labelstring which *follows* that dot (which is what it actually > > is, and I'll save everyone's stomach linings by not saying the words > > "alternate root" here. :-) > > There is no null label string following the dot in a fully-qualified > domain name, in this context. You're confusing the presentation of > domain names with wire-format encoding of domain names. Well, alas, I think you have to unpack that last sentence at least one more layer for me to be sure what I'm agreeing or disagreeing with... but since the dot is a separator (I believe by definition), if it exists at the end, it has to be separating *something*. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jabley at hopcount.ca Fri Feb 22 18:51:36 2013 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 22 Feb 2013 14:51:36 -0400 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <18234239.6902.1361558361117.JavaMail.root@benjamin.baylink.com> References: <18234239.6902.1361558361117.JavaMail.root@benjamin.baylink.com> Message-ID: On 2013-02-22, at 14:39, Jay Ashworth wrote: >>> In fact, Joe, I think it's distinguishing your second case from "a label >>> string which is intended to reference a rooted FQDN, but the user did not >>> specify the trailing dot -- and yet still does not want a search path >>> applied"... >> >> That's the same as my second case. >> >> "rooted FQDN" is also not well-defined outside this thread. I don't >> think just adopting the terminology unilaterally is going to make it >> so. > > It isn't? Nope. > I knew what he meant immediately, without having to read the rest of > the sentence: an ascii represenation of a fully qualified hostname > with a period at the end. I could have guessed the same thing, but the phrase is not in common use, and hence I think "not well-defined" is the right description. > but since the dot is a separator (I believe by definition), if it exists > at the end, it has to be separating *something*. I had a quick look, and RFC 1035 agrees with you, so I guess I have to eat my words :-) When a user needs to type a domain name, the length of each label is omitted and the labels are separated by dots ("."). Since a complete domain name ends with the root label, this leads to a printed form which ends in a dot. We use this property to distinguish between: - a character string which represents a complete domain name (often called "absolute"). For example, "poneria.ISI.EDU." - a character string that represents the starting labels of a domain name which is incomplete, and should be completed by local software using knowledge of the local domain (often called "relative"). For example, "poneria" used in the ISI.EDU domain. Relative names are either taken relative to a well known origin, or to a list of domains used as a search list. Relative names appear mostly at the user interface, where their interpretation varies from implementation to implementation, and in master files, where they are relative to a single origin domain name. The most common interpretation uses the root "." as either the single origin or as one of the members of the search list, so a multi-label relative name is often one where the trailing dot has been omitted to save typing. So I guess we have a winner, according to the spec: "absolute domain name". I don't believe that's in common usage either, but at least it is referenced in the specification. Joe From asullivan at dyn.com Fri Feb 22 19:01:05 2013 From: asullivan at dyn.com (Andrew Sullivan) Date: Fri, 22 Feb 2013 14:01:05 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <18234239.6902.1361558361117.JavaMail.root@benjamin.baylink.com> References: <4229AA2A-1735-4E2B-9739-89A364610C89@hopcount.ca> <18234239.6902.1361558361117.JavaMail.root@benjamin.baylink.com> Message-ID: <20130222190105.GR455@dyn.com> On Fri, Feb 22, 2013 at 01:39:21PM -0500, Jay Ashworth wrote: > but since the dot is a separator (I believe by definition), if it exists > at the end, it has to be separating *something*. > Without getting into metaphysics, we can think of the dot in the presentation format as representing the separators in the wire format. In the wire format, of course, these separators are octets that indicate the size of the next label. And since the final label is null, the separator indicates a zero length in the wire format. Therefore, in the presentation format, the final separator is indicative of the (null) root label after. But if we want to skirt metaphysics, the problem here is the status of the presentation vs. wire format. If these are two perfectly co-equal forms of representation, then we have a funny problem, since in the global DNS the wire format is _never_ a relative lookup (the search path gets appended before lookup). If on the other hand the presentation format is merely one for human consumption, and the wire format is canonical, then there's just a representational problem. This of course doesn't actually help with the original question, which is how to refer to all these things unambiguously. I have no idea how to solve that: the different terms have an established use, and fixing ambiguities in established use is a problem far beyond the bounds of networking. A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From cidr-report at potaroo.net Fri Feb 22 22:00:00 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Feb 2013 22:00:00 GMT Subject: The Cidr Report Message-ID: <201302222200.r1MM00bV063324@wattle.apnic.net> This report has been generated at Tue Feb 19 16:13:14 2013 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 12-02-13 445341 254468 13-02-13 444932 254971 14-02-13 445625 254890 15-02-13 445440 255148 16-02-13 445491 255598 17-02-13 445709 255627 18-02-13 445529 256541 19-02-13 445862 256692 AS Summary 43455 Number of ASes in routing system 18036 Number of ASes announcing only one prefix 3063 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 116912864 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 19Feb13 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 445961 256729 189232 42.4% All ASes AS6389 3063 104 2959 96.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS28573 2387 88 2299 96.3% NET Servicos de Comunicao S.A. AS17974 2486 474 2012 80.9% TELKOMNET-AS2-AP PT Telekomunikasi Indonesia AS4766 2938 942 1996 67.9% KIXS-AS-KR Korea Telecom AS18566 2080 427 1653 79.5% COVAD - Covad Communications Co. AS10620 2319 670 1649 71.1% Telmex Colombia S.A. AS7303 1681 408 1273 75.7% Telecom Argentina S.A. AS4323 1606 401 1205 75.0% TWTC - tw telecom holdings, inc. AS4755 1688 579 1109 65.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS2118 1115 83 1032 92.6% RELCOM-AS OOO "NPO Relcom" AS7552 1161 180 981 84.5% VIETEL-AS-AP Vietel Corporation AS7029 2166 1198 968 44.7% WINDSTREAM - Windstream Communications Inc AS36998 1286 381 905 70.4% SDN-MOBITEL AS18101 1008 170 838 83.1% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS22773 1989 1162 827 41.6% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS7545 1834 1019 815 44.4% TPG-INTERNET-AP TPG Internet Pty Ltd AS1785 1959 1169 790 40.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS8151 1513 745 768 50.8% Uninet S.A. de C.V. AS4808 1114 355 759 68.1% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS18881 773 26 747 96.6% Global Village Telecom AS14754 942 207 735 78.0% Telgua AS13977 838 123 715 85.3% CTELCO - FAIRPOINT COMMUNICATIONS, INC. AS9808 737 51 686 93.1% CMNET-GD Guangdong Mobile Communication Co.Ltd. AS855 715 50 665 93.0% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS24560 1045 416 629 60.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS22561 1067 445 622 58.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS17676 720 99 621 86.2% GIGAINFRA Softbank BB Corp. AS3356 1103 498 605 54.9% LEVEL3 Level 3 Communications AS3549 1046 444 602 57.6% GBLX Global Crossing Ltd. AS19262 998 404 594 59.5% VZGNI-TRANSIT - Verizon Online LLC Total 45377 13318 32059 70.7% Top 30 total Possible Bogus Routes 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 41.222.80.0/21 AS37110 moztel-as 62.12.96.0/19 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.185.224.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.225.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.226.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.227.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.228.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.229.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.230.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.231.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.232.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.233.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.234.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.235.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.236.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.237.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.238.0/24 AS27431 JTLNET - JTL Networks Inc. 64.185.239.0/24 AS27431 JTLNET - JTL Networks Inc. 64.187.208.0/24 AS174 COGENT Cogent/PSI 65.111.1.0/24 AS32258 SDNGLOBAL - SDN Global 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 66.251.128.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.133.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.134.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.136.0/21 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.140.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.141.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.142.0/24 AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks 66.251.143.0/24 AS3356 LEVEL3 Level 3 Communications 69.46.224.0/20 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.233.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.46.236.0/24 AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers 69.165.92.0/24 AS20077 IPNETZONE-ASN - IPNetZone 71.19.134.0/23 AS3313 INET-AS BT Italia S.p.A. 72.35.224.0/22 AS30097 NUWAVE - NuWave 72.35.229.0/24 AS30188 TELEVERGENCE - Televergence Solutions Inc. 72.35.232.0/21 AS30097 NUWAVE - NuWave 72.44.16.0/20 AS15054 NORTHEAST-TEXAS-BROADBAND-LLC - Northeast Texas Broadband, LLC 74.91.48.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.49.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.50.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.51.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.52.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.53.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.54.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.55.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.56.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.57.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.58.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.59.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.60.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.61.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.62.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.91.63.0/24 AS30137 SEA-BROADBAND - Sea Broadband, LLC 74.115.124.0/23 AS46540 NARSASN - National Asset Recovery Services, Inc 81.4.0.0/18 AS38478 SUNNYVISION-AS-AP SunnyVision Limited 81.22.64.0/20 AS5511 OPENTRANSIT France Telecom S.A. 82.101.160.0/19 AS5511 OPENTRANSIT France Telecom S.A. 100.100.0.0/24 AS4847 CNIX-AP China Networks Inter-Exchange 102.2.88.0/22 AS38456 PACTEL-AS-AP Pacific Teleports. 103.5.152.0/22 AS4686 BEKKOAME BEKKOAME INTERNET INC. 103.11.148.0/24 AS58452 103.11.149.0/24 AS58452 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas S.A. 116.206.72.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.85.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 116.206.103.0/24 AS6461 MFNX MFN - Metromedia Fiber Network 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services LP 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 172.116.0.0/24 AS7018 ATT-INTERNET4 - AT&T Services, Inc. 185.19.20.0/22 AS42610 NCNET-AS National Cable Networks 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.53.0.0/19 AS13878 Diveo do Brasil Telecomunicacoes Ltda 200.58.248.0/21 AS27849 202.8.106.0/24 AS9530 SHINSEGAE-AS SHINSEGAE I&C Co., Ltd. 202.58.113.0/24 AS19161 202.65.96.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.73.240.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.142.219.0/24 AS45149 204.9.116.0/22 AS30097 NUWAVE - NuWave 204.10.88.0/21 AS3356 LEVEL3 Level 3 Communications 204.10.92.0/23 AS30097 NUWAVE - NuWave 204.10.94.0/23 AS30097 NUWAVE - NuWave 204.10.112.0/21 AS27027 ANBELL ASN-ANBELL 204.11.112.0/22 AS14745 INTERNAP-BLOCK-4 - Internap Network Services Corporation 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A. 205.211.160.0/24 AS30045 UHN-ASN - University Health Network 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 206.221.176.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.177.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.178.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.179.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.180.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.181.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.182.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.183.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.184.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.185.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.186.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.187.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.188.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.189.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.190.0/24 AS27431 JTLNET - JTL Networks Inc. 206.221.191.0/24 AS27431 JTLNET - JTL Networks Inc. 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.254.128.0/21 AS30689 FLOW-NET - FLOW 207.254.128.0/24 AS30689 FLOW-NET - FLOW 207.254.136.0/21 AS30689 FLOW-NET - FLOW 207.254.138.0/24 AS30689 FLOW-NET - FLOW 207.254.140.0/24 AS30689 FLOW-NET - FLOW 208.77.164.0/24 AS22659 208.77.165.0/24 AS22659 208.77.166.0/24 AS22659 208.77.167.0/24 AS22659 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 208.89.32.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.33.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.34.0/24 AS27431 JTLNET - JTL Networks Inc. 208.89.35.0/24 AS27431 JTLNET - JTL Networks Inc. 208.91.72.0/24 AS21681 ANDOVER-TRADING - ANDOVER TRADING 208.91.73.0/24 AS17361 BRASS - Sungard Trading System (ASC) 208.91.76.0/23 AS21681 ANDOVER-TRADING - ANDOVER TRADING 209.148.64.0/19 AS13773 TELNETCOMM - Telnet Communications 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.234.112.0/23 AS32252 209.234.114.0/23 AS32252 209.234.116.0/24 AS32252 209.234.117.0/24 AS32252 209.234.118.0/24 AS32252 209.234.119.0/24 AS32252 209.234.120.0/24 AS32252 209.234.121.0/24 AS32252 209.234.122.0/24 AS32252 213.150.204.0/24 AS29338 AFOL-AS Used by Africaonline Operations 216.12.163.0/24 AS26627 AS-PILOSOFT - Pilosoft, Inc. 216.146.0.0/19 AS11915 TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 216.152.24.0/22 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.227.142.0/23 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.227.144.0/21 AS46856 GLOBAL-HOST-AS - The Global Host Exchange 216.234.128.0/22 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.132.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. 216.234.139.0/24 AS14545 ADR-DRIVING-RECORDS - AMERICAN DRIVING RECORDS, INC. Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Feb 22 22:00:02 2013 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Feb 2013 22:00:02 GMT Subject: BGP Update Report Message-ID: <201302222200.r1MM02ak063350@wattle.apnic.net> BGP Update Report Interval: 11-Feb-13 -to- 18-Feb-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9498 111602 4.7% 107.9 -- BBIL-AP BHARTI Airtel Ltd. 2 - AS24560 91379 3.8% 88.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 3 - AS8402 49667 2.1% 27.5 -- CORBINA-AS OJSC "Vimpelcom" 4 - AS18207 45646 1.9% 131.9 -- YOU-INDIA-AP YOU Broadband & Cable India Ltd. 5 - AS3909 42966 1.8% 1227.6 -- QWEST-AS-3908 - Qwest Communications Company, LLC 6 - AS7029 36157 1.5% 18.3 -- WINDSTREAM - Windstream Communications Inc 7 - AS8151 30815 1.3% 23.8 -- Uninet S.A. de C.V. 8 - AS9829 28968 1.2% 34.8 -- BSNL-NIB National Internet Backbone 9 - AS45609 27674 1.2% 105.6 -- BHARTI-MOBILITY-AS-AP Bharti Airtel Ltd. AS for GPRS Service 10 - AS18002 24115 1.0% 114.8 -- WORLDPHONE-IN AS Number for Interdomain Routing 11 - AS32777 23335 1.0% 4667.0 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 12 - AS36998 21970 0.9% 18.1 -- SDN-MOBITEL 13 - AS2708 21659 0.9% 154.7 -- Universidad de Guanajuato 14 - AS45514 21014 0.9% 69.1 -- TELEMEDIA-SMB-AS-AP Bharti Airtel Ltd., TELEMEDIA Services, for SMB customers 15 - AS4 19416 0.8% 526.0 -- COMUNICALO DE MEXICO S.A. DE C.V 16 - AS45528 17023 0.7% 45.2 -- TDN Tikona Digital Networks Pvt Ltd. 17 - AS17974 16207 0.7% 7.0 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 18 - AS31148 15822 0.7% 20.6 -- FREENET-AS Freenet Ltd. 19 - AS17488 14556 0.6% 45.5 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 20 - AS57816 11755 0.5% 2938.8 -- SAMEN Samen Ertebat Asr Co. (P.J.S.) TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32777 23335 1.0% 4667.0 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 2 - AS19406 4126 0.2% 4126.0 -- TWRS-MA - Towerstream I, Inc. 3 - AS40946 6077 0.2% 3038.5 -- PROCON - Sat Track 4 - AS6174 5879 0.2% 2939.5 -- SPRINTLINK8 - Sprint 5 - AS57816 11755 0.5% 2938.8 -- SAMEN Samen Ertebat Asr Co. (P.J.S.) 6 - AS14680 5943 0.2% 1981.0 -- REALE-6 - Auction.com 7 - AS36529 2746 0.1% 1373.0 -- AXXA-RACKCO - Rackco.com 8 - AS8657 1323 0.1% 1323.0 -- CPRM CPRM Autonomous System 9 - AS17293 3920 0.2% 1306.7 -- VTXC - VTX Communications 10 - AS3909 42966 1.8% 1227.6 -- QWEST-AS-3908 - Qwest Communications Company, LLC 11 - AS22140 5832 0.2% 972.0 -- T-MOBILE-AS22140 - T-Mobile USA, Inc. 12 - AS4 19416 0.8% 526.0 -- COMUNICALO DE MEXICO S.A. DE C.V 13 - AS40931 1660 0.1% 830.0 -- MOBITV - MobiTV, Inc 14 - AS12397 807 0.0% 807.0 -- OPTOCOM Optocom Ltd 15 - AS9950 4666 0.2% 777.7 -- PUBNETPLUS2-AS-KR DACOM 16 - AS37367 709 0.0% 709.0 -- CALLKEY 17 - AS57201 696 0.0% 696.0 -- EDF-AS Estonian Defence Forces 18 - AS4663 2758 0.1% 689.5 -- ELIMNET-AS ELIMNET, INC 19 - AS12413 686 0.0% 686.0 -- HANSHAKE-AS Handshake e.V. 20 - AS6197 686 0.0% 686.0 -- BATI-ATL - BellSouth Network Solutions, Inc TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 151.118.255.0/24 14290 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 2 - 151.118.254.0/24 14290 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - 151.118.18.0/24 14259 0.6% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - 37.9.248.0/21 11701 0.5% AS57816 -- SAMEN Samen Ertebat Asr Co. (P.J.S.) 5 - 202.41.70.0/24 9362 0.4% AS2697 -- ERX-ERNET-AS Education and Research Network 6 - 196.1.167.0/24 8133 0.3% AS11139 -- CWRIN CW BARBADOS 7 - 66.55.234.0/24 7838 0.3% AS7029 -- WINDSTREAM - Windstream Communications Inc 8 - 192.58.232.0/24 7645 0.3% AS6629 -- NOAA-AS - NOAA 9 - 208.92.131.0/24 6076 0.2% AS40946 -- PROCON - Sat Track 10 - 208.14.186.0/24 5803 0.2% AS22140 -- T-MOBILE-AS22140 - T-Mobile USA, Inc. 11 - 12.139.133.0/24 4793 0.2% AS14680 -- REALE-6 - Auction.com 12 - 194.63.9.0/24 4706 0.2% AS1273 -- CW Cable and Wireless Worldwide plc 13 - 8.12.92.0/22 4667 0.2% AS32777 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 14 - 66.78.242.0/23 4667 0.2% AS32777 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 15 - 67.110.75.0/24 4667 0.2% AS32777 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 16 - 65.172.212.0/22 4667 0.2% AS32777 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 17 - 97.65.228.0/22 4667 0.2% AS32777 -- SMART-CITY-FORT-WORTH - Smart City Networks, L.P. 18 - 58.184.229.0/24 4652 0.2% AS9950 -- PUBNETPLUS2-AS-KR DACOM 19 - 69.38.178.0/24 4126 0.2% AS19406 -- TWRS-MA - Towerstream I, Inc. 20 - 122.161.0.0/16 4028 0.2% AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From brunner at nic-naa.net Fri Feb 22 22:10:02 2013 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Fri, 22 Feb 2013 14:10:02 -0800 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130222190105.GR455@dyn.com> References: <4229AA2A-1735-4E2B-9739-89A364610C89@hopcount.ca> <18234239.6902.1361558361117.JavaMail.root@benjamin.baylink.com> <20130222190105.GR455@dyn.com> Message-ID: <5127ECBA.40807@nic-naa.net> On 2/22/13 11:01 AM, Andrew Sullivan wrote: > Without getting into metaphysics, we can think of the dot in the > presentation format as representing the separators in the wire > format. In the wire format, of course, these separators are octets > that indicate the size of the next label. And since the final label > is null, the separator indicates a zero length in the wire format. > Therefore, in the presentation format, the final separator is > indicative of the (null) root label after. just keep in mind that while "." ought to be a label separator, the utc's bidi algorithm allows the directionality of a label to "leak" across the "period" character, where it is not a terminal character. hilarity ensues. From reichert at numachi.com Fri Feb 22 21:55:02 2013 From: reichert at numachi.com (Brian Reichert) Date: Fri, 22 Feb 2013 16:55:02 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <7446004.6892.1361554893925.JavaMail.root@benjamin.baylink.com> References: <20130222171710.GB99258@numachi.com> <7446004.6892.1361554893925.JavaMail.root@benjamin.baylink.com> Message-ID: <20130222215502.GD99258@numachi.com> On Fri, Feb 22, 2013 at 12:41:33PM -0500, Jay Ashworth wrote: > My snap reaction is to say that nothing should ever be *trying* to > compare a rooted F.Q.D.N. against a certificate; it is, as has been > noted, merely command line/entry field shorthand to tell the local > resolver where to quit; applications should all be stripping that > trailing dot. > > Do you have evidence that the extra AltName with the trailing dot > is operationally necessary? 'Necessary' is what's hard to ascertain here. If, under a UNIX-like operating system, you request a PTR with some command-line tool such as 'dig', you'll get a rooted domain name: $ dig -x 8.8.8.8 +short google-public-dns-a.google.com. And you can use this rooted domain name get an A record: $ dig a google-public-dns-a.google.com. +short 8.8.8.8 As a matter of example, if you had automation that was internally testing your network for trusted certificates, and generated a set of hostnames based on reverse DNS, then your SSL client will now be using rooted domain names. When I did my initial development with OpenSSL, I observed: - If I did not have the rooted domain name in the SAN, then any SSL client stack would fail the verification if a rooted domain name was used to connect to the SSL server. - I could generate a CSR with both formats of hostnames. - My OpenSSL-based CA (and our internal MS-based CA) would sign said certificate request, preserving all of the hostnames in the SAN. - and now using a roted domain name was successful. And I figured, if both OpenSSL and Microsoft's Certificate Services, (and their respective SSL clients) behaved the same way, I just coded my automated generation of the CSR to include the rooted domain names, just to cover my bases. I did not expect that misc commercial entities would punish people under these circumstances... Now, I expect in this specific customer's case, I'm reasonably certain that they won't have a tool chain / work flow / whatever, that would introduce a rooted domain name. But, I don't know if I can guarantee that for all of our current and future clients. I don't know if the practices suggested by RFC 1535 will come into effect, but I wanted to future-proof our product in this regard... > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 > -- Brian Reichert BSD admin/developer at large From jra at baylink.com Fri Feb 22 22:21:02 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 22 Feb 2013 17:21:02 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130222215502.GD99258@numachi.com> References: <20130222171710.GB99258@numachi.com> <7446004.6892.1361554893925.JavaMail.root@benjamin.baylink.com> <20130222215502.GD99258@numachi.com> Message-ID: In short, "yes, Jay, I do". Got it. :-) You saw Joe's second reply? Brian Reichert wrote: >On Fri, Feb 22, 2013 at 12:41:33PM -0500, Jay Ashworth wrote: >> My snap reaction is to say that nothing should ever be *trying* to >> compare a rooted F.Q.D.N. against a certificate; it is, as has been >> noted, merely command line/entry field shorthand to tell the local >> resolver where to quit; applications should all be stripping that >> trailing dot. >> >> Do you have evidence that the extra AltName with the trailing dot >> is operationally necessary? > >'Necessary' is what's hard to ascertain here. > >If, under a UNIX-like operating system, you request a PTR with some >command-line tool such as 'dig', you'll get a rooted domain name: > > $ dig -x 8.8.8.8 +short > google-public-dns-a.google.com. > >And you can use this rooted domain name get an A record: > > $ dig a google-public-dns-a.google.com. +short > 8.8.8.8 > >As a matter of example, if you had automation that was internally >testing your network for trusted certificates, and generated a set >of hostnames based on reverse DNS, then your SSL client will now >be using rooted domain names. > >When I did my initial development with OpenSSL, I observed: > >- If I did not have the rooted domain name in the SAN, then any SSL > client stack would fail the verification if a rooted domain name > was used to connect to the SSL server. > >- I could generate a CSR with both formats of hostnames. > >- My OpenSSL-based CA (and our internal MS-based CA) would sign > said certificate request, preserving all of the hostnames in the SAN. > >- and now using a roted domain name was successful. > >And I figured, if both OpenSSL and Microsoft's Certificate Services, >(and their respective SSL clients) behaved the same way, I just >coded my automated generation of the CSR to include the rooted >domain names, just to cover my bases. > >I did not expect that misc commercial entities would punish people >under these circumstances... > >Now, I expect in this specific customer's case, I'm reasonably >certain that they won't have a tool chain / work flow / whatever, >that would introduce a rooted domain name. > >But, I don't know if I can guarantee that for all of our current >and future clients. I don't know if the practices suggested by RFC >1535 will come into effect, but I wanted to future-proof our product >in this regard... > >> >> Cheers, >> -- jra >> -- >> Jay R. Ashworth Baylink >jra at baylink.com >> Designer The Things I Think >RFC 2100 >> Ashworth & Associates http://baylink.pitas.com 2000 Land >Rover DII >> St Petersburg FL USA #natog +1 727 >647 1274 >> > >-- >Brian Reichert >BSD admin/developer at large -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From asullivan at dyn.com Fri Feb 22 22:27:21 2013 From: asullivan at dyn.com (Andrew Sullivan) Date: Fri, 22 Feb 2013 17:27:21 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <5127ECBA.40807@nic-naa.net> References: <4229AA2A-1735-4E2B-9739-89A364610C89@hopcount.ca> <18234239.6902.1361558361117.JavaMail.root@benjamin.baylink.com> <20130222190105.GR455@dyn.com> <5127ECBA.40807@nic-naa.net> Message-ID: <20130222222721.GE455@dyn.com> On Fri, Feb 22, 2013 at 02:10:02PM -0800, Eric Brunner-Williams wrote: > just keep in mind that while "." ought to be a label separator, the > utc's bidi algorithm allows the directionality of a label to "leak" > across the "period" character, where it is not a terminal character. Yes, this is true, although that's at yet another layer _above_ the DNS presentation layer. That is, the . we are talking about is in the DNS presentation layer, which ought only ever to contain A-labels (xn--somethinghere) and not U-labels. (Someone suggested to me that the motto for IDNA ought to be, "Insufficient complication can always be solved by another layer of misdirection.") A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From reichert at numachi.com Fri Feb 22 22:19:50 2013 From: reichert at numachi.com (Brian Reichert) Date: Fri, 22 Feb 2013 17:19:50 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: References: <20130222171710.GB99258@numachi.com> <7446004.6892.1361554893925.JavaMail.root@benjamin.baylink.com> <20130222215502.GD99258@numachi.com> Message-ID: <20130222221950.GE99258@numachi.com> On Fri, Feb 22, 2013 at 05:21:02PM -0500, Jay Ashworth wrote: > In short, "yes, Jay, I do". Got it. :-) :) > You saw Joe's second reply? Apparently, I lost track of that while writing this up. :) -- Brian Reichert BSD admin/developer at large From jra at baylink.com Fri Feb 22 22:46:27 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 22 Feb 2013 17:46:27 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130222221950.GE99258@numachi.com> References: <20130222171710.GB99258@numachi.com> <7446004.6892.1361554893925.JavaMail.root@benjamin.baylink.com> <20130222215502.GD99258@numachi.com> <20130222221950.GE99258@numachi.com> Message-ID: <97006e8c-d3bd-4ced-b814-fc880130fbe1@email.android.com> So, should browsers send absolute host names in http/1.1 requests, and shouldn't servers strip the trailing dot if they get one? I vote No and Yes, resp. Brian Reichert wrote: >On Fri, Feb 22, 2013 at 05:21:02PM -0500, Jay Ashworth wrote: >> In short, "yes, Jay, I do". Got it. :-) > >:) > >> You saw Joe's second reply? > >Apparently, I lost track of that while writing this up. :) > >-- >Brian Reichert >BSD admin/developer at large -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From rsk at gsp.org Fri Feb 22 23:08:05 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 22 Feb 2013 18:08:05 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <1361513943.28479.437.camel@karl> References: <20130221225540.GA99258@numachi.com> <20130222055742.DE65A2FF4D49@drugs.dv.isc.org> <1361513943.28479.437.camel@karl> Message-ID: <20130222230805.GA5475@gsp.org> On Fri, Feb 22, 2013 at 05:19:03PM +1100, Karl Auer wrote: > It's a convention common enough and useful enough that I can see why > people would want a handy term for it. How about "stopdot"? Seems to cover the function and the form. ---rsk From reichert at numachi.com Fri Feb 22 22:56:23 2013 From: reichert at numachi.com (Brian Reichert) Date: Fri, 22 Feb 2013 17:56:23 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <97006e8c-d3bd-4ced-b814-fc880130fbe1@email.android.com> References: <20130222171710.GB99258@numachi.com> <7446004.6892.1361554893925.JavaMail.root@benjamin.baylink.com> <20130222215502.GD99258@numachi.com> <20130222221950.GE99258@numachi.com> <97006e8c-d3bd-4ced-b814-fc880130fbe1@email.android.com> Message-ID: <20130222225623.GG99258@numachi.com> On Fri, Feb 22, 2013 at 05:46:27PM -0500, Jay Ashworth wrote: > So, should browsers send absolute host names in http/1.1 requests, and shouldn't servers strip the trailing dot if they get one? > > I vote No and Yes, resp. The first question is tough, only because of the depth of the exatblished convention. I think I would argue 'Yes', as to remove ambiguity, but that naively makes a lot of legacy software trip in unexpected ways. As for the second question, I generally disapprove of throwing away information, so I say No. Clearly I like to make trouble for myself. :) -- Brian Reichert BSD admin/developer at large From reichert at numachi.com Fri Feb 22 23:12:41 2013 From: reichert at numachi.com (Brian Reichert) Date: Fri, 22 Feb 2013 18:12:41 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: References: <20130221225540.GA99258@numachi.com> <20130222055742.DE65A2FF4D49@drugs.dv.isc.org> <1361513943.28479.437.camel@karl> <20130222171710.GB99258@numachi.com> Message-ID: <20130222231241.GH99258@numachi.com> On Fri, Feb 22, 2013 at 03:30:57PM -0800, Geoffrey Keating wrote: > This is clarified in RFC 3280: > > When the subjectAltName extension contains a domain name system > label, the domain name MUST be stored in the dNSName (an IA5String). > The name MUST be in the "preferred name syntax," as specified by RFC > 1034 [RFC 1034]. I agree on what that spec says. My concern that that a rooted domain name is (will be?) valid in practice, and is supported by client software seemingly everywhere. The spec for a URL also calls out what constitutes a hostname, and I've yet to see a HTTP client that trips over a rooted domain name. (Yes, I'm aware an alternate bit of terminology has been proposed, but I'm trying to be consistent for the duration of this thread.) Still, I'm not arguing about what should be allowed; I'm trying to come up with the words to explain to end-users. -- Brian Reichert BSD admin/developer at large From jra at baylink.com Sat Feb 23 00:10:31 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 22 Feb 2013 19:10:31 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130222225623.GG99258@numachi.com> References: <20130222171710.GB99258@numachi.com> <7446004.6892.1361554893925.JavaMail.root@benjamin.baylink.com> <20130222215502.GD99258@numachi.com> <20130222221950.GE99258@numachi.com> <97006e8c-d3bd-4ced-b814-fc880130fbe1@email.android.com> <20130222225623.GG99258@numachi.com> Message-ID: <3d98cac2-d819-4da4-8f14-cf812f6433da@email.android.com> Well, the followup question is: are absolute host names "real", or /solely/ hint to the local resolver not to search-list? I will reread 1035 later tonight ... Brian Reichert wrote: >On Fri, Feb 22, 2013 at 05:46:27PM -0500, Jay Ashworth wrote: >> So, should browsers send absolute host names in http/1.1 requests, >and shouldn't servers strip the trailing dot if they get one? >> >> I vote No and Yes, resp. > >The first question is tough, only because of the depth of the >exatblished convention. I think I would argue 'Yes', as to remove >ambiguity, but that naively makes a lot of legacy software trip in >unexpected ways. > >As for the second question, I generally disapprove of throwing away >information, so I say No. > >Clearly I like to make trouble for myself. :) > >-- >Brian Reichert >BSD admin/developer at large -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From asullivan at dyn.com Sat Feb 23 02:06:09 2013 From: asullivan at dyn.com (Andrew Sullivan) Date: Fri, 22 Feb 2013 21:06:09 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130222231241.GH99258@numachi.com> References: <20130221225540.GA99258@numachi.com> <20130222055742.DE65A2FF4D49@drugs.dv.isc.org> <1361513943.28479.437.camel@karl> <20130222171710.GB99258@numachi.com> <20130222231241.GH99258@numachi.com> Message-ID: <20130223020609.GD78022@dyn.com> On Fri, Feb 22, 2013 at 06:12:41PM -0500, Brian Reichert wrote: > The spec for a URL also calls out what constitutes a hostname, and > I've yet to see a HTTP client that trips over a rooted domain name. Well, RFC 3986 (URI) explicitly allows the final dot. See the section on reg-name in section 3.2.2. Sometimes this RFC is used as one of the example sowers-of-confusion, because despite the fact that the relevant section is talking about DNS domain names, the name of the segment of the URI is called "host", and hostnames don't have a trailing dot. It's no wonder people who merely have to implement this stuff are confused, when the stnadards development organization in question can't figure out how the terminology works! A -- Andrew Sullivan Dyn asullivan at dyn.com From jra at baylink.com Sat Feb 23 03:02:53 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 22 Feb 2013 22:02:53 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130222230805.GA5475@gsp.org> References: <20130221225540.GA99258@numachi.com> <20130222055742.DE65A2FF4D49@drugs.dv.isc.org> <1361513943.28479.437.camel@karl> <20130222230805.GA5475@gsp.org> Message-ID: <2c7a4e70-5156-451e-a56c-1959acd4eb3c@email.android.com> Yrs, but he wanted the retronym for domain names not containing one, not the dot. Absolute and relative domain names, as Joe and 1035 said. Rich Kulawiec wrote: >On Fri, Feb 22, 2013 at 05:19:03PM +1100, Karl Auer wrote: >> It's a convention common enough and useful enough that I can see why >> people would want a handy term for it. > >How about "stopdot"? Seems to cover the function and the form. > >---rsk -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From bzs at world.std.com Sat Feb 23 03:13:00 2013 From: bzs at world.std.com (Barry Shein) Date: Fri, 22 Feb 2013 22:13:00 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <5127ECBA.40807@nic-naa.net> References: <4229AA2A-1735-4E2B-9739-89A364610C89@hopcount.ca> <18234239.6902.1361558361117.JavaMail.root@benjamin.baylink.com> <20130222190105.GR455@dyn.com> <5127ECBA.40807@nic-naa.net> Message-ID: <20776.13244.443230.554193@world.std.com> http://domainincite.com/page/5?s=right+of+the+dot -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From mysidia at gmail.com Sat Feb 23 03:27:18 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 22 Feb 2013 21:27:18 -0600 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130222055742.DE65A2FF4D49@drugs.dv.isc.org> References: <20130221225540.GA99258@numachi.com> <20130222055742.DE65A2FF4D49@drugs.dv.isc.org> Message-ID: On 2/21/13, Mark Andrews wrote: > RFC 952 as modified by RFC 1123 describe the legal syntax of a hostname. > There is no trailing period. A hostname is not a domain name, the hostname is just a label, and has stricter syntax than is allowed in a DNS label; however: When hostnames are represented in DNS, they have corresponding domain names. eg for A.example.com The domain name is unqualified if it contains just the hostname "A". It is partially qualified, if a subset of the labels are provided "A.example" The names are called fully qualified, when the domain name shown is the complete DNS name, with all labels; "A.example.com" In the DNS, the implicit trailing dot is understood to be part of the domain name. Technically "A.example.com" without a trailing dot is unqualified, for purposes of DNS resolution; if a DNS resolver receives NXDOMAIN for A.example.com; some resolvers will normally search for A.example.com.suffix next However, it is nevertheless commonly referred to as fully-qualified, with or without the trailing dot, even though syntactically it could be unqualified; because ".COM" is such a well-known TLD . In this case, it doesn't actually matter what the RFCs call a FQDN; it's overridden by common usage of the phrase/acronym (It is commonly understood that no trailing dot is required, except in the context of a zone file). There is little understanding about qualification of hostnames, and DNS resolver search, and these concepts should probably just go away / be simplified, so all valid lookup names are FQDNs or local hostnames with no dots. >> -- >> Brian Reichert >> BSD admin/developer at large >> > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -- -JH From james.cutler at consultant.com Sat Feb 23 03:49:57 2013 From: james.cutler at consultant.com (Cutler James R) Date: Fri, 22 Feb 2013 22:49:57 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20776.13244.443230.554193@world.std.com> References: <4229AA2A-1735-4E2B-9739-89A364610C89@hopcount.ca> <18234239.6902.1361558361117.JavaMail.root@benjamin.baylink.com> <20130222190105.GR455@dyn.com> <5127ECBA.40807@nic-naa.net> <20776.13244.443230.554193@world.std.com> Message-ID: A domain name without a terminal dot is a relative domain name. -- An application requesting name to address translation gets to decide if a search list is to be used, including the default of dot. A domain name with a terminal dot is a Fully Qualified Domain Name. -- An application requesting name to address translation must submit the name as received to the lookup process. These definitions have been effective of decades and do not need additional terminology. -- Faulty implementations are not an excuse for ever more complex terminology. As a side note, a hostname is usually a domain name. A domain name is never necessarily a hostname. For example, the hostname command on my mini returns "minijim", while the domain name used to reach my mini locally is "minijim.local", but that is not my mini's hostname. But my mini's name to address lookup mechanism uses protocols other than DNS to figure that out. But, new terminology for hostnames or domain names was never required. James R. Cutler james.cutler at consultant.com From jra at baylink.com Sat Feb 23 04:01:03 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 22 Feb 2013 23:01:03 -0500 (EST) Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: Message-ID: <30545475.6952.1361592063875.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Cutler James R" > A domain name without a terminal dot is a relative domain name. > -- An application requesting name to address translation gets to > decide if a search list is to be used, including the default of dot. > > A domain name with a terminal dot is a Fully Qualified Domain Name. > -- An application requesting name to address translation must submit > the name as received to the lookup process. > > These definitions have been effective of decades and do not need > additional terminology. > -- Faulty implementations are not an excuse for ever more complex > terminology. The authoritative document here is, as Joe Abley noted earlier, RFC 1035, which says, in section 5.1: """ Domain names that end in a dot are called absolute, and are taken as complete. Domain names which do not end in a dot are called relative; the actual domain name is the concatenation of the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as an argument to the master file loading routine. A relative name is an error when no origin is available. """ Or, in more Jewish terms: not so much. And in fact, I don't believe that you *have* a manual API-level choice as an application as to whether your resolver library will apply a search list or not: if you specify an absolute name, it won't; if you specify a relative name, it will. Nope: gethostbyname(3) only takes one argument: char *hostname So the only control you have as app is whether you include the trailing dot. (PS: your quoting (or bulleting) protocol is non-standard and non-intuitive) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mysidia at gmail.com Sat Feb 23 04:26:58 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 22 Feb 2013 22:26:58 -0600 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <30545475.6952.1361592063875.JavaMail.root@benjamin.baylink.com> References: <30545475.6952.1361592063875.JavaMail.root@benjamin.baylink.com> Message-ID: On 2/22/13, Jay Ashworth wrote: RFC103 5.1 is correct in the context of a DNS zonefile. In other contexts, however, a domain is absolute without a trailing dot. One example, would be in the case of the SMTP protocol, where hostnames are required to _always_ be absolute. In various common contexts, a domain is always either fully qualified, or not valid. Sometimes a trailing dot is allowed, and in some protocols, a trailing dot is not allowed; however the domain used is still called a FQDN; it's just different syntax, for a fqdn, with minor variations.. A trailing dot is not included in the domain portion of an e-mail address, however within the context of nobody at example.com; example.com is understood to be a fully qualified domain. Nothing else really makes sense; "example.com" is absolute and not relative in this context.. It is also true in the context of a http URL scheme http://www.example.com/ In that context, the www.example.com is a fully qualified domain; although some browsers might try appending other suffixes, as an aid to the user, if the domain cannot be found. No trailing dot allowed; "each domain label starting and ending with an alphanumerical character"; The URL is the most common context where a fully qualified domain would be encountered, e-mail addresses and URLs are the most common case where the average network user will encounter a domain name. For the sake of consistency, if something is considered a FQDN in a URL and in a SMTP hostname or e-mail address, then it ought to be made to be considered a fully qualified domain, everywhere. " Berners-Lee, Masinter & McCahill [Page 5] RFC 1738 Uniform Resource Locators (URL) December 1994 host The fully qualified domain name of a network host, or its IP address as a set of four decimal digit groups separated by ".". Fully qualified domain names take the form as described in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 [5]: a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumerical character and possibly also containing "-" characters. The rightmost domain label will never start with a digit, though, which syntactically distinguishes all domain names from the IP addresses. " > The authoritative document here is, as Joe Abley noted earlier, RFC 1035, > which says, in section 5.1: > > """ > Domain names that end in a dot are called absolute, and are taken as > complete. Domain names which do not end in a dot are called relative; > the actual domain name is the concatenation of the relative part with > an origin specified in a $ORIGIN, $INCLUDE, or as an argument to the > master file loading routine. A relative name is an error when no > origin is available. > """ > Jay R. Ashworth Baylink -- -JH From jra at baylink.com Sat Feb 23 04:57:22 2013 From: jra at baylink.com (Jay Ashworth) Date: Fri, 22 Feb 2013 23:57:22 -0500 (EST) Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: Message-ID: <29360005.6982.1361595442368.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jimmy Hess" > RFC103 5.1 is correct in the context of a DNS zonefile. > In other contexts, however, a domain is absolute without a trailing > dot. If that can be nailed down authoritatively, then it will answer my followup questions, and at least locate the problem the OP was having (that is, it will still work improperly, but at least we'll be able to blame the app vendors with a straight face). > Sometimes a trailing dot is allowed, and in some protocols, a > trailing dot is not allowed; however the domain used is still called > a FQDN; it's just different syntax, for a fqdn, with minor > variations.. You're backing, effectively, my assertion that the only place you can *use* a relative domain name *is as input to a local resolver*, I think. or maybe not. > A trailing dot is not included in the domain portion of an e-mail > address, however within the context of nobody at example.com; > example.com is understood to be a fully qualified domain. I think 5322 actually says so, no? > Nothing else really makes sense; "example.com" is absolute and not > relative in this context.. > > > > It is also true in the context of a http URL scheme > http://www.example.com/ > > In that context, the www.example.com is a fully qualified domain; > although some browsers > might try appending other suffixes, as an aid to the user, if the > domain cannot be found. > > No trailing dot allowed; "each domain label starting and ending with > an alphanumerical character"; The OP asserts that a) if he puts an absolute domain name into a URL then that will be what the webserver at the other end gets as the http/1.1 URL (I believe that's the implication of what he's saying, anyway), and b) if his webserver receives the URL with the trailing dot *it will try to look it up in the SSL cert that way*. No, I must have misunderstood him; as I'm painfully aware, that URL doesn't move until you have the SSL link running. Pants. > The URL is the most common context where a fully qualified domain > would be encountered, e-mail addresses and URLs are the most > common case where the average network user will encounter a domain > name. The issue isn't FQDN vs non-FQDN; it's FQDN represented as an absolute domain name with trailing dot vs FQDN represented as a relative domain without such a dot, but *still* a "rooted" FQDN. > For the sake of consistency, if something is considered a FQDN in a > URL and in a SMTP hostname or e-mail address, then it ought to be > made to be considered a fully qualified domain, everywhere. Don't tell people for whom http://www.slac.physics/ is a valid and common URL that. :-) > " > Berners-Lee, Masinter & McCahill [Page 5] > RFC 1738 Uniform Resource Locators (URL) December 1994 > > host > The fully qualified domain name of a network host, or its IP > address as a set of four decimal digit groups separated by > ".". Fully qualified domain names take the form as described > in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 > [5]: a sequence of domain labels separated by ".", each domain > label starting and ending with an alphanumerical character and > possibly also containing "-" characters. The rightmost domain > label will never start with a digit, though, which > syntactically distinguishes all domain names from the IP > addresses. > " If I'm parsing that right, it means that my assertion was correct: Browsers given an absolute domain name ought not to send the trailing dot in the transactions of any type, and servers receiving it ought to strip it. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From marka at isc.org Sat Feb 23 13:10:20 2013 From: marka at isc.org (Mark Andrews) Date: Sun, 24 Feb 2013 00:10:20 +1100 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: Your message of "Fri, 22 Feb 2013 16:55:02 CDT." <20130222215502.GD99258@numachi.com> References: <20130222171710.GB99258@numachi.com> <7446004.6892.1361554893925.JavaMail.root@benjamin.baylink.com> <20130222215502.GD99258@numachi.com> Message-ID: <20130223131021.498CA30008FF@drugs.dv.isc.org> In message <20130222215502.GD99258 at numachi.com>, Brian Reichert writes: > On Fri, Feb 22, 2013 at 12:41:33PM -0500, Jay Ashworth wrote: > > My snap reaction is to say that nothing should ever be *trying* to > > compare a rooted F.Q.D.N. against a certificate; it is, as has been > > noted, merely command line/entry field shorthand to tell the local > > resolver where to quit; applications should all be stripping that > > trailing dot. > > > > Do you have evidence that the extra AltName with the trailing dot > > is operationally necessary? > > 'Necessary' is what's hard to ascertain here. > > If, under a UNIX-like operating system, you request a PTR with some > command-line tool such as 'dig', you'll get a rooted domain name: > > $ dig -x 8.8.8.8 +short > google-public-dns-a.google.com. You used a tool that returns a entry from the DNS. That tool doesn't do the reverse mapping into a hostname because it is a tool for querying the DNS. If you want a tool that deals with hostnames use something that wraps getnameinfo(). > And you can use this rooted domain name get an A record: > > $ dig a google-public-dns-a.google.com. +short > 8.8.8.8 Again you are confusing domain names with host names. > As a matter of example, if you had automation that was internally > testing your network for trusted certificates, and generated a set > of hostnames based on reverse DNS, then your SSL client will now > be using rooted domain names. > > When I did my initial development with OpenSSL, I observed: > > - If I did not have the rooted domain name in the SAN, then any SSL > client stack would fail the verification if a rooted domain name > was used to connect to the SSL server. Well you have a broken SSL client app. If it is accepting non legal hostnames it should be normalising them before passing them to the ssl layer. > - I could generate a CSR with both formats of hostnames. > > - My OpenSSL-based CA (and our internal MS-based CA) would sign > said certificate request, preserving all of the hostnames in the SAN. > > - and now using a roted domain name was successful. > > And I figured, if both OpenSSL and Microsoft's Certificate Services, > (and their respective SSL clients) behaved the same way, I just > coded my automated generation of the CSR to include the rooted > domain names, just to cover my bases. > > I did not expect that misc commercial entities would punish people > under these circumstances... > > Now, I expect in this specific customer's case, I'm reasonably > certain that they won't have a tool chain / work flow / whatever, > that would introduce a rooted domain name. > > But, I don't know if I can guarantee that for all of our current > and future clients. I don't know if the practices suggested by RFC > 1535 will come into effect, but I wanted to future-proof our product > in this regard... > > > > > Cheers, > > -- jra > > -- > > Jay R. Ashworth Baylink jra at baylink. > com > > Designer The Things I Think RFC 2 > 100 > > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover > DII > > St Petersburg FL USA #natog +1 727 647 1 > 274 > > > > -- > Brian Reichert > BSD admin/developer at large > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Sat Feb 23 13:14:57 2013 From: marka at isc.org (Mark Andrews) Date: Sun, 24 Feb 2013 00:14:57 +1100 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: Your message of "Fri, 22 Feb 2013 17:46:27 CDT." <97006e8c-d3bd-4ced-b814-fc880130fbe1@email.android.com> References: <20130222171710.GB99258@numachi.com> <7446004.6892.1361554893925.JavaMail.root@benjamin.baylink.com> <20130222215502.GD99258@numachi.com> <20130222221950.GE99258@numachi.com> <97006e8c-d3bd-4ced-b814-fc880130fbe1@email.android.com> Message-ID: <20130223131457.78EF03000968@drugs.dv.isc.org> In message <97006e8c-d3bd-4ced-b814-fc880130fbe1 at email.android.com>, Jay Ashwor th writes: > So, should browsers send absolute host names in http/1.1 requests, and should > n't servers strip the trailing dot if they get one? > > I vote No and Yes, resp. Yes. Note that doesn't mean with a trailing period. Browsers should also disable searches when following urls not entered in the entry bar. > Brian Reichert wrote: > > >On Fri, Feb 22, 2013 at 05:21:02PM -0500, Jay Ashworth wrote: > >> In short, "yes, Jay, I do". Got it. :-) > > > >:) > > > >> You saw Joe's second reply? > > > >Apparently, I lost track of that while writing this up. :) > > > >-- > >Brian Reichert > >BSD admin/developer at large > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Sat Feb 23 13:28:38 2013 From: marka at isc.org (Mark Andrews) Date: Sun, 24 Feb 2013 00:28:38 +1100 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: Your message of "Fri, 22 Feb 2013 23:01:03 CDT." <30545475.6952.1361592063875.JavaMail.root@benjamin.baylink.com> References: <30545475.6952.1361592063875.JavaMail.root@benjamin.baylink.com> Message-ID: <20130223132838.333F83000A4D@drugs.dv.isc.org> In message <30545475.6952.1361592063875.JavaMail.root at benjamin.baylink.com>, Ja y Ashworth writes: > ----- Original Message ----- > > From: "Cutler James R" > > > A domain name without a terminal dot is a relative domain name. > > -- An application requesting name to address translation gets to > > decide if a search list is to be used, including the default of dot. > > > > A domain name with a terminal dot is a Fully Qualified Domain Name. > > -- An application requesting name to address translation must submit > > the name as received to the lookup process. > > > > These definitions have been effective of decades and do not need > > additional terminology. > > -- Faulty implementations are not an excuse for ever more complex > > terminology. > > The authoritative document here is, as Joe Abley noted earlier, RFC 1035, > which says, in section 5.1: > > """ > Domain names that end in a dot are called absolute, and are taken as > complete. Domain names which do not end in a dot are called relative; > the actual domain name is the concatenation of the relative part with > an origin specified in a $ORIGIN, $INCLUDE, or as an argument to the > master file loading routine. A relative name is an error when no > origin is available. > """ Which applies to domain names in master files. > Or, in more Jewish terms: not so much. > > And in fact, I don't believe that you *have* a manual API-level choice > as an application as to whether your resolver library will apply a > search list or not: if you specify an absolute name, it won't; if you > specify a relative name, it will. > > Nope: gethostbyname(3) only takes one argument: char *hostname > > So the only control you have as app is whether you include the trailing > dot. On most platforms it isn't the only control. Not gethostname predates search lists and even heirachical domain named. > (PS: your quoting (or bulleting) protocol is non-standard and non-intuitive) > > Cheers, > -- jra > > > -- > Jay R. Ashworth Baylink jra at baylink.co > m > Designer The Things I Think RFC 210 > 0 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DI > I > St Petersburg FL USA #natog +1 727 647 127 > 4 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Sat Feb 23 13:36:08 2013 From: marka at isc.org (Mark Andrews) Date: Sun, 24 Feb 2013 00:36:08 +1100 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: Your message of "Fri, 22 Feb 2013 23:57:22 CDT." <29360005.6982.1361595442368.JavaMail.root@benjamin.baylink.com> References: <29360005.6982.1361595442368.JavaMail.root@benjamin.baylink.com> Message-ID: <20130223133608.BC18F3000AB0@drugs.dv.isc.org> For what it is worth I argued for removal of support for partially qualified domain names when looking at resolving the issues in RFC 1535. "ndots" was the compromise. I also argued for searches stopping on nodata responses. I felt and continue to feel both of these are security issues. If RFC 1535 came up today I believe that different decisions may have been made but give the political climate at the time that was the best I could get. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Sat Feb 23 13:37:27 2013 From: marka at isc.org (Mark Andrews) Date: Sun, 24 Feb 2013 00:37:27 +1100 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: Your message of "Fri, 22 Feb 2013 11:52:34 CDT." <24339470.6878.1361551954109.JavaMail.root@benjamin.baylink.com> References: <24339470.6878.1361551954109.JavaMail.root@benjamin.baylink.com> Message-ID: <20130223133727.6229B3000AF2@drugs.dv.isc.org> In message <24339470.6878.1361551954109.JavaMail.root at benjamin.baylink.com>, Ja y Ashworth writes: > ----- Original Message ----- > > From: "Mark Andrews" > > > RFC 952 as modified by RFC 1123 describe the legal syntax of a > > hostname. There is no trailing period. > > May someone create a "com" subdomain in a DNS domain you have to work in, > Mark. It wouldn't bother me. I use sane resolvers and don't use partially qualified names. > Or *course* the trailing dot matters, even if only due to the behavior > of DNS resolvers. > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.co > m > Designer The Things I Think RFC 210 > 0 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DI > I > St Petersburg FL USA #natog +1 727 647 127 > 4 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From asullivan at dyn.com Sat Feb 23 22:15:06 2013 From: asullivan at dyn.com (Andrew Sullivan) Date: Sat, 23 Feb 2013 17:15:06 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: References: <30545475.6952.1361592063875.JavaMail.root@benjamin.baylink.com> Message-ID: <20130223221506.GB4031@dyn.com> On Fri, Feb 22, 2013 at 10:26:58PM -0600, Jimmy Hess wrote: > > No trailing dot allowed; "each domain label starting and ending with > an alphanumerical character"; Note, however, that the URI specification actually contemplates the possibility of the host part being a dom-spec, and the names in that are able to be terminated with a dot. Or at least that's how I read it when I looked it up the other day. A -- Andrew Sullivan Dyn, Inc. asullivan at dyn.com v: +1 603 663 0448 From kmedcalf at dessus.com Sat Feb 23 22:53:03 2013 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 23 Feb 2013 15:53:03 -0700 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130223221506.GB4031@dyn.com> Message-ID: <4b40ea8fb0fa5740a5fe7d45cc735a55@mail.dessus.com> We can call them "rooted" domain names and "pwned" domain names... --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org > -----Original Message----- > From: Andrew Sullivan [mailto:asullivan at dyn.com] > Sent: Saturday, 23 February, 2013 15:15 > To: nanog at nanog.org > Subject: Re: looking for terminology recommendations concerning non-rooted > FQDNs > > On Fri, Feb 22, 2013 at 10:26:58PM -0600, Jimmy Hess wrote: > > > > No trailing dot allowed; "each domain label starting and ending with > > an alphanumerical character"; > > Note, however, that the URI specification actually contemplates the > possibility of the host part being a dom-spec, and the names in that > are able to be terminated with a dot. Or at least that's how I read > it when I looked it up the other day. > > A > > -- > Andrew Sullivan > Dyn, Inc. > asullivan at dyn.com > v: +1 603 663 0448 From deric.kwok2000 at gmail.com Sun Feb 24 17:00:58 2013 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Sun, 24 Feb 2013 12:00:58 -0500 Subject: can you share ipv6 addressallo cation In-Reply-To: <56982C89-3F69-41BD-9097-C1E268519D3D@delong.com> References: <56982C89-3F69-41BD-9097-C1E268519D3D@delong.com> Message-ID: Hi Owen and all Thank you so much for all info. I do have question about /126 or /64 as link to link After getting this http://www.clarksys.com/blog/2010/08/18/howto-subnet-ipv6-for-network-links/ Can I know what do you think? Can we say that to use /64 to replace /126 for network link? and what do you think the problem to use /64? The website said: If you refer back to the presentation I mentioned earlier there?s notes about the potential dangers of /64s on network links and why people intuitively want to subnet to a /127 or a /126. We ended up splitting the difference and actually subnetting the /64 for the network link to a /126. IPv6 is a very large pool of IP space ? to paraphrase my favorite quote so far ?IPv6 has 340 undecillion unique addresses (that?s a 39-digit number). If IPv4 is a golf ball IPv6 is the sun.? Trust me, don?t try to over think this. Just follow what all the RFCs say and use /64s for your network links. If you want to read more I found the following links to be very helpful in understanding how to properly subnet IPv6: Thank you so much On Wed, Feb 20, 2013 at 9:00 PM, Owen DeLong wrote: > First, if you are starting from a /32 and deciding how to carve it up from there, you are already approaching the problem backwards. > > The correct approach (general broad strokes) is to: > > 1. Identify your subnetting needs. > A. Infrastructure addressing > B. Internal IT needs within the company > C. Customer network needs (usually best to count the Infrastructure and Internal IT as n*customers at this point when > rolling this all up into a total number of subnets needed). > D. Decide on a customer end-site subnet size (unless this is an exceptional case, /48 is a good number to use) > > 2. Identify the natural aggregation points in your network. > > 3. Identify the number of /48s (or whatever other size you decided in D) needed > in your largest aggregation site. (This should be the sum of all subordinate > end-user networks as well as any infrastructure networks, etc. > > Round that up to a nibble boundary ensuring at least a 25% free space. > > 4. Identify the total number of aggregation points at the hierarchy level identified in (3) above. > > 5. Round that up to a nibble boundary as well. > > 6. Make a request for the prefix size determined by taking the number in 1D (/48) and > subtracting the number of bits identified in (3) and (5). e.g. your largest aggregation > point serves 50,000 customer end sites and you have 196 such aggregation points. > Each customer end-site is to receive a /48. > > 50,000 customer end-sites is 16-bits. To get a 25% min free, we must round up to 20. > This count includes 2 customer end-sites to support ISP infrastructure and internal IT > needs, respectively. > > 196 aggregation points is 8-bits. To get a 25% min free, we must round up to 12. > > 48-20=28-12=16 -- This network should request a /16 from their RIR. > > Notes: > > This is a severe oversimplification. Obviously more details will be required and the process must be adapted to each individual ISP's network topology and other considerations. > > Your first several iterations of addressing plan will be wrong. Accept it, deploy it, and expect to redo it a few times before you're completely happy with it. > > Plan big, deploy small the first few times so that you can learn lessons about the big plan while the deployments are still small. > > Owen > > On Feb 20, 2013, at 14:44 , Deric Kwok wrote: > >> Hi all >> >> I am searching information about ipv6 addressallocation for /32 >> >> Any experience and advice can be shared >> >> eg: loopback. peer to peer, >> >> Thank you so much > From jra at baylink.com Mon Feb 25 02:44:54 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 25 Feb 2013 02:44:54 GMT Subject: Facebook Expands Free Calling to Main iOS App Message-ID: <201302250244.r1P2isGi026742@web2.phonescoop.com> Check this out. Cheers, -- jra http://www.phonescoop.com/articles/article.php?a=11969 This email was sent via Phone Scoop (www.phonescoop.com). The sender thought you might be interested in the page linked above. From frnkblk at iname.com Mon Feb 25 04:56:38 2013 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 24 Feb 2013 22:56:38 -0600 Subject: 10 Mbit/s problem in your network In-Reply-To: References: <28915468.6329.1361118824719.JavaMail.root@benjamin.baylink.com> Message-ID: <000601ce1314$7eaec660$7c0c5320$@iname.com> The IEEE 802.11n standards do not require 5 GHz support. It's typical, but not necessary. Frank -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Sunday, February 17, 2013 2:07 PM To: Jay Ashworth Cc: NANOG Subject: Re: 10 Mbit/s problem in your network On Feb 17, 2013, at 08:33 , Jay Ashworth wrote: > ----- Original Message ----- >> From: "Scott Howard" > >>> A VPN or SSH session (which is what most hotel guests traveling for >>> work will do) won't cache at all well, so this is a very bad idea. >>> Might improve some things, but not the really important ones. >> >> The chances of the average hotel wifi user even knowing what SSH means >> is close to zero. > > {{citation-needed}} > >> As an aside, I was sitting in JFK airport (terminal 4) a few days ago and >> having a shocking time getting a good internet connection - even from my >> own Mifi. I fired up inSSIDer, and within a few seconds it had detected >> 122 AP's... > > Yup; B/G/N congestion is a real problem. Nice that the latest generation > of both mifi's and cellphones all seem to do A as well, in addition to > current-gen business laptops (my x61 is almost 5 years old, and speaks A). > I think by A you actually mean 5Ghz N. A doesn't do much better than G, though you still have the advantage of wider channels and less frequency congestion with other uses. Owen From glen.kent at gmail.com Mon Feb 25 08:23:13 2013 From: glen.kent at gmail.com (Glen Kent) Date: Mon, 25 Feb 2013 13:53:13 +0530 Subject: SDN - Killer Apps Message-ID: Hi, I am trying to understand how SDNs can dramatically change the networking paradigm and this is my understanding. Yahoo, Google, etc applications are running on one server and each application could be theoretically associated with a unique VXLAN tag. This way service providers will be able to provide QoS per application (by effectively providing QoS to the VXLAN carried in the pkts). So now Youtube for example, can get unique QoS treatment from our desktops to the edge of the network. Form there on core routing will pick up - which remains largely unaffected by VXLANs. OpenFlow is useful because it provides a common "CLI/SNMP" with which all routers from all vendors can be provisioned and monitored. As an example, VPLS configuration in Juniper, CIsco and AlaLu routers will be very different. So, provisioning a VPLS service in a network that comprises of these 3 vendors would require the admins to know the CLIs of all these routers. If these routers support OpenFlow, then theoretically, one configuration would work on all routers. OpenFlow would like say "Provision a LSP" and each router will internally provision an LSP. The admin remains oblivious to the internal CLIs of these boxes. The SDN controller is a SW that can again theoretically be made aware of the entire network. It can look at SNMP traps, etc and can figure out the exact topology of the network. Based on the SNMP traps, messages it can determine all failures in the network. It can run routing protocol simulations and figure out the best topology in the network. This can, using OpenFlow, be programmed on all routers. So, all heavy CPU processing task is taken over by the SDN controller. The controller can also take in requests on what network aware applications require and feed that to the routers/switches in the network and thus you have an application aware network provisioned. I understand that this is just some bit of what we can do with SDN. The amount of what all can be done is limitless. So, a question to all out there - Is my understanding of what can be achieved with SDN, is correct? Glen From simon.perreault at viagenie.ca Mon Feb 25 09:32:01 2013 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Mon, 25 Feb 2013 10:32:01 +0100 Subject: SDN - Killer Apps In-Reply-To: References: Message-ID: <512B2F91.3020107@viagenie.ca> Le 2013-02-25 09:23, Glen Kent a ?crit : > Yahoo, Google, etc applications are running on one server and each > application could be theoretically associated with a unique VXLAN tag. This > way service providers will be able to provide QoS per application (by > effectively providing QoS to the VXLAN carried in the pkts). So now Youtube > for example, can get unique QoS treatment from our desktops to the edge of > the network. Form there on core routing will pick up - which remains > largely unaffected by VXLANs. Uh? I'm pretty sure that QoS is *not* SDN's killer app. Simon From saku at ytti.fi Mon Feb 25 10:10:56 2013 From: saku at ytti.fi (Saku Ytti) Date: Mon, 25 Feb 2013 12:10:56 +0200 Subject: SDN - Killer Apps In-Reply-To: References: Message-ID: <20130225101056.GA30452@pob.ytti.fi> On (2013-02-25 13:53 +0530), Glen Kent wrote: > I understand that this is just some bit of what we can do with SDN. The > amount of what all can be done is limitless. So, a question to all out > there - Is my understanding of what can be achieved with SDN, is correct? Frankly I don't think there is single answer. >From my point of view I don't see much use for it as general purpose SP. Already second most common reason to outage is software defect, SDN will just reduce software MTBF and can potentially break lot really fast. I don't want to run some HP OV SDNd magic black box process deciding what happens to the network and I don't have the resources (or motivation) to custom develop the software. For researcher it seems really invaluable, you can test new protocols in real equipment. For GOOG/FB et.al. I can also see value, as I imagine their software stack is already very specialized, very home-grown. SDN can allow them to tie in network to their current VM/service orchestration tools, essentially making sure network and services share synchronous view of what should happen. -- ++ytti From reichert at numachi.com Mon Feb 25 14:30:34 2013 From: reichert at numachi.com (Brian Reichert) Date: Mon, 25 Feb 2013 09:30:34 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130223131021.498CA30008FF@drugs.dv.isc.org> References: <20130222171710.GB99258@numachi.com> <7446004.6892.1361554893925.JavaMail.root@benjamin.baylink.com> <20130222215502.GD99258@numachi.com> <20130223131021.498CA30008FF@drugs.dv.isc.org> Message-ID: <20130225143034.GN99258@numachi.com> On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote: > > When I did my initial development with OpenSSL, I observed: > > > > - If I did not have the rooted domain name in the SAN, then any SSL > > client stack would fail the verification if a rooted domain name > > was used to connect to the SSL server. > > Well you have a broken SSL client app. If it is accepting non legal > hostnames it should be normalising them before passing them to the ssl > layer. >From what little research I've done (only OpenSSL), the SSL client is relying on getaddrinfo(3) to do name resolution. In turn, I haven't found an implementation of getaddrinfo(3) that rejects rooted domain names as non-legal. Looking for couter-examples... > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -- Brian Reichert BSD admin/developer at large From jra at baylink.com Mon Feb 25 14:49:19 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 25 Feb 2013 09:49:19 -0500 (EST) Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: <20130225143034.GN99258@numachi.com> Message-ID: <15455394.7034.1361803759023.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brian Reichert" > On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote: [I believe this is Brian, then Mark: ] > > > When I did my initial development with OpenSSL, I observed: > > > > > > - If I did not have the rooted domain name in the SAN, then any SSL > > > client stack would fail the verification if a rooted domain name > > > was used to connect to the SSL server. > > > > Well you have a broken SSL client app. If it is accepting non legal > > hostnames it should be normalising them before passing them to the > > ssl layer. > > From what little research I've done (only OpenSSL), the SSL client > is relying on getaddrinfo(3) to do name resolution. In turn, I > haven't found an implementation of getaddrinfo(3) that rejects > rooted domain names as non-legal. Yes, but that's not the question, Brian, assuming I understand the problem as well as I think I do. The question is not how the client does the name resolution on the client machine -- it's what it does with the domain name it's looking up before doing the SSL interaction with the server side, a process with which I'm not familiar enough to know if the client actually send the host/domain name to the server end. Assuming it does -- and I am -- the question is: should it take the dot off. === More formally: "is a host/domain name with a trailing dot *actually a legal host name? Or is that merely local shorthand notation for resolvers and DNS server zone files, to define absoluteness. In short: are domain names on-the-wire *always* to be interpreted as absolute even in the absence of a trailing dot." My personal opinion, based on about 2 decades of watching from the outside, and of systems analysis and application design in non-internet contexts, is to say that yes, they must; there is *in fact* no reason for a relative domain name to leave a machine, since the context for it's relativity is dependent on the resolv.conf on that machine for lookups, and on which zone file it's in for service... and that the implication of that is that any application/library which takes a text-string host/domain name handed to it from off-machine ought to normalize away any trailing dot. I invite counter-arguments and -citations. :-) Cheers, -- jr 'yeah, I know, it's Monday' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From intensifysecurity at gmail.com Mon Feb 25 15:02:18 2013 From: intensifysecurity at gmail.com (Jeff Hartley) Date: Mon, 25 Feb 2013 10:02:18 -0500 Subject: SDN - Killer Apps In-Reply-To: References: Message-ID: On Mon, Feb 25, 2013 at 3:23 AM, Glen Kent wrote: > Yahoo, Google, etc applications are running on one server and each > application could be theoretically associated with a unique VXLAN tag. This > way service providers will be able to provide QoS per application (by > effectively providing QoS to the VXLAN carried in the pkts). So now Youtube > for example, can get unique QoS treatment from our desktops to the edge of > the network. Form there on core routing will pick up - which remains > largely unaffected by VXLANs. > > OpenFlow is useful because it provides a common "CLI/SNMP" with which all > routers from all vendors can be provisioned and monitored. As an example, > VPLS configuration in Juniper, CIsco and AlaLu routers will be very > different. So, provisioning a VPLS service in a network that comprises of > these 3 vendors would require the admins to know the CLIs of all these > routers. If these routers support OpenFlow, then theoretically, one > configuration would work on all routers. OpenFlow would like say "Provision > a LSP" and each router will internally provision an LSP. The admin remains > oblivious to the internal CLIs of these boxes. > > The SDN controller is a SW that can again theoretically be made aware of > the entire network. It can look at SNMP traps, etc and can figure out the > exact topology of the network. Based on the SNMP traps, messages it can > determine all failures in the network. It can run routing protocol > simulations and figure out the best topology in the network. This can, > using OpenFlow, be programmed on all routers. So, all heavy CPU processing > task is taken over by the SDN controller. The controller can also take in > requests on what network aware applications require and feed that to the > routers/switches in the network and thus you have an application aware > network provisioned. > > Glen Hi Glen; You've got a bit of "buzzword bingo" going on in those three paragraphs... Perhaps I can steer you in the right direction by categorizing and pointing you to some search topics.: VxLAN -- This is in the category of Overlay Networks. Check out the draft RFC, and search for terms like "VxLAN tutorial" or "VxLAN primer". Think "encapsulation" and "segmentation beyond 4k vlan tags." Don't confuse OpenFlow with VxLAN, although there's more than one use-case where either could theoretically be used. Note that VxLAN is just one of a few OLN protocols out there, and none of them have reached very far beyond the hype curve yet. OpenFlow vs. OpenStack -- The actual OpenStack project documentation is a great place to start here. Orchestration is another category with several competing efforts, so read as much as possible! SDN -- Consider this the broad category, but avoid overly broad terms like "SDN Controller" in favor of " controller" until you have the big picture filled in. For example, "OpenFlow Controller": There are plenty of docs to read on that specific subject, and there was a stellar tutorial for first-timers at the start of NANOG57. ...and lastly, the "killer apps": Don't bother researching this until you've covered the basics above. There are plenty of vendors and researchers out there doing the legwork on "killer SDN apps", but you'll want to understand all the underlying technologies first. -Jeff From jra at baylink.com Mon Feb 25 15:23:31 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 25 Feb 2013 10:23:31 -0500 (EST) Subject: What are you doing about Six Strikes? In-Reply-To: <20130224211616.GB15123@vortex.com> Message-ID: <28937159.7124.1361805811710.JavaMail.root@benjamin.baylink.com> This just in from Lauren Weinstein. This is, of course, today. Have people actually deployed changes to support this? Cheers, -- jra ----- Forwarded Message ----- > From: "PRIVACY Forum mailing list" > ISP six-strikes starts tomorrow, and the expected results are ... > > http://j.mp/W47lA7 (Torrent Freak) > > "The much-discussed U.S. six strikes anti-piracy scheme is expected to > go live on Monday. The start date hasn't been announced officially by > the CCI but a source close to the scheme confirmed the plans." > > - - - > > Expected results: > > 1) Legit users are harassed due to IP address mix-ups, etc. Remember > you must pay to file an appeal. > > 2) Proxy services see a massive up-tick in use. > > 3) Public Wi-Fi access points in small stores, etc. are decimated. > > 4) Relatively visible Torrent-based systems are even more rapidly > replaced with completely underground and well-hidden systems. > > 5) In relatively short order, the MPAA et al. will be back with their > Congressional supporters again demanding that the Internet be remade > to protect their obsolete 20th century profit center models, no > matter what the costs. > > --Lauren-- > Lauren Weinstein (lauren at vortex.com): http://www.vortex.com/lauren -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From bmanning at vacation.karoshi.com Mon Feb 25 15:25:55 2013 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 25 Feb 2013 15:25:55 +0000 Subject: can you share ipv6 addressallo cation In-Reply-To: References: <56982C89-3F69-41BD-9097-C1E268519D3D@delong.com> Message-ID: <20130225152555.GA7438@vacation.karoshi.com.> don't think of this in terms of waste (v6 has an unthinkable number of numbers) and think of security. by announceing more space than you are actually using, you create "dark-space" that attackers can hide in-plain-sight. so, for example, in your P2P links, you can use tools that lazy developers picked a near random number, a /64 as a constant, or you can reduce your attack surface by a) only announcing what your are actually using, in this case /126 for p2p links your call, your network, your inducced vulnerabilities. Your LIABILITY. /bill On Sun, Feb 24, 2013 at 12:00:58PM -0500, Deric Kwok wrote: > Hi Owen and all > > Thank you so much for all info. I do have question about /126 or /64 > as link to link > > After getting this > http://www.clarksys.com/blog/2010/08/18/howto-subnet-ipv6-for-network-links/ > > Can I know what do you think? > > Can we say that to use /64 to replace /126 for network link? > > and what do you think the problem to use /64? > > > The website said: > If you refer back to the presentation I mentioned earlier therebs > notes about the potential dangers of /64s on network links and why > people intuitively want to subnet to a /127 or a /126. We ended up > splitting the difference and actually subnetting the /64 for the > network link to a /126. > > IPv6 is a very large pool of IP space b to paraphrase my favorite > quote so far b IPv6 has 340 undecillion unique addresses (thatbs a > 39-digit number). If IPv4 is a golf ball IPv6 is the sun.b Trust me, > donbt try to over think this. Just follow what all the RFCs say and > use /64s for your network links. > > If you want to read more I found the following links to be very > helpful in understanding how to properly subnet IPv6: > > > Thank you so much > > > On Wed, Feb 20, 2013 at 9:00 PM, Owen DeLong wrote: > > First, if you are starting from a /32 and deciding how to carve it up from there, you are already approaching the problem backwards. > > > > The correct approach (general broad strokes) is to: > > > > 1. Identify your subnetting needs. > > A. Infrastructure addressing > > B. Internal IT needs within the company > > C. Customer network needs (usually best to count the Infrastructure and Internal IT as n*customers at this point when > > rolling this all up into a total number of subnets needed). > > D. Decide on a customer end-site subnet size (unless this is an exceptional case, /48 is a good number to use) > > > > 2. Identify the natural aggregation points in your network. > > > > 3. Identify the number of /48s (or whatever other size you decided in D) needed > > in your largest aggregation site. (This should be the sum of all subordinate > > end-user networks as well as any infrastructure networks, etc. > > > > Round that up to a nibble boundary ensuring at least a 25% free space. > > > > 4. Identify the total number of aggregation points at the hierarchy level identified in (3) above. > > > > 5. Round that up to a nibble boundary as well. > > > > 6. Make a request for the prefix size determined by taking the number in 1D (/48) and > > subtracting the number of bits identified in (3) and (5). e.g. your largest aggregation > > point serves 50,000 customer end sites and you have 196 such aggregation points. > > Each customer end-site is to receive a /48. > > > > 50,000 customer end-sites is 16-bits. To get a 25% min free, we must round up to 20. > > This count includes 2 customer end-sites to support ISP infrastructure and internal IT > > needs, respectively. > > > > 196 aggregation points is 8-bits. To get a 25% min free, we must round up to 12. > > > > 48-20=28-12=16 -- This network should request a /16 from their RIR. > > > > Notes: > > > > This is a severe oversimplification. Obviously more details will be required and the process must be adapted to each individual ISP's network topology and other considerations. > > > > Your first several iterations of addressing plan will be wrong. Accept it, deploy it, and expect to redo it a few times before you're completely happy with it. > > > > Plan big, deploy small the first few times so that you can learn lessons about the big plan while the deployments are still small. > > > > Owen > > > > On Feb 20, 2013, at 14:44 , Deric Kwok wrote: > > > >> Hi all > >> > >> I am searching information about ipv6 addressallocation for /32 > >> > >> Any experience and advice can be shared > >> > >> eg: loopback. peer to peer, > >> > >> Thank you so much > > > From reichert at numachi.com Mon Feb 25 15:56:49 2013 From: reichert at numachi.com (Brian Reichert) Date: Mon, 25 Feb 2013 10:56:49 -0500 Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: <15455394.7034.1361803759023.JavaMail.root@benjamin.baylink.com> References: <20130225143034.GN99258@numachi.com> <15455394.7034.1361803759023.JavaMail.root@benjamin.baylink.com> Message-ID: <20130225155649.GQ99258@numachi.com> On Mon, Feb 25, 2013 at 09:49:19AM -0500, Jay Ashworth wrote: > ----- Original Message ----- > > From: "Brian Reichert" > > > On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote: > [I believe this is Brian, then Mark: ] > > > > When I did my initial development with OpenSSL, I observed: > > > > > > > > - If I did not have the rooted domain name in the SAN, then any SSL > > > > client stack would fail the verification if a rooted domain name > > > > was used to connect to the SSL server. > > > > > > Well you have a broken SSL client app. If it is accepting non legal > > > hostnames it should be normalising them before passing them to the > > > ssl layer. > > > > From what little research I've done (only OpenSSL), the SSL client > > is relying on getaddrinfo(3) to do name resolution. In turn, I > > haven't found an implementation of getaddrinfo(3) that rejects > > rooted domain names as non-legal. > > Yes, but that's not the question, Brian, assuming I understand the problem > as well as I think I do. The question is not how the client does the > name resolution on the client machine -- it's what it does with the domain > name it's looking up before doing the SSL interaction with the server side, > a process with which I'm not familiar enough to know if the client actually > send the host/domain name to the server end. Assuming it does -- and I > am -- the question is: should it take the dot off. My understanding is this: Unless you're doing client certificate verification (wherein the server is making decisions about which clients attempting a connection), all validation/verification is done by the client. The SSL client retrieves the server's certificate, and the set of values in the Subject and the Subject Alternative Name is compared against the hostname/IP address used to initiate the process. This comparison is (to my understanding) straight-forward (modulo UTF8 encodings, etc.). The upshot (assuming I'm not totally off base here), is that other than getaddrinfo(), nothing is acting on the semantics of the supplied hostname (or IP address). They are 'just strings', and are (essentially) compared as such. > Cheers, > -- jr 'yeah, I know, it's Monday' a > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 -- Brian Reichert BSD admin/developer at large From jra at baylink.com Mon Feb 25 16:26:47 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 25 Feb 2013 11:26:47 -0500 (EST) Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: <20130225155649.GQ99258@numachi.com> Message-ID: <3520994.7144.1361809607617.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brian Reichert" > My understanding is this: > > Unless you're doing client certificate verification (wherein the > server is making decisions about which clients attempting a > connection), all validation/verification is done by the client. Right; my apologies; I know better than to post Before Coffee. :-) > The SSL client retrieves the server's certificate, and the set of > values in the Subject and the Subject Alternative Name is compared > against the hostname/IP address used to initiate the process. This > comparison is (to my understanding) straight-forward (modulo UTF8 > encodings, etc.). > > The upshot (assuming I'm not totally off base here), is that other > than getaddrinfo(), nothing is acting on the semantics of the > supplied hostname (or IP address). They are 'just strings', and > are (essentially) compared as such. Right. And I'm asserting that that's wrong: the client side libraries Really Ought To normalize that name before trying to compare it against the retrieved certificate to see if it matches, which would relieve you of having to have the altName with the trailing dot in such a cert. The controlling standard *appears* to be RFC 2246, TLS v1.0. I'm doing some work this morning, but that's up in a tab for coffee breaks; I'll try to figure out what I think Dierks and Allen thought about this topic, if anything, during the day. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From owen at delong.com Mon Feb 25 16:34:09 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Feb 2013 08:34:09 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: <000601ce1314$7eaec660$7c0c5320$@iname.com> References: <28915468.6329.1361118824719.JavaMail.root@benjamin.baylink.com> <000601ce1314$7eaec660$7c0c5320$@iname.com> Message-ID: <6D4636E8-F773-423D-8C80-A84B9851B181@delong.com> Correct. However, while A is 5Ghz (only), it's not significantly better than G. The true performance gains come from 5Ghz and N together. N on 2.4Ghz has limited benefit over G. N on 5Ghz is significantly better. Owen On Feb 24, 2013, at 8:56 PM, "Frank Bulk" wrote: > The IEEE 802.11n standards do not require 5 GHz support. It's typical, but > not necessary. > > Frank > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Sunday, February 17, 2013 2:07 PM > To: Jay Ashworth > Cc: NANOG > Subject: Re: 10 Mbit/s problem in your network > > > On Feb 17, 2013, at 08:33 , Jay Ashworth wrote: > >> ----- Original Message ----- >>> From: "Scott Howard" >> >>>> A VPN or SSH session (which is what most hotel guests traveling for >>>> work will do) won't cache at all well, so this is a very bad idea. >>>> Might improve some things, but not the really important ones. >>> >>> The chances of the average hotel wifi user even knowing what SSH means >>> is close to zero. >> >> {{citation-needed}} >> >>> As an aside, I was sitting in JFK airport (terminal 4) a few days ago and >>> having a shocking time getting a good internet connection - even from my >>> own Mifi. I fired up inSSIDer, and within a few seconds it had detected >>> 122 AP's... >> >> Yup; B/G/N congestion is a real problem. Nice that the latest generation >> of both mifi's and cellphones all seem to do A as well, in addition to >> current-gen business laptops (my x61 is almost 5 years old, and speaks A). >> > > I think by A you actually mean 5Ghz N. A doesn't do much better than G, > though > you still have the advantage of wider channels and less frequency congestion > with other uses. > > Owen > > > > From schoen at loyalty.org Mon Feb 25 16:37:22 2013 From: schoen at loyalty.org (Seth David Schoen) Date: Mon, 25 Feb 2013 08:37:22 -0800 Subject: What are you doing about Six Strikes? In-Reply-To: <28937159.7124.1361805811710.JavaMail.root@benjamin.baylink.com> References: <20130224211616.GB15123@vortex.com> <28937159.7124.1361805811710.JavaMail.root@benjamin.baylink.com> Message-ID: <20130225163721.GG8791@frotz.zork.net> Jay Ashworth writes: > This just in from Lauren Weinstein. This is, of course, today. > > Have people actually deployed changes to support this? Six Strikes is not a law; it's a private agreement. http://www.scribd.com/doc/91987640/CCI-MOU -- Seth David Schoen | No haiku patents http://www.loyalty.org/~schoen/ | means I've no incentive to FD9A6AA28193A9F03D4BF4ADC11B36DC9C7DD150 | -- Don Marti From wbailey at satelliteintelligencegroup.com Mon Feb 25 16:42:01 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 25 Feb 2013 16:42:01 +0000 Subject: 10 Mbit/s problem in your network In-Reply-To: <6D4636E8-F773-423D-8C80-A84B9851B181@delong.com> References: <28915468.6329.1361118824719.JavaMail.root@benjamin.baylink.com> <000601ce1314$7eaec660$7c0c5320$@iname.com>, <6D4636E8-F773-423D-8C80-A84B9851B181@delong.com> Message-ID: I should probably know this, but doesn't N just spread better and have the ability to send receive on multiple polarizations? As an RF engineer I should probably know this, but I can't think of many people in my industry who really care about 802.11_. I really don't even use wireless in my house, though it's generally due to overcrowding the spectrum in populous areas. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Owen DeLong Date: 02/25/2013 8:38 AM (GMT-08:00) To: Frank Bulk Cc: NANOG Subject: Re: 10 Mbit/s problem in your network Correct. However, while A is 5Ghz (only), it's not significantly better than G. The true performance gains come from 5Ghz and N together. N on 2.4Ghz has limited benefit over G. N on 5Ghz is significantly better. Owen On Feb 24, 2013, at 8:56 PM, "Frank Bulk" wrote: > The IEEE 802.11n standards do not require 5 GHz support. It's typical, but > not necessary. > > Frank > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Sunday, February 17, 2013 2:07 PM > To: Jay Ashworth > Cc: NANOG > Subject: Re: 10 Mbit/s problem in your network > > > On Feb 17, 2013, at 08:33 , Jay Ashworth wrote: > >> ----- Original Message ----- >>> From: "Scott Howard" >> >>>> A VPN or SSH session (which is what most hotel guests traveling for >>>> work will do) won't cache at all well, so this is a very bad idea. >>>> Might improve some things, but not the really important ones. >>> >>> The chances of the average hotel wifi user even knowing what SSH means >>> is close to zero. >> >> {{citation-needed}} >> >>> As an aside, I was sitting in JFK airport (terminal 4) a few days ago and >>> having a shocking time getting a good internet connection - even from my >>> own Mifi. I fired up inSSIDer, and within a few seconds it had detected >>> 122 AP's... >> >> Yup; B/G/N congestion is a real problem. Nice that the latest generation >> of both mifi's and cellphones all seem to do A as well, in addition to >> current-gen business laptops (my x61 is almost 5 years old, and speaks A). >> > > I think by A you actually mean 5Ghz N. A doesn't do much better than G, > though > you still have the advantage of wider channels and less frequency congestion > with other uses. > > Owen > > > > From reichert at numachi.com Mon Feb 25 16:30:07 2013 From: reichert at numachi.com (Brian Reichert) Date: Mon, 25 Feb 2013 11:30:07 -0500 Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: <3520994.7144.1361809607617.JavaMail.root@benjamin.baylink.com> References: <20130225155649.GQ99258@numachi.com> <3520994.7144.1361809607617.JavaMail.root@benjamin.baylink.com> Message-ID: <20130225163007.GS99258@numachi.com> On Mon, Feb 25, 2013 at 11:26:47AM -0500, Jay Ashworth wrote: > > The upshot (assuming I'm not totally off base here), is that other > > than getaddrinfo(), nothing is acting on the semantics of the > > supplied hostname (or IP address). They are 'just strings', and > > are (essentially) compared as such. > > Right. And I'm asserting that that's wrong: the client side libraries > Really Ought To normalize that name before trying to compare it against > the retrieved certificate to see if it matches, which would relieve you > of having to have the altName with the trailing dot in such a cert. I know for internal testing, I've had to introduce unqualified hostnames in the CSR as well (e.g. 'testhost', instead of 'testhost.example.com'), to handle the case of the client not using domain names at all (when framing queries). This illustrates that there's not even an effort to synthesize a FQDN. Who should implement the normalization logic? Not the SSL library, certainly. That sounds like the bailiwick of the resolver library... > The controlling standard *appears* to be RFC 2246, TLS v1.0. I'm doing > some work this morning, but that's up in a tab for coffee breaks; I'll > try to figure out what I think Dierks and Allen thought about this topic, > if anything, during the day. I look forward to the fruits of your research. :) > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 -- Brian Reichert BSD admin/developer at large From owen at delong.com Mon Feb 25 16:47:44 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Feb 2013 08:47:44 -0800 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130225143034.GN99258@numachi.com> References: <20130222171710.GB99258@numachi.com> <7446004.6892.1361554893925.JavaMail.root@benjamin.baylink.com> <20130222215502.GD99258@numachi.com> <20130223131021.498CA30008FF@drugs.dv.isc.org> <20130225143034.GN99258@numachi.com> Message-ID: <74F5F4AD-935B-442D-86CC-9CB19B880123@delong.com> On Feb 25, 2013, at 6:30 AM, Brian Reichert wrote: > On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote: >>> When I did my initial development with OpenSSL, I observed: >>> >>> - If I did not have the rooted domain name in the SAN, then any SSL >>> client stack would fail the verification if a rooted domain name >>> was used to connect to the SSL server. >> >> Well you have a broken SSL client app. If it is accepting non legal >> hostnames it should be normalising them before passing them to the ssl >> layer. > >> From what little research I've done (only OpenSSL), the SSL client > is relying on getaddrinfo(3) to do name resolution. In turn, I > haven't found an implementation of getaddrinfo(3) that rejects > rooted domain names as non-legal. > getaddrinfo should not reject foo.blah.com. or foo.blah.com. However, it will use the data? foo.blah.com will have the domain search strings (if any) appended, so for example, if your search configuration is "blah.com, example.com", then it will search for foo.blah.com.blah.com., foo.blah.com.example.com., and foo.blah.com. until it finds a match. However, that's for the resolver library. In terms of matching the CN in a certificate, this should always be FQDN and the trailing dot should not be present. If OpenSSL (the command line tool) is passing foo.blah.com. to the SSL functions and not just getaddrinfo(), then, it is a bug. Owen From dmiller at tiggee.com Mon Feb 25 16:55:53 2013 From: dmiller at tiggee.com (David Miller) Date: Mon, 25 Feb 2013 11:55:53 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <74F5F4AD-935B-442D-86CC-9CB19B880123@delong.com> References: <20130222171710.GB99258@numachi.com> <7446004.6892.1361554893925.JavaMail.root@benjamin.baylink.com> <20130222215502.GD99258@numachi.com> <20130223131021.498CA30008FF@drugs.dv.isc.org> <20130225143034.GN99258@numachi.com> <74F5F4AD-935B-442D-86CC-9CB19B880123@delong.com> Message-ID: <512B9799.6000203@tiggee.com> On 02/25/2013 11:47 AM, Owen DeLong wrote: > On Feb 25, 2013, at 6:30 AM, Brian Reichert wrote: > >> On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote: >>>> When I did my initial development with OpenSSL, I observed: >>>> >>>> - If I did not have the rooted domain name in the SAN, then any SSL >>>> client stack would fail the verification if a rooted domain name >>>> was used to connect to the SSL server. >>> Well you have a broken SSL client app. If it is accepting non legal >>> hostnames it should be normalising them before passing them to the ssl >>> layer. >>> From what little research I've done (only OpenSSL), the SSL client >> is relying on getaddrinfo(3) to do name resolution. In turn, I >> haven't found an implementation of getaddrinfo(3) that rejects >> rooted domain names as non-legal. >> > getaddrinfo should not reject foo.blah.com. or foo.blah.com. However, > it will use the data? foo.blah.com will have the domain search strings > (if any) appended, so for example, if your search configuration is > "blah.com, example.com", then it will search for foo.blah.com.blah.com., > foo.blah.com.example.com., and foo.blah.com. until it finds a match. The lookup order should be foo.blah.com, foo.blah.com.blah.com, foo.blah.com.example.com ? > > However, that's for the resolver library. In terms of matching the CN > in a certificate, this should always be FQDN and the trailing dot > should not be present. If OpenSSL (the command line tool) is passing > foo.blah.com. to the SSL functions and not just getaddrinfo(), then, > it is a bug. > > > Owen > > -- -______________________ David Miller dmiller at tiggee.com From owen at delong.com Mon Feb 25 16:56:05 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Feb 2013 08:56:05 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: References: <28915468.6329.1361118824719.JavaMail.root@benjamin.baylink.com> <000601ce1314$7eaec660$7c0c5320$@iname.com>, <6D4636E8-F773-423D-8C80-A84B9851B181@delong.com> Message-ID: N has a number of advantages? Better spread, the ability to take advantage of polarization, better use of MIMO, and IIRC, a better encoding scheme that allows denser constellation points (more bits per signaling element). N on 5Ghz takes advantage of the increased bandwidth of the 5Ghz channel where A merely replicated G on 5Ghz for all practical purposes. Owen On Feb 25, 2013, at 8:42 AM, Warren Bailey wrote: > I should probably know this, but doesn't N just spread better and have the ability to send receive on multiple polarizations? As an RF engineer I should probably know this, but I can't think of many people in my industry who really care about 802.11_. I really don't even use wireless in my house, though it's generally due to overcrowding the spectrum in populous areas. > > > From my Android phone on T-Mobile. The first nationwide 4G network. > > > > -------- Original message -------- > From: Owen DeLong > Date: 02/25/2013 8:38 AM (GMT-08:00) > To: Frank Bulk > Cc: NANOG > Subject: Re: 10 Mbit/s problem in your network > > > Correct. However, while A is 5Ghz (only), it's not significantly better than G. > > The true performance gains come from 5Ghz and N together. N on 2.4Ghz has > limited benefit over G. N on 5Ghz is significantly better. > > Owen > > On Feb 24, 2013, at 8:56 PM, "Frank Bulk" wrote: > > > The IEEE 802.11n standards do not require 5 GHz support. It's typical, but > > not necessary. > > > > Frank > > > > -----Original Message----- > > From: Owen DeLong [mailto:owen at delong.com] > > Sent: Sunday, February 17, 2013 2:07 PM > > To: Jay Ashworth > > Cc: NANOG > > Subject: Re: 10 Mbit/s problem in your network > > > > > > On Feb 17, 2013, at 08:33 , Jay Ashworth wrote: > > > >> ----- Original Message ----- > >>> From: "Scott Howard" > >> > >>>> A VPN or SSH session (which is what most hotel guests traveling for > >>>> work will do) won't cache at all well, so this is a very bad idea. > >>>> Might improve some things, but not the really important ones. > >>> > >>> The chances of the average hotel wifi user even knowing what SSH means > >>> is close to zero. > >> > >> {{citation-needed}} > >> > >>> As an aside, I was sitting in JFK airport (terminal 4) a few days ago and > >>> having a shocking time getting a good internet connection - even from my > >>> own Mifi. I fired up inSSIDer, and within a few seconds it had detected > >>> 122 AP's... > >> > >> Yup; B/G/N congestion is a real problem. Nice that the latest generation > >> of both mifi's and cellphones all seem to do A as well, in addition to > >> current-gen business laptops (my x61 is almost 5 years old, and speaks A). > >> > > > > I think by A you actually mean 5Ghz N. A doesn't do much better than G, > > though > > you still have the advantage of wider channels and less frequency congestion > > with other uses. > > > > Owen > > > > > > > > From jra at baylink.com Mon Feb 25 17:11:48 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 25 Feb 2013 12:11:48 -0500 (EST) Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: <20130225163007.GS99258@numachi.com> Message-ID: <7370441.7160.1361812308247.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brian Reichert" > > Right. And I'm asserting that that's wrong: the client side libraries > > Really Ought To normalize that name before trying to compare it against > > the retrieved certificate to see if it matches, which would relieve you > > of having to have the altName with the trailing dot in such a cert. > > I know for internal testing, I've had to introduce unqualified > hostnames in the CSR as well (e.g. 'testhost', instead of > 'testhost.example.com'), to handle the case of the client not using > domain names at all (when framing queries). This illustrates that > there's not even an effort to synthesize a FQDN. And there probably shouldn't be, and yes, you will probably have to have short names in there as altnames; there isn't -- and again, cannot be -- a rule for that; it's implementation dependent. > Who should implement the normalization logic? Not the SSL library, > certainly. That sounds like the bailiwick of the resolver library... No, in fact, I think this is layer... 3 or 4, not 2; this *should* be in the SSL library -- *you're not resolving this name*. > > The controlling standard *appears* to be RFC 2246, TLS v1.0. I'm > > doing > > some work this morning, but that's up in a tab for coffee breaks; > > I'll > > try to figure out what I think Dierks and Allen thought about this > > topic, > > if anything, during the day. > > I look forward to the fruits of your research. :) Pomegranates. Martha Stewart taught me over the weekend how to get the seeds out without ruining them. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Mon Feb 25 17:18:00 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 25 Feb 2013 12:18:00 -0500 (EST) Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <74F5F4AD-935B-442D-86CC-9CB19B880123@delong.com> Message-ID: <24025524.7172.1361812680297.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > However, that's for the resolver library. In terms of matching the CN > in a certificate, this should always be FQDN and the trailing dot > should not be present. If OpenSSL (the command line tool) is passing > foo.blah.com. to the SSL functions and not just getaddrinfo(), then, > it is a bug. If I understood Brian correctly, his problem is that people/programs are trying to retrieve things from, eg: https://my.host.name./this/is/a/path and the SSL library fails the certificate match if the cert doesn't contain the absolute domain name as an altName -- because *the browser* (or whatever) does not normalize before calling the library. As I suggest in another thread, I think the SSL library probably ought to be normalizing off that trailing dot itself, before trying to match the string supplied to the names in the retrieved cert. It sounds as if you might agree with me, at least in principle. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From joesox at gmail.com Mon Feb 25 17:22:41 2013 From: joesox at gmail.com (JoeSox) Date: Mon, 25 Feb 2013 09:22:41 -0800 Subject: Circuit Bandwidth Simulator applet etc Message-ID: I would like a applet or program I can feed it nodes and a network topology, then just set hypothetical transmit speeds at child nodes then have the applet or program display the Parent node bandwidth. Is there any Visio applets or macros out there I wonder? Sorry another tool question but I don't want to start coding something up if I don't have to. I use NetDot but I don't think it has any circuit bandwidth tools like that. I have used GNS3 in the past but that is way more complex for this need I have. -- Thanks, Joe From mloftis at wgops.com Mon Feb 25 17:32:40 2013 From: mloftis at wgops.com (Michael Loftis) Date: Mon, 25 Feb 2013 09:32:40 -0800 Subject: Circuit Bandwidth Simulator applet etc In-Reply-To: References: Message-ID: Try http://www.nsnam.org/ (AKA NS2/NS3) whichis GPL/OSS or Tetcos NetSim - http://tetcos.com/ I've never used NetSim FYI, just heard of it. And NS only rarely. On Mon, Feb 25, 2013 at 9:22 AM, JoeSox wrote: > I would like a applet or program I can feed it nodes and a network > topology, then just set hypothetical transmit speeds at child nodes > then have the applet or program display the Parent node bandwidth. Is > there any Visio applets or macros out there I wonder? > > Sorry another tool question but I don't want to start coding something > up if I don't have to. > I use NetDot but I don't think it has any circuit bandwidth tools like > that. I have used GNS3 in the past but that is way more complex for > this need I have. > -- > Thanks, Joe > -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From owen at delong.com Mon Feb 25 17:38:11 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Feb 2013 09:38:11 -0800 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <24025524.7172.1361812680297.JavaMail.root@benjamin.baylink.com> References: <24025524.7172.1361812680297.JavaMail.root@benjamin.baylink.com> Message-ID: <3392837B-86E1-4D01-8E3E-5862E8EED2B6@delong.com> On Feb 25, 2013, at 9:18 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> However, that's for the resolver library. In terms of matching the CN >> in a certificate, this should always be FQDN and the trailing dot >> should not be present. If OpenSSL (the command line tool) is passing >> foo.blah.com. to the SSL functions and not just getaddrinfo(), then, >> it is a bug. > > If I understood Brian correctly, his problem is that people/programs > are trying to retrieve things from, eg: > > https://my.host.name./this/is/a/path > > and the SSL library fails the certificate match if the cert doesn't contain > the absolute domain name as an altName -- because *the browser* (or whatever) > does not normalize before calling the library. > > As I suggest in another thread, I think the SSL library probably ought to > be normalizing off that trailing dot itself, before trying to match the > string supplied to the names in the retrieved cert. > > It sounds as if you might agree with me, at least in principle. > I don't see any reason that the SSL library shouldn't normalize the name and remove the trailing dot. However, even if the SSL library does so, I see no valid reason that would relieve the browser of the obligation to do so as well. Be conservative in what you send (or pass to a library) and liberal in what you accept. Under that principle, the SSL library should accept either one and normalize it. However, the browser should also normalize what it passes to the SSL library. Owen From wbailey at satelliteintelligencegroup.com Mon Feb 25 17:47:55 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 25 Feb 2013 17:47:55 +0000 Subject: 10 Mbit/s problem in your network In-Reply-To: Message-ID: If you want to see something pretty amazing, check this out.. http://www.popsci.com/science/article/2012-06/twisting-signals-vortex-researchers-beam-25-terabits-data-second These guys got close to 100 bits/hz using Orbital Angular Momentum in addition to the normal Spin Angular Momentum. There is a picture out there of the I/Q showing the constellation, which to me looks like the future of communications systems. In my world, if you could offer 5 bits/hz or higher you would very likely be able to retire on your own island. Space segment for satellite systems can cost as much as 175k for 36MHz, so giving someone a 20x bandwidth increase would be an absolute game changer. Don't be surprised if you see the 802.11 guys trying to figure out how to make OAM work, it would essentially solve the worlds bandwidth problems at nearly all frequencies. From: Owen DeLong > Date: Mon, 25 Feb 2013 08:56:05 -0800 To: User > Cc: Frank Bulk >, NANOG > Subject: Re: 10 Mbit/s problem in your network N has a number of advantages? Better spread, the ability to take advantage of polarization, better use of MIMO, and IIRC, a better encoding scheme that allows denser constellation points (more bits per signaling element). N on 5Ghz takes advantage of the increased bandwidth of the 5Ghz channel where A merely replicated G on 5Ghz for all practical purposes. Owen On Feb 25, 2013, at 8:42 AM, Warren Bailey > wrote: I should probably know this, but doesn't N just spread better and have the ability to send receive on multiple polarizations? As an RF engineer I should probably know this, but I can't think of many people in my industry who really care about 802.11_. I really don't even use wireless in my house, though it's generally due to overcrowding the spectrum in populous areas. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Owen DeLong > Date: 02/25/2013 8:38 AM (GMT-08:00) To: Frank Bulk > Cc: NANOG > Subject: Re: 10 Mbit/s problem in your network Correct. However, while A is 5Ghz (only), it's not significantly better than G. The true performance gains come from 5Ghz and N together. N on 2.4Ghz has limited benefit over G. N on 5Ghz is significantly better. Owen On Feb 24, 2013, at 8:56 PM, "Frank Bulk" > wrote: > The IEEE 802.11n standards do not require 5 GHz support. It's typical, but > not necessary. > > Frank > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Sunday, February 17, 2013 2:07 PM > To: Jay Ashworth > Cc: NANOG > Subject: Re: 10 Mbit/s problem in your network > > > On Feb 17, 2013, at 08:33 , Jay Ashworth > wrote: > >> ----- Original Message ----- >>> From: "Scott Howard" > >> >>>> A VPN or SSH session (which is what most hotel guests traveling for >>>> work will do) won't cache at all well, so this is a very bad idea. >>>> Might improve some things, but not the really important ones. >>> >>> The chances of the average hotel wifi user even knowing what SSH means >>> is close to zero. >> >> {{citation-needed}} >> >>> As an aside, I was sitting in JFK airport (terminal 4) a few days ago and >>> having a shocking time getting a good internet connection - even from my >>> own Mifi. I fired up inSSIDer, and within a few seconds it had detected >>> 122 AP's... >> >> Yup; B/G/N congestion is a real problem. Nice that the latest generation >> of both mifi's and cellphones all seem to do A as well, in addition to >> current-gen business laptops (my x61 is almost 5 years old, and speaks A). >> > > I think by A you actually mean 5Ghz N. A doesn't do much better than G, > though > you still have the advantage of wider channels and less frequency congestion > with other uses. > > Owen > > > > From wbailey at satelliteintelligencegroup.com Mon Feb 25 17:48:46 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 25 Feb 2013 17:48:46 +0000 Subject: Circuit Bandwidth Simulator applet etc In-Reply-To: Message-ID: We use IXChariot for traffic simulation. It's pretty nice, albeit expensive. On 2/25/13 9:22 AM, "JoeSox" wrote: >I would like a applet or program I can feed it nodes and a network >topology, then just set hypothetical transmit speeds at child nodes >then have the applet or program display the Parent node bandwidth. Is >there any Visio applets or macros out there I wonder? > >Sorry another tool question but I don't want to start coding something >up if I don't have to. >I use NetDot but I don't think it has any circuit bandwidth tools like >that. I have used GNS3 in the past but that is way more complex for >this need I have. >-- >Thanks, Joe > > From joelja at bogus.com Mon Feb 25 17:55:47 2013 From: joelja at bogus.com (joel jaeggli) Date: Mon, 25 Feb 2013 09:55:47 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: References: <28915468.6329.1361118824719.JavaMail.root@benjamin.baylink.com> <000601ce1314$7eaec660$7c0c5320$@iname.com>, <6D4636E8-F773-423D-8C80-A84B9851B181@delong.com> Message-ID: <512BA5A3.5010005@bogus.com> On 2/25/13 8:42 AM, Warren Bailey wrote: > I should probably know this, but doesn't N just spread better and have the ability to send receive on multiple polarizations? That would be a rather extreme over-simplifcation of spatial-division-multiplexing and space-time-coding. > As an RF engineer I should probably know this, but I can't think of many people in my industry who really care about 802.11_. I really don't even use wireless in my house, though it's generally due to overcrowding the spectrum in populous areas. > > > From my Android phone on T-Mobile. The first nationwide 4G network. > > > > -------- Original message -------- > From: Owen DeLong > Date: 02/25/2013 8:38 AM (GMT-08:00) > To: Frank Bulk > Cc: NANOG > Subject: Re: 10 Mbit/s problem in your network > > > Correct. However, while A is 5Ghz (only), it's not significantly better than G. > > The true performance gains come from 5Ghz and N together. N on 2.4Ghz has > limited benefit over G. N on 5Ghz is significantly better. > > Owen > > On Feb 24, 2013, at 8:56 PM, "Frank Bulk" wrote: > >> The IEEE 802.11n standards do not require 5 GHz support. It's typical, but >> not necessary. >> >> Frank >> >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Sunday, February 17, 2013 2:07 PM >> To: Jay Ashworth >> Cc: NANOG >> Subject: Re: 10 Mbit/s problem in your network >> >> >> On Feb 17, 2013, at 08:33 , Jay Ashworth wrote: >> >>> ----- Original Message ----- >>>> From: "Scott Howard" >>>>> A VPN or SSH session (which is what most hotel guests traveling for >>>>> work will do) won't cache at all well, so this is a very bad idea. >>>>> Might improve some things, but not the really important ones. >>>> The chances of the average hotel wifi user even knowing what SSH means >>>> is close to zero. >>> {{citation-needed}} >>> >>>> As an aside, I was sitting in JFK airport (terminal 4) a few days ago and >>>> having a shocking time getting a good internet connection - even from my >>>> own Mifi. I fired up inSSIDer, and within a few seconds it had detected >>>> 122 AP's... >>> Yup; B/G/N congestion is a real problem. Nice that the latest generation >>> of both mifi's and cellphones all seem to do A as well, in addition to >>> current-gen business laptops (my x61 is almost 5 years old, and speaks A). >>> >> I think by A you actually mean 5Ghz N. A doesn't do much better than G, >> though >> you still have the advantage of wider channels and less frequency congestion >> with other uses. >> >> Owen >> >> >> >> > > > From reichert at numachi.com Mon Feb 25 17:49:41 2013 From: reichert at numachi.com (Brian Reichert) Date: Mon, 25 Feb 2013 12:49:41 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <24025524.7172.1361812680297.JavaMail.root@benjamin.baylink.com> References: <74F5F4AD-935B-442D-86CC-9CB19B880123@delong.com> <24025524.7172.1361812680297.JavaMail.root@benjamin.baylink.com> Message-ID: <20130225174941.GT99258@numachi.com> On Mon, Feb 25, 2013 at 12:18:00PM -0500, Jay Ashworth wrote: > If I understood Brian correctly, his problem is that people/programs > are trying to retrieve things from, eg: > > https://my.host.name./this/is/a/path > > and the SSL library fails the certificate match if the cert doesn't contain > the absolute domain name as an altName -- because *the browser* (or whatever) > does not normalize before calling the library. I'd argue that if you have an absolute domain name, then that _is_ the 'normalized' form of the domain name; it's an unambigious representation of the domain name. (Here, I'm treating the string as a serialized data structure.) Choosing to remove the notion of "this is rooted", and then asking any (all?) other layers to handle the introduced ambiguity sounds like setting yourself up for the issues that RFC 1535 was drawing attention to. > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII > St Petersburg FL USA #natog +1 727 647 1274 -- Brian Reichert BSD admin/developer at large From joly at punkcast.com Mon Feb 25 18:05:48 2013 From: joly at punkcast.com (Joly MacFie) Date: Mon, 25 Feb 2013 13:05:48 -0500 Subject: What are you doing about Six Strikes? In-Reply-To: <20130225163721.GG8791@frotz.zork.net> References: <20130224211616.GB15123@vortex.com> <28937159.7124.1361805811710.JavaMail.root@benjamin.baylink.com> <20130225163721.GG8791@frotz.zork.net> Message-ID: Who said it's a law? On Mon, Feb 25, 2013 at 11:37 AM, Seth David Schoen wrote: > Jay Ashworth writes: > >> This just in from Lauren Weinstein. This is, of course, today. >> >> Have people actually deployed changes to support this? > > Six Strikes is not a law; it's a private agreement. > > http://www.scribd.com/doc/91987640/CCI-MOU > > -- > Seth David Schoen | No haiku patents > http://www.loyalty.org/~schoen/ | means I've no incentive to > FD9A6AA28193A9F03D4BF4ADC11B36DC9C7DD150 | -- Don Marti > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From dougb at dougbarton.us Mon Feb 25 18:10:55 2013 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 25 Feb 2013 10:10:55 -0800 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130225174941.GT99258@numachi.com> References: <74F5F4AD-935B-442D-86CC-9CB19B880123@delong.com> <24025524.7172.1361812680297.JavaMail.root@benjamin.baylink.com> <20130225174941.GT99258@numachi.com> Message-ID: <512BA92F.7090703@dougbarton.us> On 02/25/2013 09:49 AM, Brian Reichert wrote: > On Mon, Feb 25, 2013 at 12:18:00PM -0500, Jay Ashworth wrote: >> If I understood Brian correctly, his problem is that people/programs >> are trying to retrieve things from, eg: >> >> https://my.host.name./this/is/a/path >> >> and the SSL library fails the certificate match if the cert doesn't contain >> the absolute domain name as an altName -- because *the browser* (or whatever) >> does not normalize before calling the library. > > I'd argue that if you have an absolute domain name, then that _is_ > the 'normalized' form of the domain name; it's an unambigious > representation of the domain name. (Here, I'm treating the string > as a serialized data structure.) > > Choosing to remove the notion of "this is rooted", and then asking > any (all?) other layers to handle the introduced ambiguity sounds > like setting yourself up for the issues that RFC 1535 was drawing > attention to. Brian, This may be a silly question, but what's your goal here? Your OP was about terminology, but the thread has gone down several different off-topic ratholes. Doug From jra at baylink.com Mon Feb 25 18:18:05 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 25 Feb 2013 13:18:05 -0500 (EST) Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <20130225174941.GT99258@numachi.com> Message-ID: <25813967.7204.1361816285665.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brian Reichert" > On Mon, Feb 25, 2013 at 12:18:00PM -0500, Jay Ashworth wrote: > > If I understood Brian correctly, his problem is that people/programs > > are trying to retrieve things from, eg: > > > > https://my.host.name./this/is/a/path > > > > and the SSL library fails the certificate match if the cert doesn't contain > > the absolute domain name as an altName -- because *the browser* (or > > whatever) does not normalize before calling the library. > > I'd argue that if you have an absolute domain name, then that _is_ > the 'normalized' form of the domain name; it's an unambigious > representation of the domain name. (Here, I'm treating the string > as a serialized data structure.) I disagree, and happily, I can tell you exactly why. > Choosing to remove the notion of "this is rooted", and then asking > any (all?) other layers to handle the introduced ambiguity sounds > like setting yourself up for the issues that RFC 1535 was drawing > attention to. The interface we're talking about here is an application on a machine asking the SSL library "does the certificate which I have retrieved and handed to you for processing match this domain name?" *Since that certificate has [possibly] come from a different machine*, the context in which that evaluation must be done seems necessarily to be "over the wire/remote", and -- if you accept my earlier premise -- *it[1] is inherently absolute, no matter what it contains*. Since that context exists, you can then safely strip off the trailing dot inside the library before making said comparison. This is not the same circumstance as being presented with a shortname, where the actual IP connection/SSL retrieval was done based on the resolver applying a search path: in this case there's no obvious thing which the library could add, whereas it *is* obvious what you should strip (and, I allege, why) in the absolute-name-provided case. [1] The context of the evaluation, and by extension, the context of the string you're handing the SSL library to do the match. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From wbailey at satelliteintelligencegroup.com Mon Feb 25 18:32:31 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 25 Feb 2013 18:32:31 +0000 Subject: What are you doing about Six Strikes? In-Reply-To: Message-ID: The federal agents who get the list of offenders every week?? :P On 2/25/13 10:05 AM, "Joly MacFie" wrote: >Who said it's a law? > > > >On Mon, Feb 25, 2013 at 11:37 AM, Seth David Schoen >wrote: >> Jay Ashworth writes: >> >>> This just in from Lauren Weinstein. This is, of course, today. >>> >>> Have people actually deployed changes to support this? >> >> Six Strikes is not a law; it's a private agreement. >> >> http://www.scribd.com/doc/91987640/CCI-MOU >> >> -- >> Seth David Schoen | No haiku patents >> http://www.loyalty.org/~schoen/ | means I've no incentive >>to >> FD9A6AA28193A9F03D4BF4ADC11B36DC9C7DD150 | -- Don Marti >> > > > >-- >--------------------------------------------------------------- >Joly MacFie 218 565 9365 Skype:punkcast >WWWhatsup NYC - http://wwwhatsup.com > http://pinstand.com - http://punkcast.com > VP (Admin) - ISOC-NY - http://isoc-ny.org >-------------------------------------------------------------- >- > > From jra at baylink.com Mon Feb 25 18:50:58 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 25 Feb 2013 13:50:58 -0500 (EST) Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: <7370441.7160.1361812308247.JavaMail.root@benjamin.baylink.com> Message-ID: <12433887.7226.1361818258718.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jay Ashworth" > > Who should implement the normalization logic? Not the SSL library, > > certainly. That sounds like the bailiwick of the resolver library... > > No, in fact, I think this is layer... 3 or 4, not 2; this *should* > be in the SSL library -- *you're not resolving this name*. Or maybe even above that. RFC 5246 seems the currently controlling spec, and neither it nor the Wikipedia article on this: https://en.wikipedia.org/wiki/Transport_Layer_Security actually says *what the client is supposed to do with the Server Certificate* which 7.4.2 says the server will send; appendix D.2 explicitly punts that question "upstairs"... but I'm not sure exactly to where, as I don't know in detail how HTTPS connections are generally set up. I suspect, though, that at this point, it leaves NANOG's domain. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From tarko at lanparty.ee Mon Feb 25 19:06:07 2013 From: tarko at lanparty.ee (Tarko Tikan) Date: Mon, 25 Feb 2013 21:06:07 +0200 Subject: Circuit Bandwidth Simulator applet etc In-Reply-To: References: Message-ID: <512BB61F.9020708@lanparty.ee> hey, > I would like a applet or program I can feed it nodes and a network > topology, then just set hypothetical transmit speeds at child nodes > then have the applet or program display the Parent node bandwidth. Is > there any Visio applets or macros out there I wonder? http://totem.run.montefiore.ulg.ac.be/ Written in Java and quite usable. Topology and traffic matrix are stored/read in XML so it's easy to generate your own with scripts. -- tarko From reichert at numachi.com Mon Feb 25 18:59:04 2013 From: reichert at numachi.com (Brian Reichert) Date: Mon, 25 Feb 2013 13:59:04 -0500 Subject: looking for terminology recommendations concerning non-rooted FQDNs In-Reply-To: <512BA92F.7090703@dougbarton.us> References: <74F5F4AD-935B-442D-86CC-9CB19B880123@delong.com> <24025524.7172.1361812680297.JavaMail.root@benjamin.baylink.com> <20130225174941.GT99258@numachi.com> <512BA92F.7090703@dougbarton.us> Message-ID: <20130225185904.GU99258@numachi.com> On Mon, Feb 25, 2013 at 10:10:55AM -0800, Doug Barton wrote: > Brian, > > This may be a silly question, but what's your goal here? Your OP was > about terminology, but the thread has gone down several different > off-topic ratholes. That was indeed by original goal, and there have been a couple of useful suggestions, and I thank this forum for all of the suggestions and feedback. I later mentioned why I was pursuing the terminology (use case surrounding entries in a SAN), and there's some effort to consider whether or not my issue is really a non-issue. Which it might be. > Doug -- Brian Reichert BSD admin/developer at large From Valdis.Kletnieks at vt.edu Mon Feb 25 19:25:52 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 25 Feb 2013 14:25:52 -0500 Subject: What are you doing about Six Strikes? In-Reply-To: Your message of "Mon, 25 Feb 2013 13:05:48 -0500." References: <20130224211616.GB15123@vortex.com> <28937159.7124.1361805811710.JavaMail.root@benjamin.baylink.com> <20130225163721.GG8791@frotz.zork.net> Message-ID: <15869.1361820352@turing-police.cc.vt.edu> On Mon, 25 Feb 2013 13:05:48 -0500, Joly MacFie said: > Who said it's a law? If it was in fact a law, it would be a lot easier for the victims to fight back in a court of law. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From joesox at gmail.com Mon Feb 25 19:41:18 2013 From: joesox at gmail.com (JoeSox) Date: Mon, 25 Feb 2013 11:41:18 -0800 Subject: Circuit Bandwidth Simulator applet etc In-Reply-To: <512BB61F.9020708@lanparty.ee> References: <512BB61F.9020708@lanparty.ee> Message-ID: TOTEM looks like it might fit my needs but the download link appears offline. The others I am looking at also. -- Thanks, Joe On Mon, Feb 25, 2013 at 11:06 AM, Tarko Tikan wrote: > hey, > > >> I would like a applet or program I can feed it nodes and a network >> topology, then just set hypothetical transmit speeds at child nodes >> then have the applet or program display the Parent node bandwidth. Is >> there any Visio applets or macros out there I wonder? > > > http://totem.run.montefiore.ulg.ac.be/ > > Written in Java and quite usable. Topology and traffic matrix are > stored/read in XML so it's easy to generate your own with scripts. > > -- > tarko > From Jason_Livingood at cable.comcast.com Mon Feb 25 20:07:43 2013 From: Jason_Livingood at cable.comcast.com (Livingood, Jason) Date: Mon, 25 Feb 2013 20:07:43 +0000 Subject: What are you doing about Six Strikes? In-Reply-To: <28937159.7124.1361805811710.JavaMail.root@benjamin.baylink.com> Message-ID: <10229F86C86EB444898E629583FD417161671F2D@PACDCEXMB06.cable.comcast.com> On 2/25/13 10:23 AM, "Jay Ashworth" wrote: >>Expected results: >> >> 1) Legit users are harassed due to IP address mix-ups, etc. Remember >> you must pay to file an appeal. >> Other than a few IP mix ups years ago, is this still really an issue? It seems ISPs have pretty reliable IP lease histories for many years to support LEA requests and other needs... - Jason From gem at rellim.com Mon Feb 25 20:16:56 2013 From: gem at rellim.com (Gary E. Miller) Date: Mon, 25 Feb 2013 12:16:56 -0800 Subject: What are you doing about Six Strikes? In-Reply-To: <10229F86C86EB444898E629583FD417161671F2D@PACDCEXMB06.cable.comcast.com> References: <28937159.7124.1361805811710.JavaMail.root@benjamin.baylink.com> <10229F86C86EB444898E629583FD417161671F2D@PACDCEXMB06.cable.comcast.com> Message-ID: <20130225121656.0b7de46b.gem@rellim.com> Yo Jason! On Mon, 25 Feb 2013 20:07:43 +0000 "Livingood, Jason" wrote: > >> 1) Legit users are harassed due to IP address mix-ups, etc. > >> Remember you must pay to file an appeal. > Other than a few IP mix ups years ago, is this still really an issue? It has been for me. My SWIP records are up to date but the copyright trolls can't be bothered with the facts of my IPs. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From wbailey at satelliteintelligencegroup.com Mon Feb 25 20:20:34 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 25 Feb 2013 20:20:34 +0000 Subject: Visio-fu Message-ID: All, I have been searching our beloved internet endlessly for months on information regarding Visio technique. Does anyone have a good resource(s) for advanced visio drawings, or more to the point a good place for high quality connectors? There is some great quality work out there, this is something I found just a little while ago http://www.parallels.com/r/upload/figure2-1.gif This may not be a visio drawing (do not have any background on it), but I would really dig some resources that you guys out there may or may not use. The cables in that drawing look fantastic to me, so I would really appreciate any guidance you all have in helping me improve my output. Thanks! //warren From Valdis.Kletnieks at vt.edu Mon Feb 25 20:20:24 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 25 Feb 2013 15:20:24 -0500 Subject: What are you doing about Six Strikes? In-Reply-To: Your message of "Mon, 25 Feb 2013 20:07:43 +0000." <10229F86C86EB444898E629583FD417161671F2D@PACDCEXMB06.cable.comcast.com> References: <10229F86C86EB444898E629583FD417161671F2D@PACDCEXMB06.cable.comcast.com> Message-ID: <25208.1361823624@turing-police.cc.vt.edu> On Mon, 25 Feb 2013 20:07:43 +0000, "Livingood, Jason" said: > Other than a few IP mix ups years ago, is this still really an issue? It > seems ISPs have pretty reliable IP lease histories for many years to > support LEA requests and other needs... The fact that the ISP has a good record of what customer had what IP address doesn't do much good if the agency hired to do the dirty work calls the ISP and gives it the wrong IP or timestamp in the the report... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jra at baylink.com Mon Feb 25 20:23:59 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 25 Feb 2013 15:23:59 -0500 (EST) Subject: What are you doing about Six Strikes? In-Reply-To: <25208.1361823624@turing-police.cc.vt.edu> Message-ID: <19629935.7254.1361823839720.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Mon, 25 Feb 2013 20:07:43 +0000, "Livingood, Jason" said: > > > Other than a few IP mix ups years ago, is this still really an issue? It > > seems ISPs have pretty reliable IP lease histories for many years to > > support LEA requests and other needs... > > The fact that the ISP has a good record of what customer had what IP > address doesn't do much good if the agency hired to do the dirty work calls > the ISP and gives it the wrong IP or timestamp in the the report... And since the labels and their contractors are arguably Happy Enough if they reduce "pirating" by *scaring* everyone rather than actually hitting the targets, they have little incentive to care, unless one is provided to them, um, externally. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From george.herbert at gmail.com Mon Feb 25 20:58:57 2013 From: george.herbert at gmail.com (George Herbert) Date: Mon, 25 Feb 2013 12:58:57 -0800 Subject: Visio-fu In-Reply-To: References: Message-ID: On Mon, Feb 25, 2013 at 12:20 PM, Warren Bailey wrote: > All, > > I have been searching our beloved internet endlessly for months on information regarding Visio technique. Does anyone have a good resource(s) for advanced visio drawings, or more to the point a good place for high quality connectors? There is some great quality work out there, this is something I found just a little while ago http://www.parallels.com/r/upload/figure2-1.gif > > This may not be a visio drawing (do not have any background on it), but I would really dig some resources that you guys out there may or may not use. The cables in that drawing look fantastic to me, so I would really appreciate any guidance you all have in helping me improve my output. > > Thanks! > > //warren I've seen a lot of .vsd and drawn a few, and that looks like a professional artist and graphics program like Illustrator, not Visio. They might have poached some visio generic system images, but those could be hand-done too. If Visio can do twisted, curved cables like that, it's a feature I've never seen before in it... My company has a Visio whiz, who I'm going to ping for his opinion on that, but I am guessing it's a no. -- -george william herbert george.herbert at gmail.com From peter.phaal at gmail.com Mon Feb 25 21:13:00 2013 From: peter.phaal at gmail.com (Peter Phaal) Date: Mon, 25 Feb 2013 13:13:00 -0800 Subject: SDN - Killer Apps In-Reply-To: <20130225101056.GA30452@pob.ytti.fi> References: <20130225101056.GA30452@pob.ytti.fi> Message-ID: On Mon, Feb 25, 2013 at 2:10 AM, Saku Ytti wrote: > On (2013-02-25 13:53 +0530), Glen Kent wrote: > >> I understand that this is just some bit of what we can do with SDN. The >> amount of what all can be done is limitless. So, a question to all out >> there - Is my understanding of what can be achieved with SDN, is correct? > > Frankly I don't think there is single answer. > > From my point of view I don't see much use for it as general purpose SP. There is potential for balancing to be a killer application for SDN in the service provider space: http://blog.sflow.com/2013/02/sdn-and-large-flows.html What do people think? From Valdis.Kletnieks at vt.edu Mon Feb 25 21:49:00 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 25 Feb 2013 16:49:00 -0500 Subject: SDN - Killer Apps In-Reply-To: Your message of "Mon, 25 Feb 2013 13:53:13 +0530." References: Message-ID: <56959.1361828940@turing-police.cc.vt.edu> On Mon, 25 Feb 2013 13:53:13 +0530, Glen Kent said: > Yahoo, Google, etc applications are running on one server and each > application could be theoretically associated with a unique VXLAN tag. This > way service providers will be able to provide QoS per application QoS is, when you get down to it, a way to decide who gets screwed when your network capacity is insufficient. And it's unclear that you're going to get a killer app out of that, because most of the 800 pound gorillas are instead spending their dollars making their network work right at their end. And no amount of QoS at the server end is going to fix things when the real problem is bufferbloat in the CPE router at the other end or other issue not under the control of those participating in the QoS (in other words, if you don't do it end-to-end, it won't buy you much). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From george.herbert at gmail.com Mon Feb 25 22:04:18 2013 From: george.herbert at gmail.com (George Herbert) Date: Mon, 25 Feb 2013 14:04:18 -0800 Subject: Visio-fu In-Reply-To: References: Message-ID: On Mon, Feb 25, 2013 at 12:58 PM, George Herbert wrote: > [...] > My company has a Visio whiz, who I'm going to ping for his opinion on > that, but I am guessing it's a no. Our Visio guy's opinion concurred with mine; it's custom drawing, not off-the-shelf capability, and would most likely have been in a graphics program (though he thinks it might have been possible with Visio, it would have been much easier in for example Illustrator). -- -george william herbert george.herbert at gmail.com From pelle at hemmop.com Mon Feb 25 22:06:13 2013 From: pelle at hemmop.com (Per Carlson) Date: Mon, 25 Feb 2013 23:06:13 +0100 Subject: SDN - Killer Apps In-Reply-To: References: Message-ID: Hi Glen. Here's some thoughts how Networking can learn from SDN: http://forums.juniper.net/t5/The-New-Network/Decoding-SDN/ba-p/174651 /Pelle From joshbaird at gmail.com Mon Feb 25 22:06:14 2013 From: joshbaird at gmail.com (Josh Baird) Date: Mon, 25 Feb 2013 17:06:14 -0500 Subject: Visio-fu In-Reply-To: References: Message-ID: Check SmartDraw. On Mon, Feb 25, 2013 at 5:04 PM, George Herbert wrote: > On Mon, Feb 25, 2013 at 12:58 PM, George Herbert > wrote: > > [...] > > My company has a Visio whiz, who I'm going to ping for his opinion on > > that, but I am guessing it's a no. > > Our Visio guy's opinion concurred with mine; it's custom drawing, not > off-the-shelf capability, and would most likely have been in a > graphics program (though he thinks it might have been possible with > Visio, it would have been much easier in for example Illustrator). > > > -- > -george william herbert > george.herbert at gmail.com > > From marka at isc.org Mon Feb 25 22:07:24 2013 From: marka at isc.org (Mark Andrews) Date: Tue, 26 Feb 2013 09:07:24 +1100 Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: Your message of "Mon, 25 Feb 2013 09:49:19 CDT." <15455394.7034.1361803759023.JavaMail.root@benjamin.baylink.com> References: <15455394.7034.1361803759023.JavaMail.root@benjamin.baylink.com> Message-ID: <20130225220724.6EF12300B8E8@drugs.dv.isc.org> In message <15455394.7034.1361803759023.JavaMail.root at benjamin.baylink.com>, Ja y Ashworth writes: > ----- Original Message ----- > > From: "Brian Reichert" > > > On Sun, Feb 24, 2013 at 12:10:20AM +1100, Mark Andrews wrote: > [I believe this is Brian, then Mark: ] > > > > When I did my initial development with OpenSSL, I observed: > > > > > > > > - If I did not have the rooted domain name in the SAN, then any SSL > > > > client stack would fail the verification if a rooted domain name > > > > was used to connect to the SSL server. > > > > > > Well you have a broken SSL client app. If it is accepting non legal > > > hostnames it should be normalising them before passing them to the > > > ssl layer. > > > > From what little research I've done (only OpenSSL), the SSL client > > is relying on getaddrinfo(3) to do name resolution. In turn, I > > haven't found an implementation of getaddrinfo(3) that rejects > > rooted domain names as non-legal. And getaddrinfo() returns the canonical name (ai_canonname) which is the name found after searching, if any, and CNAMEs (DNAME) have been followed. It doesn't have a period at the end unless there is a implementation bug. struct addrinfo { int ai_flags; /* input flags */ int ai_family; /* protocol family for socket */ int ai_socktype; /* socket type */ int ai_protocol; /* protocol for socket */ socklen_t ai_addrlen; /* length of socket-address */ struct sockaddr *ai_addr; /* socket-address for socket */ char *ai_canonname; /* canonical name for service location */ struct addrinfo *ai_next; /* pointer to next in list */ }; Now http{s} clients and server administrators have misused CNAME for years so ai_canonname is not as useful as it should be. ai_canonname should match the expected name in the presented CERT. As a result the http{s} client needs to do the normalisation including search list processing. Yes there are lots of broken clients. > Yes, but that's not the question, Brian, assuming I understand the problem > as well as I think I do. The question is not how the client does the > name resolution on the client machine -- it's what it does with the domain > name it's looking up before doing the SSL interaction with the server side, > a process with which I'm not familiar enough to know if the client actually > send the host/domain name to the server end. Assuming it does -- and I > am -- the question is: should it take the dot off. > > === > > More formally: "is a host/domain name with a trailing dot *actually a > legal host name? No. See RFC 952 > Or is that merely local shorthand notation for resolvers > and DNS server zone files, to define absoluteness. In short: are domain > names on-the-wire *always* to be interpreted as absolute even in the > absence of a trailing dot." > > My personal opinion, based on about 2 decades of watching from the outside, > and of systems analysis and application design in non-internet contexts, > is to say that yes, they must; there is *in fact* no reason for a relative > domain name to leave a machine, since the context for it's relativity is > dependent on the resolv.conf on that machine for lookups, and on which > zone file it's in for service... > > and that the implication of that is that any application/library which > takes a text-string host/domain name handed to it from off-machine ought > to normalize away any trailing dot. > > I invite counter-arguments and -citations. :-) > > Cheers, > -- jr 'yeah, I know, it's Monday' a > -- > Jay R. Ashworth Baylink jra at baylink.co > m > Designer The Things I Think RFC 210 > 0 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DI > I > St Petersburg FL USA #natog +1 727 647 127 > 4 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From wbailey at satelliteintelligencegroup.com Mon Feb 25 22:15:41 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Mon, 25 Feb 2013 22:15:41 +0000 Subject: Visio-fu In-Reply-To: References: , Message-ID: I've seen smart draw. I wish these drawing software companies would port their application over to mac.. Every big design guy I know is a mac fanboy, Adobe has it figured out but smart draw and visio have no excuse. Omni is about the only thing out there, but it is hell to use in my opinion. :) >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Josh Baird Date: 02/25/2013 2:10 PM (GMT-08:00) To: George Herbert Cc: Warren Bailey ,North American Network Operators Group Subject: Re: Visio-fu Check SmartDraw. On Mon, Feb 25, 2013 at 5:04 PM, George Herbert > wrote: On Mon, Feb 25, 2013 at 12:58 PM, George Herbert > wrote: > [...] > My company has a Visio whiz, who I'm going to ping for his opinion on > that, but I am guessing it's a no. Our Visio guy's opinion concurred with mine; it's custom drawing, not off-the-shelf capability, and would most likely have been in a graphics program (though he thinks it might have been possible with Visio, it would have been much easier in for example Illustrator). -- -george william herbert george.herbert at gmail.com From m.hallgren at free.fr Mon Feb 25 22:20:18 2013 From: m.hallgren at free.fr (Michael Hallgren) Date: Mon, 25 Feb 2013 23:20:18 +0100 Subject: Visio-fu In-Reply-To: References: Message-ID: <512BE3A2.3060608@free.fr> Le 25/02/2013 23:06, Josh Baird a ?crit : > Check SmartDraw. pstricks, metapost, TikZ (pgf),... mh > > On Mon, Feb 25, 2013 at 5:04 PM, George Herbert wrote: > >> On Mon, Feb 25, 2013 at 12:58 PM, George Herbert >> wrote: >>> [...] >>> My company has a Visio whiz, who I'm going to ping for his opinion on >>> that, but I am guessing it's a no. >> Our Visio guy's opinion concurred with mine; it's custom drawing, not >> off-the-shelf capability, and would most likely have been in a >> graphics program (though he thinks it might have been possible with >> Visio, it would have been much easier in for example Illustrator). >> >> >> -- >> -george william herbert >> george.herbert at gmail.com >> >> From m.hallgren at free.fr Mon Feb 25 22:22:24 2013 From: m.hallgren at free.fr (Michael Hallgren) Date: Mon, 25 Feb 2013 23:22:24 +0100 Subject: Visio-fu In-Reply-To: References: , Message-ID: <512BE420.7080304@free.fr> Le 25/02/2013 23:15, Warren Bailey a ?crit : > I've seen smart draw. I wish these drawing software companies would port their application over to mac.. Every big design guy I know is a mac fanboy, Adobe has it figured out but smart draw and visio have no excuse. Omni is about the only thing out there, but it is hell to use in my opinion. :) Hell is quite structured in the TeX related list I just proposed. :) mh > > > From my Android phone on T-Mobile. The first nationwide 4G network. > > > > -------- Original message -------- > From: Josh Baird > Date: 02/25/2013 2:10 PM (GMT-08:00) > To: George Herbert > Cc: Warren Bailey ,North American Network Operators Group > Subject: Re: Visio-fu > > > Check SmartDraw. > > On Mon, Feb 25, 2013 at 5:04 PM, George Herbert > wrote: > On Mon, Feb 25, 2013 at 12:58 PM, George Herbert > > wrote: >> [...] >> My company has a Visio whiz, who I'm going to ping for his opinion on >> that, but I am guessing it's a no. > Our Visio guy's opinion concurred with mine; it's custom drawing, not > off-the-shelf capability, and would most likely have been in a > graphics program (though he thinks it might have been possible with > Visio, it would have been much easier in for example Illustrator). > > > -- > -george william herbert > george.herbert at gmail.com > > From jra at baylink.com Mon Feb 25 23:09:01 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 25 Feb 2013 18:09:01 -0500 (EST) Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: <20130225220724.6EF12300B8E8@drugs.dv.isc.org> Message-ID: <32423329.7280.1361833741738.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Andrews" > > > From what little research I've done (only OpenSSL), the SSL client > > > is relying on getaddrinfo(3) to do name resolution. In turn, I > > > haven't found an implementation of getaddrinfo(3) that rejects > > > rooted domain names as non-legal. > > And getaddrinfo() returns the canonical name (ai_canonname) which > is the name found after searching, if any, and CNAMEs (DNAME) have > been followed. It doesn't have a period at the end unless there > is a implementation bug. > > struct addrinfo { > int ai_flags; /* input flags */ > int ai_family; /* protocol family for socket */ > int ai_socktype; /* socket type */ > int ai_protocol; /* protocol for socket */ > socklen_t ai_addrlen; /* length of socket-address */ > struct sockaddr *ai_addr; /* socket-address for socket */ > char *ai_canonname; /* canonical name for service location */ > struct addrinfo *ai_next; /* pointer to next in list */ > }; > > Now http{s} clients and server administrators have misused CNAME > for years so ai_canonname is not as useful as it should be. > ai_canonname should match the expected name in the presented CERT. > As a result the http{s} client needs to do the normalisation including > search list processing. Yes there are lots of broken clients. Sure, but both of those were red herrings, as we weren't at that point talking about DNS proper anymore, but on-machine interpretation of an imported SSL cert against a hostname generated on-machine. As I note here: > > Yes, but that's not the question, Brian, assuming I understand the problem > > as well as I think I do. The question is not how the client does the > > name resolution on the client machine -- it's what it does with the > > domain name it's looking up before doing the SSL interaction with the > > server side, > > a process with which I'm not familiar enough to know if the client > > actually > > send the host/domain name to the server end. Assuming it does -- and > > I am -- the question is: should it take the dot off. :-) > > More formally: "is a host/domain name with a trailing dot *actually > > a legal host name? > > No. See RFC 952 I think 952 is functionally obsolete, requireing a <24 char name length; I would have expected citations, perhaps, to 1535. Care to expand? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From reichert at numachi.com Mon Feb 25 22:48:10 2013 From: reichert at numachi.com (Brian Reichert) Date: Mon, 25 Feb 2013 17:48:10 -0500 Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: <20130225220724.6EF12300B8E8@drugs.dv.isc.org> References: <15455394.7034.1361803759023.JavaMail.root@benjamin.baylink.com> <20130225220724.6EF12300B8E8@drugs.dv.isc.org> Message-ID: <20130225224810.GA99258@numachi.com> On Tue, Feb 26, 2013 at 09:07:24AM +1100, Mark Andrews wrote: > > In message <15455394.7034.1361803759023.JavaMail.root at benjamin.baylink.com>, Ja > y Ashworth writes: > > More formally: "is a host/domain name with a trailing dot *actually a > > legal host name? > > No. See RFC 952 In the case of URIs, RFC 2396 (circa 1998) seems to allow for it, if I read the ABNF for 'hostname' right in section 3.2.2. But that's the only place I see it. > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org -- Brian Reichert BSD admin/developer at large From jra at baylink.com Mon Feb 25 23:24:15 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 25 Feb 2013 18:24:15 -0500 (EST) Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: <20130225224810.GA99258@numachi.com> Message-ID: <19557229.7296.1361834655750.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Brian Reichert" > > > More formally: "is a host/domain name with a trailing dot > > > *actually a legal host name? > > > > No. See RFC 952 > > In the case of URIs, RFC 2396 (circa 1998) seems to allow for it, > if I read the ABNF for 'hostname' right in section 3.2.2. > > But that's the only place I see it. Concur, unhappily. And at this point, we are *definitely* out-of-scope for NANOG. :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From marka at isc.org Mon Feb 25 23:25:38 2013 From: marka at isc.org (Mark Andrews) Date: Tue, 26 Feb 2013 10:25:38 +1100 Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: Your message of "Mon, 25 Feb 2013 18:09:01 CDT." <32423329.7280.1361833741738.JavaMail.root@benjamin.baylink.com> References: <32423329.7280.1361833741738.JavaMail.root@benjamin.baylink.com> Message-ID: <20130225232538.3213C300C787@drugs.dv.isc.org> In message <32423329.7280.1361833741738.JavaMail.root at benjamin.baylink.com>, Ja y Ashworth writes: > ----- Original Message ----- > > From: "Mark Andrews" > > > > > From what little research I've done (only OpenSSL), the SSL client > > > > is relying on getaddrinfo(3) to do name resolution. In turn, I > > > > haven't found an implementation of getaddrinfo(3) that rejects > > > > rooted domain names as non-legal. > > > > And getaddrinfo() returns the canonical name (ai_canonname) which > > is the name found after searching, if any, and CNAMEs (DNAME) have > > been followed. It doesn't have a period at the end unless there > > is a implementation bug. > > > > struct addrinfo { > > int ai_flags; /* input flags */ > > int ai_family; /* protocol family for socket */ > > int ai_socktype; /* socket type */ > > int ai_protocol; /* protocol for socket */ > > socklen_t ai_addrlen; /* length of socket-address */ > > struct sockaddr *ai_addr; /* socket-address for socket */ > > char *ai_canonname; /* canonical name for service location */ > > struct addrinfo *ai_next; /* pointer to next in list */ > > }; > > > > Now http{s} clients and server administrators have misused CNAME > > for years so ai_canonname is not as useful as it should be. > > ai_canonname should match the expected name in the presented CERT. > > As a result the http{s} client needs to do the normalisation including > > search list processing. Yes there are lots of broken clients. > > Sure, but both of those were red herrings, as we weren't at that point > talking about DNS proper anymore, but on-machine interpretation of an > imported SSL cert against a hostname generated on-machine. > > As I note here: > > > > Yes, but that's not the question, Brian, assuming I understand the proble > m > > > as well as I think I do. The question is not how the client does the > > > name resolution on the client machine -- it's what it does with the > > > domain name it's looking up before doing the SSL interaction with the > > > server side, > > > a process with which I'm not familiar enough to know if the client > > > actually > > > send the host/domain name to the server end. Assuming it does -- and > > > I am -- the question is: should it take the dot off. > > :-) > > > > > More formally: "is a host/domain name with a trailing dot *actually > > > a legal host name? > > > > No. See RFC 952 > > I think 952 is functionally obsolete, requireing a <24 char name length; > I would have expected citations, perhaps, to 1535. > > Care to expand? Ok. RFC 952 as modified by RFC 1123. This covers all legal hostnames in use today including those that do not fit in the DNS. The DNS supports hostnames up to 253 bytes (255 bytes in wire encoding). RFC 1123 allow hostnames to go to 255 bytes. I'm deliberately ignoring IDN's as they still need to map back into what is permitted by RFC 952 as modified by RFC 1123. RFC 1535 is NOT a STANDARD. Not all RFC are created equal. > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.co > m > Designer The Things I Think RFC 210 > 0 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DI > I > St Petersburg FL USA #natog +1 727 647 127 > 4 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Mon Feb 25 23:36:05 2013 From: marka at isc.org (Mark Andrews) Date: Tue, 26 Feb 2013 10:36:05 +1100 Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: Your message of "Mon, 25 Feb 2013 18:09:01 CDT." <32423329.7280.1361833741738.JavaMail.root@benjamin.baylink.com> References: <32423329.7280.1361833741738.JavaMail.root@benjamin.baylink.com> Message-ID: <20130225233605.B4408300C80A@drugs.dv.isc.org> In message <32423329.7280.1361833741738.JavaMail.root at benjamin.baylink.com>, Ja y Ashworth writes: > ----- Original Message ----- > > From: "Mark Andrews" > > > > > From what little research I've done (only OpenSSL), the SSL client > > > > is relying on getaddrinfo(3) to do name resolution. In turn, I > > > > haven't found an implementation of getaddrinfo(3) that rejects > > > > rooted domain names as non-legal. > > > > And getaddrinfo() returns the canonical name (ai_canonname) which > > is the name found after searching, if any, and CNAMEs (DNAME) have > > been followed. It doesn't have a period at the end unless there > > is a implementation bug. > > > > struct addrinfo { > > int ai_flags; /* input flags */ > > int ai_family; /* protocol family for socket */ > > int ai_socktype; /* socket type */ > > int ai_protocol; /* protocol for socket */ > > socklen_t ai_addrlen; /* length of socket-address */ > > struct sockaddr *ai_addr; /* socket-address for socket */ > > char *ai_canonname; /* canonical name for service location */ > > struct addrinfo *ai_next; /* pointer to next in list */ > > }; > > > > Now http{s} clients and server administrators have misused CNAME > > for years so ai_canonname is not as useful as it should be. > > ai_canonname should match the expected name in the presented CERT. > > As a result the http{s} client needs to do the normalisation including > > search list processing. Yes there are lots of broken clients. > > Sure, but both of those were red herrings, as we weren't at that point > talking about DNS proper anymore, but on-machine interpretation of an > imported SSL cert against a hostname generated on-machine. getaddrinfo() is *independent* of the underlying name resolution technology. The DNS, NIS, /etc/hosts LDAP all have the concepts of canoical name and alias. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jra at baylink.com Mon Feb 25 23:36:24 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 25 Feb 2013 18:36:24 -0500 (EST) Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: <20130225232538.3213C300C787@drugs.dv.isc.org> Message-ID: <17812038.7306.1361835383974.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Mark Andrews" > > > No. See RFC 952 > > > > I think 952 is functionally obsolete, requireing a <24 char name > > length; > > I would have expected citations, perhaps, to 1535. > > > > Care to expand? > > Ok. RFC 952 as modified by RFC 1123. This covers all legal hostnames > in use today including those that do not fit in the DNS. The DNS > supports hostnames up to 253 bytes (255 bytes in wire encoding). > RFC 1123 allow hostnames to go to 255 bytes. I'm deliberately > ignoring IDN's as they still need to map back into what is permitted > by RFC 952 as modified by RFC 1123. And except on length and first-digit-allowed, 1123 punts naming to 952 (which doesn't really say) and in 6.1, to 1034 and 1035. So I know what my light night reading will be (unless Albitz, Liu, Mockapetris, or any of the BIND team are around on the list :-) > RFC 1535 is NOT a STANDARD. Not all RFC are created equal. Typo. 1035 (as updated by whatever is on-point, if anything). And Mark: could you please trim your quoting a bit? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jfmezei_nanog at vaxination.ca Mon Feb 25 23:44:22 2013 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 25 Feb 2013 18:44:22 -0500 Subject: Demarc in FTTH ? Message-ID: <512BF756.1020601@vaxination.ca> What are you thoughts about whether FTTH GPON systems have a demarc or not ? Would it be the ONT ? (since beyond the ONT, the end user has no ability to test the line). or should FTTH be viewed more like DOCSIS systems where there is no official demarc ? In Canada, the telcos charge a "DMC" charge if they visit an end user's house and find the service is fine at the demarc (indicating problem in within customer's responsability). So finding out where responsanility ends would be userful. Any thoughts would be appreciated. Also, since the ONT is generally proprietary to the telco who made decisions on GPON deployments, does it make sense to have the ONT in the customer's responsability ? From streiner at cluebyfour.org Mon Feb 25 23:44:55 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 25 Feb 2013 18:44:55 -0500 (EST) Subject: Visio-fu In-Reply-To: References: Message-ID: On Mon, 25 Feb 2013, George Herbert wrote: > Our Visio guy's opinion concurred with mine; it's custom drawing, not > off-the-shelf capability, and would most likely have been in a > graphics program (though he thinks it might have been possible with > Visio, it would have been much easier in for example Illustrator). I concur. Visio is not particularly good at (what appear to be) freehand shapes. jm'probably the closest thing to "the Visio guy" at my workplace's From streiner at cluebyfour.org Mon Feb 25 23:52:12 2013 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 25 Feb 2013 18:52:12 -0500 (EST) Subject: Demarc in FTTH ? In-Reply-To: <512BF756.1020601@vaxination.ca> References: <512BF756.1020601@vaxination.ca> Message-ID: On Mon, 25 Feb 2013, Jean-Francois Mezei wrote: > Would it be the ONT ? (since beyond the ONT, the end user has no ability > to test the line). I would tend to think the ONT is treated as the demarc point. Most carriers I've seen treat them as the optical equivalent of copper NIDs or smartjacks. I have no non-physical access (1) to the ONT for the FiOS installation at my house, and no responsibility for it, beyond providing it with power. (1) a possibly untrue statement, but I've never had any real need to mess around with it ;) jms From marka at isc.org Mon Feb 25 23:54:37 2013 From: marka at isc.org (Mark Andrews) Date: Tue, 26 Feb 2013 10:54:37 +1100 Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: Your message of "Mon, 25 Feb 2013 18:36:24 CDT." <17812038.7306.1361835383974.JavaMail.root@benjamin.baylink.com> References: <17812038.7306.1361835383974.JavaMail.root@benjamin.baylink.com> Message-ID: <20130225235437.92A40300C937@drugs.dv.isc.org> In message <17812038.7306.1361835383974.JavaMail.root at benjamin.baylink.com>, Ja y Ashworth writes: > ----- Original Message ----- > > From: "Mark Andrews" > > > > > No. See RFC 952 > > > > > > I think 952 is functionally obsolete, requireing a <24 char name > > > length; > > > I would have expected citations, perhaps, to 1535. > > > > > > Care to expand? > > > > Ok. RFC 952 as modified by RFC 1123. This covers all legal hostnames > > in use today including those that do not fit in the DNS. The DNS > > supports hostnames up to 253 bytes (255 bytes in wire encoding). > > RFC 1123 allow hostnames to go to 255 bytes. I'm deliberately > > ignoring IDN's as they still need to map back into what is permitted > > by RFC 952 as modified by RFC 1123. > > And except on length and first-digit-allowed, 1123 punts naming to 952 > (which doesn't really say) and in 6.1, to 1034 and 1035. So I know what > my light night reading will be (unless Albitz, Liu, Mockapetris, or any > of the BIND team are around on the list :-) 952 says hostnames don't end in a period. Note that periods are only allowed when they serve to delimit components of "domain style names". ::= *["."] ::= [*[]] 1123 turned into ::= [*[]] it also banned all digit tlds (no covered in the grammar). > > RFC 1535 is NOT a STANDARD. Not all RFC are created equal. > > Typo. 1035 (as updated by whatever is on-point, if anything). And 1035 refers you to 952 + 1123 for hostnames. However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs. For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822. When creating a new host name, the old rules for HOSTS.TXT should be followed. This avoids problems when old software is converted to use domain names. HOSTS.TXT == RFC 952. Host names and domain names are not interchangable in all contexts. You need to know the subtle differences and when which rules apply. Lots of rfcs fail to make the proper distinctions and use domain name when they mean domain style hostname. Mark > And Mark: could you please trim your quoting a bit? > > Cheers, > -- jra > -- > Jay R. Ashworth Baylink jra at baylink.co > m > Designer The Things I Think RFC 210 > 0 > Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DI > I > St Petersburg FL USA #natog +1 727 647 127 > 4 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jra at baylink.com Mon Feb 25 23:57:52 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 25 Feb 2013 18:57:52 -0500 (EST) Subject: Demarc in FTTH ? In-Reply-To: <512BF756.1020601@vaxination.ca> Message-ID: <23496849.7308.1361836672246.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jean-Francois Mezei" > What are you thoughts about whether FTTH GPON systems have a demarc or > not ? > > Would it be the ONT ? (since beyond the ONT, the end user has no > ability to test the line). > > or should FTTH be viewed more like DOCSIS systems where there is no > official demarc ? Many many opinions on this are in the archives from about 3 weeks ago; you should look for "L1 vs L2", and several threads whose titles look related. :) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From mysidia at gmail.com Tue Feb 26 01:07:20 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 25 Feb 2013 19:07:20 -0600 Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: <15455394.7034.1361803759023.JavaMail.root@benjamin.baylink.com> References: <20130225143034.GN99258@numachi.com> <15455394.7034.1361803759023.JavaMail.root@benjamin.baylink.com> Message-ID: On 2/25/13, Jay Ashworth wrote: >> From: "Brian Reichert" [snip] > name it's looking up before doing the SSL interaction with the server side, > a process with which I'm not familiar enough to know if the client actually > send the host/domain name to the server end. Assuming it does -- and I > am -- the question is: should it take the dot off. By the time the hostname is sent over HTTP, the SSL connection is already established, and all the SSL negotiation already happened.. it's up to the client to validate the server's FQDN matches the CN of the certificate, or an alternative DNS name; which are all are (hopefully) or ought to be, by definition FQDNs, before the server knows what hostname(s) HTTP requests will be made against. If the domain in a certificate were not interpreted as a FQDN by the client, this would mean, that the certificate for CN=bigbank.example.com might be used to authenticate a connection to https://bigbank.example.com which do the local resolver search order, is in fact a DNS lookup of bigbank.example.com.intranet.example.com Which might be captured by a Wildcard A record for *.com found in the intranet.example.com. zone and pointed to a server containing a phishing attack against bigbank.example.com; with a DNS cache poisoned by a false negative cache NXDOMAIN entry for bigbank.example.com. The exeption to not sending the domain name before encryption, would be the shiny new TLS protocol version with the server supporting the rarely used SNI extension; extension for server name indication, that will one day allow virtual hosting for TLS protected HTTP transport, sharing one IP address, with a different X509 certificate served up by the server, based on which hostname has been requested (once browsers and servers begin to support TLS1.2 as a replacement for SSL); in this case, the crypto stack on the server does gain access to the hostname. It probably doesn't matter if the server removes the "." or not, before sending it.. the server has to allow the dot. The HTTP/1.1 does mention something about HTTP proxies possibly being able to handle a hostname that is not a FQDN, solely by appending their own domain to the hostname; appending a suffix to the hostname is allowed, in that specific case, but a FQDN must not be changed. http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2 " The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (section 5.1.2). If a proxy receives a host name which is not a fully qualified domain name, it MAY add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy MUST NOT change the host name. " -- -JH From jra at baylink.com Tue Feb 26 02:06:39 2013 From: jra at baylink.com (Jay Ashworth) Date: Mon, 25 Feb 2013 21:06:39 -0500 (EST) Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: Message-ID: <22382459.7322.1361844399446.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jimmy Hess" > By the time the hostname is sent over HTTP, the SSL connection is > already established, and all the SSL negotiation already happened.. Correct, and yes, I did already know that (though, this morning, before coffee, it would have been hard to tell for sure :-). > it's up to the client to validate the server's FQDN matches the CN of > the certificate, or an alternative DNS name; which are all are > (hopefully) or ought to be, by definition FQDNs, before the server > knows what hostname(s) HTTP requests will be made against. Also correct. Our issue on point is this: that match where we supply an FQDN is performed by *some piece of code*, which knows that there are multiple names against which to match. What does that code do with a hostname string which is terminated by a period (it apparently does not treat it specially, and just attempts to match with it included, from Brian's experience) and... Is that the proper behavior? > If the domain in a certificate were not interpreted as a FQDN by the > client, this would mean, that the certificate for > CN=bigbank.example.com > might be used to authenticate a connection to > https://bigbank.example.com > which do the local resolver search order, is in fact a DNS lookup of > bigbank.example.com.intranet.example.com Sure: you can't match a supplied server domain name against cert names which are *longer* (have more atoms) than it is; I get that, see why, and approve. > Which might be captured by a Wildcard A record for *.com found in > the intranet.example.com. zone and pointed to a server > containing a phishing attack against bigbank.example.com; with a > DNS cache poisoned by a false negative cache NXDOMAIN entry for > bigbank.example.com. As is mentioned in RFC 1535, which Mark chastised me for accidentally mentioning a couple hours ago; yes. :-) Oh wait; no, this is a different *class* of attack, no? I can't *have* a wildcard for *.com, *because my resolvers won't ask my servers for that; they'll ask the root*; or do I need to finish reading 1535? > The exeption to not sending the domain name before encryption, would > be the shiny new TLS protocol version with the server supporting the > rarely used SNI extension; extension for server name indication, > that will one day allow virtual hosting for TLS protected HTTP > transport, sharing one IP address, with a different X509 certificate > served up by the server, based on which hostname has been requested > (once browsers and servers begin to support TLS1.2 as a replacement > for SSL); in this case, the crypto stack on the server does gain > access to the hostname. Wow; we *really* don't want to implement IPv6, do we? :-) > It probably doesn't matter if the server removes the "." or not, > before sending it.. the server has to allow the dot. It's not a question of what the server does; the server returns a Server Certificate packet, which the client library either matches on itself, or hands upstairs to ... something else. One of those two things makes the comparison, and our question is: Should that thing trim a trailing dot *off the local string*, before matching the names that came in in the cert. If my assertion from this morning, that names are automatically "absolute" in 1035 terms -- that is, a domain name with a dot after is equal to one without -- *everywhere except* 1) in a resolver query (where they're a hint to the resolver, and *don't* go out with the dot over the wire -- at leastI think they don't; I have to double check... and 2) inside a zone file, where they're a hint to the *server* about where to root the record; against $ORIGIN or not... is true, then the behavior I suggest for opening an SSL/TLS connection should also hold: strip the dot before you match, then match absolutely. > The HTTP/1.1 does mention something about HTTP proxies possibly > being able to handle a hostname that is not a FQDN, solely by > appending their own domain to the hostname; appending a suffix to the > hostname is allowed, in that specific case, but a FQDN must not be > changed. > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2 > " > The use of IP addresses in URLs SHOULD be avoided whenever possible > (see RFC 1900 [24]). If the abs_path is not present in the URL, it > MUST be given as "/" when used as a Request-URI for a resource > (section 5.1.2). If a proxy receives a host name which is not a fully > qualified domain name, it MAY add its domain to the host name it > received. If a proxy receives a fully qualified domain name, the proxy > MUST NOT change the host name. > " Hmmm. I don't know that that applies here; we're strictly HTTPS; can you proxy that? Even if you could, the thing you need to look at is inside the encrypted channel, I think. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From frnkblk at iname.com Tue Feb 26 04:36:15 2013 From: frnkblk at iname.com (Frank Bulk (iname.com)) Date: Mon, 25 Feb 2013 22:36:15 -0600 Subject: 10 Mbit/s problem in your network In-Reply-To: <6D4636E8-F773-423D-8C80-A84B9851B181@delong.com> References: <28915468.6329.1361118824719.JavaMail.root@benjamin.baylink.com> <000601ce1314$7eaec660$7c0c5320$@iname.com> <6D4636E8-F773-423D-8C80-A84B9851B181@delong.com> Message-ID: <002501ce13da$cfe913c0$6fbb3b40$@iname.com> There's only 83.5 MHz to work with at 2.4 GHz, while in most countries you have at least two hundred MHz in the 5 GHz range (http://en.wikipedia.org/wiki/U-NII). So if you choose to have 40 MHz channels for increased throughput, you can have many more (non-overlapping ones) at 5 GHz than 2.4 GHz, increasing Mbps/area. Frank -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, February 25, 2013 10:34 AM To: Frank Bulk Cc: NANOG Subject: Re: 10 Mbit/s problem in your network Correct. However, while A is 5Ghz (only), it's not significantly better than G. The true performance gains come from 5Ghz and N together. N on 2.4Ghz has limited benefit over G. N on 5Ghz is significantly better. Owen On Feb 24, 2013, at 8:56 PM, "Frank Bulk" wrote: > The IEEE 802.11n standards do not require 5 GHz support. It's typical, but > not necessary. > > Frank > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Sunday, February 17, 2013 2:07 PM > To: Jay Ashworth > Cc: NANOG > Subject: Re: 10 Mbit/s problem in your network > > > On Feb 17, 2013, at 08:33 , Jay Ashworth wrote: > >> ----- Original Message ----- >>> From: "Scott Howard" >> >>>> A VPN or SSH session (which is what most hotel guests traveling for >>>> work will do) won't cache at all well, so this is a very bad idea. >>>> Might improve some things, but not the really important ones. >>> >>> The chances of the average hotel wifi user even knowing what SSH means >>> is close to zero. >> >> {{citation-needed}} >> >>> As an aside, I was sitting in JFK airport (terminal 4) a few days ago and >>> having a shocking time getting a good internet connection - even from my >>> own Mifi. I fired up inSSIDer, and within a few seconds it had detected >>> 122 AP's... >> >> Yup; B/G/N congestion is a real problem. Nice that the latest generation >> of both mifi's and cellphones all seem to do A as well, in addition to >> current-gen business laptops (my x61 is almost 5 years old, and speaks A). >> > > I think by A you actually mean 5Ghz N. A doesn't do much better than G, > though > you still have the advantage of wider channels and less frequency congestion > with other uses. > > Owen > > > > From mansaxel at besserwisser.org Tue Feb 26 08:01:49 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Tue, 26 Feb 2013 09:01:49 +0100 Subject: Visio-fu In-Reply-To: References: Message-ID: <20130226080148.GA2606@besserwisser.org> Subject: Visio-fu Date: Mon, Feb 25, 2013 at 08:20:34PM +0000 Quoting Warren Bailey (wbailey at satelliteintelligencegroup.com): > All, > > I have been searching our beloved internet endlessly for months on information regarding Visio technique. Does anyone have a good resource(s) for advanced visio drawings, or more to the point a good place for high quality connectors? There is some great quality work out there, this is something I found just a little while ago http://www.parallels.com/r/upload/figure2-1.gif > > This may not be a visio drawing (do not have any background on it), but I would really dig some resources that you guys out there may or may not use. The cables in that drawing look fantastic to me, so I would really appreciate any guidance you all have in helping me improve my output. I'd just quit beating the rotting carcass of Visio into producing anything not appalling and go with OmniGraffle instead. http://www.omnigroup.com/products/omnigraffle/ -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 DON'T go!! I'm not HOWARD COSELL!! I know POLISH JOKES ... WAIT!! Don't go!! I AM Howard Cosell! ... And I DON'T know Polish jokes!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From oscar.vives at gmail.com Tue Feb 26 10:04:23 2013 From: oscar.vives at gmail.com ( .) Date: Tue, 26 Feb 2013 11:04:23 +0100 Subject: Visio-fu In-Reply-To: <512BE420.7080304@free.fr> References: <512BE420.7080304@free.fr> Message-ID: On 25 February 2013 23:22, Michael Hallgren wrote: > Le 25/02/2013 23:15, Warren Bailey a ?crit : >> I've seen smart draw. I wish these drawing software companies would port their application over to mac.. Every big design guy I know is a mac fanboy, Adobe has it figured out but smart draw and visio have no excuse. Omni is about the only thing out there, but it is hell to use in my opinion. :) > > Hell is quite structured in the TeX related list I just proposed. :) > > mh other tool idea: graphviz could be used to generate braincandy, but not eyecandy (most graphics generated by graphviz are awesome, but ugly). also this was cool: http://www.youtube.com/watch?feature=player_embedded&v=RCa2sjyrUdQ -- -- ?in del ?ensaje. From rs at seastrom.com Tue Feb 26 11:40:23 2013 From: rs at seastrom.com (Rob Seastrom) Date: Tue, 26 Feb 2013 06:40:23 -0500 Subject: 10 Mbit/s problem in your network In-Reply-To: (Owen DeLong's message of "Mon, 25 Feb 2013 08:56:05 -0800") References: <28915468.6329.1361118824719.JavaMail.root@benjamin.baylink.com> <000601ce1314$7eaec660$7c0c5320$@iname.com> <6D4636E8-F773-423D-8C80-A84B9851B181@delong.com> Message-ID: <867glvz4k8.fsf@valhalla.seastrom.com> Owen DeLong writes: > N on 5Ghz takes advantage of the increased bandwidth of the 5Ghz > channel where A merely replicated G on 5Ghz for all practical > purposes. You have that backwards, actually, but the legacy support in 802.11g for 802.11b clients does represent a performance hit even in the absence of b-only clients, so claiming that a and g are equivalent is only true on paper. -r (802.11a user before 802.11g, still love the relatively unoccupied 5 ghz spectrum) From rsk at gsp.org Tue Feb 26 11:43:09 2013 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 26 Feb 2013 06:43:09 -0500 Subject: NYT covers China cyberthreat In-Reply-To: <2A76E400AC84B845AAC35AA19F8E7A5D0E81134F@MUNEXBE1.medline.com> References: <20130220162948.87B4F422@m0005297.ppops.net> <20130221160024.GA19523@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0E81134F@MUNEXBE1.medline.com> Message-ID: <20130226114308.GA31240@gsp.org> On Thu, Feb 21, 2013 at 11:47:44AM -0600, Naslund, Steve wrote: [a number of very good points ] Geoblocking, like passive OS fingerprinting (another technique that reduces attack surface as measured along one axis but can be defeated by a reasonably clueful attacker), doesn't really solve problems, per se. If you have a web app that's vulnerable to SQL injection attacks, then it's still just as hackable -- all the attacker has to do is try from somewhere else, from something else. But... 1. It raises the bar. And it cuts down on the noise, which is one of the security meta-problems we face: our logs capture so much cruft, so many instances of attacks and abuse and mistakes and misconfigurations and malfunctions, that we struggle to understand what they're trying to tell us. That problem is so bad that there's an entire subindustry built around the task of trying to reduce what's in the logs to something that a human brain can process in finite time. Mountains of time and wads of cash have been spent on the thorny problems that arise when we try to figure out what to pay attention to and what to ignore... and we still screw it up. Often. So even if the *only* effect of doing so is to shrink the size of the logs: that's a win. (And used judiciously, it can be a HUGE win, as in "several orders of magnitude".) So if your security guy is as busy as you say...maybe this would be a good idea. And let me note in passing that by raising the bar, it ensures that you're faced with a somewhat higher class of attacker. It's one thing to be hacked by a competent, diligent adversary who wields their tools with rapier-like precision; it's another to be owned by a script kiddie who has no idea what they're doing and doesn't even read the language your assets are using. That's just embarassing. 2. Outbound blocks work too, y'know. Does anybody in your marketing department need to reach Elbonia? If not, then why are you allowing packets from that group's desktops to go there? Because either (a) it's someone doing something they shouldn't or (b) it's something doing something it shouldn't, as in a bot trying to phone home or a data exfiltration attack or something else unpleasant. So if there's no business need for that group to exchange packets with Elbonia or any of 82 other countries, why *aren't* you blocking that? 3. Yes, this can turn into a moderate-sized matrix of inbound and outbound rules. That's why make(1) and similar tools are your friends, because they'll let you manage this without needing to resort to scotch by 9:30 AM. And yes, sometimes things will break (because something's changed) -- but the brokeness is the best kind of brokeness: obvious, deterministic, repeatable, fixable. It's not hard. But it does require that you actually know what your own systems are doing and why. 4. "We were hacked from China" is wearing awfully damn thin as the feeble whining excuse of people who should have bidirectionally firewalled out China from their corporate infrastructure (note: not necessarily their public-facing servers) years ago. And "our data was exfiltrated to Elbonia" is getting thin as an excuse too: if you do not have an organizational need to allow outbound network traffic to Elbonia, then why the hell are you letting so much as a single packet go there? Like I said: at least make them work for it. A little. Instead of doing profoundly idiotic things like the NYTimes (e.g., "infrastructure reachable from the planet", "using M$ software", "actually believing that anti-virus software will work despite a quarter-century of uninterrupted failure", etc.). That's not making them work for it: that's inviting them in, rolling out the red carpet, and handing them celebratory champagne. ---rsk From kyle.creyts at gmail.com Tue Feb 26 16:39:22 2013 From: kyle.creyts at gmail.com (Kyle Creyts) Date: Tue, 26 Feb 2013 08:39:22 -0800 Subject: NYT covers China cyberthreat In-Reply-To: <20130226114308.GA31240@gsp.org> References: <20130220162948.87B4F422@m0005297.ppops.net> <20130221160024.GA19523@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0E81134F@MUNEXBE1.medline.com> <20130226114308.GA31240@gsp.org> Message-ID: I think it is safe to say that finding a foothold inside of the United States from which to perform/proxy an attack is not the hardest thing in the world. I don't understand why everyone expects that major corporations and diligent operators blocking certain countries' prefixes will help. That being said, you make a solid point to which people should absolutely listen: applying an understanding of your business-needs-network-traffic baseline to your firewall rules and heuristic network detections (in a more precise fashion than just "IPs from country $x") is a SOLID tactic that yields huge security benefits. Nobody who cares about security should really be able to argue with it (plenty of those who care don't will hate it, though), and makes life _awful_ for any attackers. On Tue, Feb 26, 2013 at 3:43 AM, Rich Kulawiec wrote: > On Thu, Feb 21, 2013 at 11:47:44AM -0600, Naslund, Steve wrote: > > [a number of very good points ] > > Geoblocking, like passive OS fingerprinting (another technique that > reduces attack surface as measured along one axis but can be defeated > by a reasonably clueful attacker), doesn't really solve problems, per se. > If you have a web app that's vulnerable to SQL injection attacks, then > it's still just as hackable -- all the attacker has to do is try from > somewhere else, from something else. > > But... > > 1. It raises the bar. And it cuts down on the noise, which is one of the > security meta-problems we face: our logs capture so much cruft, so many > instances of attacks and abuse and mistakes and misconfigurations and > malfunctions, that we struggle to understand what they're trying to tell > us. That problem is so bad that there's an entire subindustry built > around the task of trying to reduce what's in the logs to something > that a human brain can process in finite time. Mountains of time > and wads of cash have been spent on the thorny problems that arise > when we try to figure out what to pay attention to and what to ignore... > and we still screw it up. Often. > > So even if the *only* effect of doing so is to shrink the size of > the logs: that's a win. (And used judiciously, it can be a HUGE win, > as in "several orders of magnitude".) So if your security guy is > as busy as you say...maybe this would be a good idea. > > And let me note in passing that by raising the bar, it ensures that > you're faced with a somewhat higher class of attacker. It's one > thing to be hacked by a competent, diligent adversary who wields > their tools with rapier-like precision; it's another to be owned > by a script kiddie who has no idea what they're doing and doesn't > even read the language your assets are using. That's just embarassing. > > 2. Outbound blocks work too, y'know. Does anybody in your marketing > department need to reach Elbonia? If not, then why are you allowing > packets from that group's desktops to go there? Because either > (a) it's someone doing something they shouldn't or (b) it's something doing > something it shouldn't, as in a bot trying to phone home or a data > exfiltration attack or something else unpleasant. So if there's > no business need for that group to exchange packets with Elbonia > or any of 82 other countries, why *aren't* you blocking that? > > 3. Yes, this can turn into a moderate-sized matrix of inbound and > outbound rules. That's why make(1) and similar tools are your friends, > because they'll let you manage this without needing to resort to scotch > by 9:30 AM. And yes, sometimes things will break (because something's > changed) -- but the brokeness is the best kind of brokeness: obvious, > deterministic, repeatable, fixable. > > It's not hard. But it does require that you actually know what your > own systems are doing and why. > > 4. "We were hacked from China" is wearing awfully damn thin as the > feeble whining excuse of people who should have bidirectionally firewalled > out China from their corporate infrastructure (note: not necessarily > their public-facing servers) years ago. And "our data was exfiltrated > to Elbonia" is getting thin as an excuse too: if you do not have an > organizational need to allow outbound network traffic to Elbonia, then > why the hell are you letting so much as a single packet go there? > > Like I said: at least make them work for it. A little. Instead of > doing profoundly idiotic things like the NYTimes (e.g., "infrastructure > reachable from the planet", "using M$ software", "actually believing that > anti-virus software will work despite a quarter-century of uninterrupted > failure", etc.). That's not making them work for it: that's inviting > them in, rolling out the red carpet, and handing them celebratory champagne. > > ---rsk > -- Kyle Creyts Information Assurance Professional BSidesDetroit Organizer From wbailey at satelliteintelligencegroup.com Tue Feb 26 17:19:48 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 26 Feb 2013 17:19:48 +0000 Subject: 10 Mbit/s problem in your network In-Reply-To: <867glvz4k8.fsf@valhalla.seastrom.com> References: <28915468.6329.1361118824719.JavaMail.root@benjamin.baylink.com> <000601ce1314$7eaec660$7c0c5320$@iname.com> <6D4636E8-F773-423D-8C80-A84B9851B181@delong.com> , <867glvz4k8.fsf@valhalla.seastrom.com> Message-ID: Perhaps I don't understand.. Generally in wireless we look at two things; bits to hertz and noise components. If the noise is LESS and the carrier is the same power spectral density, you will have a greater c/n. I've always wondered why wifi didn't implement an array of modcods which can be used with a given system. That way, when you attenuate you have lower efficiency modulation and coding which will allow you to deal with fades better. Maybe they do us it and I'm just not hip to 802.11? >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Rob Seastrom Date: 02/26/2013 3:40 AM (GMT-08:00) To: Owen DeLong Cc: Warren Bailey ,NANOG Subject: Re: 10 Mbit/s problem in your network Owen DeLong writes: > N on 5Ghz takes advantage of the increased bandwidth of the 5Ghz > channel where A merely replicated G on 5Ghz for all practical > purposes. You have that backwards, actually, but the legacy support in 802.11g for 802.11b clients does represent a performance hit even in the absence of b-only clients, so claiming that a and g are equivalent is only true on paper. -r (802.11a user before 802.11g, still love the relatively unoccupied 5 ghz spectrum) From wbailey at satelliteintelligencegroup.com Tue Feb 26 17:21:16 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Tue, 26 Feb 2013 17:21:16 +0000 Subject: Visio-fu In-Reply-To: <20130226080148.GA2606@besserwisser.org> References: , <20130226080148.GA2606@besserwisser.org> Message-ID: <91avvbk0nv18amhn7g8j5p1u.1361899271729@email.android.com> I purchased omni, but it is pretty difficult to get the hang of.. :/ >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: M?ns Nilsson Date: 02/26/2013 12:01 AM (GMT-08:00) To: Warren Bailey Cc: North American Network Operators Group Subject: Re: Visio-fu Subject: Visio-fu Date: Mon, Feb 25, 2013 at 08:20:34PM +0000 Quoting Warren Bailey (wbailey at satelliteintelligencegroup.com): > All, > > I have been searching our beloved internet endlessly for months on information regarding Visio technique. Does anyone have a good resource(s) for advanced visio drawings, or more to the point a good place for high quality connectors? There is some great quality work out there, this is something I found just a little while ago http://www.parallels.com/r/upload/figure2-1.gif > > This may not be a visio drawing (do not have any background on it), but I would really dig some resources that you guys out there may or may not use. The cables in that drawing look fantastic to me, so I would really appreciate any guidance you all have in helping me improve my output. I'd just quit beating the rotting carcass of Visio into producing anything not appalling and go with OmniGraffle instead. http://www.omnigroup.com/products/omnigraffle/ -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 DON'T go!! I'm not HOWARD COSELL!! I know POLISH JOKES ... WAIT!! Don't go!! I AM Howard Cosell! ... And I DON'T know Polish jokes!! From chip.gwyn at gmail.com Tue Feb 26 17:24:00 2013 From: chip.gwyn at gmail.com (chip) Date: Tue, 26 Feb 2013 12:24:00 -0500 Subject: BGP RIB Collection Message-ID: Hello all, I have an application that needs to gather BGP RIB data from the routers that connect to all of our upstream providers. Basically I need to know all the routes available from a particular provider. Currently I'm gathering this data via SNMP. While this works it has its draw backs, it takes approximately 20 minutes per view, its nowhere near real-time, and I'm unable to gather information for IPv6. SNMP, however, is faster than screen scraping. All of the XML based access methods seem to take about the same time as well. I've been watching, with keen interest, the i2rs ietf workings, but the project is still in its infancy. BMP seems to be a good solution but I've not found a working client implementation yet. I see that you can actually configure this on some Juniper gear but I can't seem to locate a client to ingest the data the router produces. The BGP Add Paths implementation seems to be the best choice at the moment and exabgp has a working implementation. Are there any other technologies or methods of accessing this data that I've missed or that you've found useful? Thanks! --chip -- Just my $.02, your mileage may vary, batteries not included, etc.... From jof at thejof.com Tue Feb 26 17:44:07 2013 From: jof at thejof.com (Jonathan Lassoff) Date: Tue, 26 Feb 2013 18:44:07 +0100 Subject: BGP RIB Collection In-Reply-To: References: Message-ID: Personally, I would just use BGP on a PC to collect this information. Place some import/input policy on your eBGP sessions on your edge routers to add communities to the routes such that you can recognize which peers gave you the route. Then, use an iBGP session to a BIRD or Quagga instance from which you can dump the routes and filter based on the communities. Cheers, jof On Tue, Feb 26, 2013 at 6:24 PM, chip wrote: > Hello all, > > I have an application that needs to gather BGP RIB data from the routers > that connect to all of our upstream providers. Basically I need to know > all the routes available from a particular provider. Currently I'm > gathering this data via SNMP. While this works it has its draw backs, it > takes approximately 20 minutes per view, its nowhere near real-time, and > I'm unable to gather information for IPv6. SNMP, however, is faster than > screen scraping. All of the XML based access methods seem to take about > the same time as well. > > I've been watching, with keen interest, the i2rs ietf workings, but the > project is still in its infancy. BMP seems to be a good solution but I've > not found a working client implementation yet. I see that you can actually > configure this on some Juniper gear but I can't seem to locate a client to > ingest the data the router produces. The BGP Add Paths implementation > seems to be the best choice at the moment and exabgp has a working > implementation. > > Are there any other technologies or methods of accessing this data that > I've missed or that you've found useful? > > Thanks! > > --chip > > -- > Just my $.02, your mileage may vary, batteries not included, etc.... From Valdis.Kletnieks at vt.edu Tue Feb 26 18:12:53 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 26 Feb 2013 13:12:53 -0500 Subject: Should host/domain names travel over the internet with a trailing dot? In-Reply-To: Your message of "Mon, 25 Feb 2013 19:07:20 -0600." References: <20130225143034.GN99258@numachi.com> <15455394.7034.1361803759023.JavaMail.root@benjamin.baylink.com> Message-ID: <7457.1361902373@turing-police.cc.vt.edu> On Mon, 25 Feb 2013 19:07:20 -0600, Jimmy Hess said: > If the domain in a certificate were not interpreted as a FQDN by the > client, this would mean, that the certificate for > CN=bigbank.example.com > might be used to authenticate a connection to https://bigbank.example.com > which do the local resolver search order, is in fact a DNS lookup of > bigbank.example.com.intranet.example.com > > Which might be captured by a Wildcard A record for *.com found in > the intranet.example.com. zone and pointed to a server > containing a phishing attack against bigbank.example.com; with a > DNS cache poisoned by a false negative cache NXDOMAIN entry for > bigbank.example.com. I am *sooo* tempted to say "I recommend my competitors do DNS lookups this way" :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From neil at tonal.clara.co.uk Tue Feb 26 19:18:14 2013 From: neil at tonal.clara.co.uk (Neil Harris) Date: Tue, 26 Feb 2013 19:18:14 +0000 Subject: 10 Mbit/s problem in your network In-Reply-To: References: <28915468.6329.1361118824719.JavaMail.root@benjamin.baylink.com> <000601ce1314$7eaec660$7c0c5320$@iname.com> <6D4636E8-F773-423D-8C80-A84B9851B181@delong.com> , <867glvz4k8.fsf@valhalla.seastrom.com> Message-ID: <512D0A76.1060102@tonal.clara.co.uk> On 26/02/13 17:19, Warren Bailey wrote: > Perhaps I don't understand.. Generally in wireless we look at two things; bits to hertz and noise components. If the noise is LESS and the carrier is the same power spectral density, you will have a greater c/n. I've always wondered why wifi didn't implement an array of modcods which can be used with a given system. That way, when you attenuate you have lower efficiency modulation and coding which will allow you to deal with fades better. Maybe they do us it and I'm just not hip to 802.11? They do it, all right, and much, much more, including MIMO -- 802.11 has evolved into something only marginally less complex than the mobile phone wireless stack in the process. -- N. From nick at foobar.org Tue Feb 26 19:21:42 2013 From: nick at foobar.org (Nick Hilliard) Date: Tue, 26 Feb 2013 19:21:42 +0000 Subject: BGP RIB Collection In-Reply-To: References: Message-ID: <512D0B46.9080709@foobar.org> On 26/02/2013 17:24, chip wrote: > Currently I'm gathering this data via SNMP. whoa, you must really hate your router to do that to it. > While this works it has its draw backs, it > takes approximately 20 minutes per view, its nowhere near real-time, and > I'm unable to gather information for IPv6. SNMP, however, is faster than > screen scraping. All of the XML based access methods seem to take about > the same time as well. cisco: -- term len 0 show bgp ipv4 unicast neigh x.y.z.w received-routes -- juniper: -- show route receive-protocol bgp x.y.z.w | no-more -- Easily scriptable using rancid or something similar. Of course, this sucks because you're only seeing the route summary, not any of the attributes. > project is still in its infancy. BMP seems to be a good solution but I've > not found a working client implementation yet. I see that you can actually > configure this on some Juniper gear but I can't seem to locate a client to > ingest the data the router produces. Can you provide a list of the clients that you have tried? It would save people the effort of going through them and finding out the same things as you did. Nick From kemp at network-services.uoregon.edu Wed Feb 27 00:16:00 2013 From: kemp at network-services.uoregon.edu (John Kemp) Date: Tue, 26 Feb 2013 16:16:00 -0800 Subject: BGP RIB Collection In-Reply-To: <512D0B46.9080709@foobar.org> References: <512D0B46.9080709@foobar.org> Message-ID: <512D5040.7090103@network-services.uoregon.edu> I'll chime in with what we are doing with quagga and bgpmon. The question though would be for how many peers? If it is for the sake of discussion, less than 20, something like this might work. http://bgpmon.netsec.colostate.edu/download/src/bgpmon-7.2.4.tar.gz http://rmcwic.ucar.edu/sites/default/files/posters/csuconf-final19.pdf We do some of this. The pure BGPmon way is to have neighbors peer directly with a BGPmon server. We've extended this a bit and we can stream quagga MRT update files into a bgpmon server as well. Then the BGPmon server internally constructs RIBs per session. Output format is XML, and the paper linked above describes some of the perl tools there are to look at xml streams. So you can get a RIB stream or an UPDATE stream from the BGPmon server. At some scale, this might give you what you need. I think the BMP solution looks pretty nice as well, since you are as close to your true platform as you can get. So I would also be interested in hearing if you find existing client code to parse the BMP. John Kemp (kemp at routeviews.org) > >> project is still in its infancy. BMP seems to be a good solution but I've >> not found a working client implementation yet. I see that you can actually >> configure this on some Juniper gear but I can't seem to locate a client to >> ingest the data the router produces. > > Can you provide a list of the clients that you have tried? It would save > people the effort of going through them and finding out the same things as > you did. > > Nick > > > From jeroen at mompl.net Wed Feb 27 01:45:18 2013 From: jeroen at mompl.net (Jeroen van Aart) Date: Tue, 26 Feb 2013 17:45:18 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: References: Message-ID: <512D652E.9000508@mompl.net> On 02/09/2013 07:55 PM, Constantine A. Murenin wrote: > When you are staying at a 3* hotel, should you have no expectations > that you'll be getting at least a 3Mbps pipe and at least an under > 100ms average latency, and won't be getting a balancer that would be > breaking up your ssh sessions? Correct, one should not have expectations of fast reliable internet with low latency in a hotel. For many reasons: - internet connectivity at a hotel is just another free amenity like after shyave or a hair net, be glad you can at least check your email :-) - a hotel room is (should be) used for sleeping, having sex, watching the tv idly, not for work (except emergencies and the likes), even when you're on a work trip. Use an actual office for work. - such internet connectivity doesn't exist to begin with for the average consumer in the USA Granted if a hotel markets itself as a business hotel in a business area it should include at least half decent internet connectivity, otherwise forget it and be glad you can spend some time away from the hedonistic attractions of "the net". Greetings, Jeroen -- Earthquake Magnitude: 4.2 Date: Tuesday, February 26, 2013 22:33:45 UTC Location: Gulf of Alaska Latitude: 59.6203; Longitude: -142.6829 Depth: 1.00 km From Valdis.Kletnieks at vt.edu Wed Feb 27 02:30:17 2013 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 26 Feb 2013 21:30:17 -0500 Subject: 10 Mbit/s problem in your network In-Reply-To: Your message of "Tue, 26 Feb 2013 17:45:18 -0800." <512D652E.9000508@mompl.net> References: <512D652E.9000508@mompl.net> Message-ID: <3462.1361932217@turing-police.cc.vt.edu> On Tue, 26 Feb 2013 17:45:18 -0800, Jeroen van Aart said: > Correct, one should not have expectations of fast reliable internet with > low latency in a hotel. The part that always puzzled me is why a major high-tier chain like Hilton can't get it right, but a Motel 6 can... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 865 bytes Desc: not available URL: From jra at baylink.com Wed Feb 27 02:45:54 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 26 Feb 2013 21:45:54 -0500 (EST) Subject: 10 Mbit/s problem in your network In-Reply-To: <512D652E.9000508@mompl.net> Message-ID: <6234920.7596.1361933154017.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jeroen van Aart" > - internet connectivity at a hotel is just another free amenity like > after shyave or a hair net, be glad you can at least check your email > :-) It is like hell. It is very often not one paid, but *unreasonably* expensive ($5-10 a *day*). If you don't know this, it's because you either 1) never looked, 2) were always in hotels on group rates where free access was negotiated in the contract or 3) were very very lucky. > Granted if a hotel markets itself as a business hotel in a business area > it should include at least half decent internet connectivity, otherwise > forget it and be glad you can spend some time away from the hedonistic > attractions of "the net". One word: "Conventions". No, it really *isn't* acceptable for a hotel not to have decent connectivity these days; would you tolerate a hotel where the power went out from 8-midnight every day? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jra at baylink.com Wed Feb 27 02:49:03 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 26 Feb 2013 21:49:03 -0500 (EST) Subject: 10 Mbit/s problem in your network In-Reply-To: <3462.1361932217@turing-police.cc.vt.edu> Message-ID: <25022406.7598.1361933343141.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Tue, 26 Feb 2013 17:45:18 -0800, Jeroen van Aart said: > > Correct, one should not have expectations of fast reliable internet > > with low latency in a hotel. > > The part that always puzzled me is why a major high-tier chain like > Hilton can't get it right, but a Motel 6 can... :) Ironically, I suspect that it's for the same reason that East Germany has right up to the minute telephony services these days, while West German is still sucking hind tit: The big properties are, over all, likely to skew somewhat older in building construction, and because of that, they're not built/wired for the internal transport; too much rebar in the walls blocking wifi and stuff like that. Plus they have more corporate inertia in actually getting it done. Or, they just don't care. They don't have to. They're... oh, nevermind. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From randy_94108 at yahoo.com Wed Feb 27 02:54:47 2013 From: randy_94108 at yahoo.com (Randy) Date: Tue, 26 Feb 2013 18:54:47 -0800 (PST) Subject: 10 Mbit/s problem in your network In-Reply-To: <3462.1361932217@turing-police.cc.vt.edu> Message-ID: <1361933687.72585.YahooMailClassic@web184703.mail.ne1.yahoo.com> --- On Tue, 2/26/13, Valdis.Kletnieks at vt.edu wrote: > From: Valdis.Kletnieks at vt.edu > Subject: Re: 10 Mbit/s problem in your network > To: "Jeroen van Aart" > Cc: nanog at nanog.org > Date: Tuesday, February 26, 2013, 6:30 PM > On Tue, 26 Feb 2013 17:45:18 -0800, > Jeroen van Aart said: > > > Correct, one should not have expectations of fast > reliable internet with > > low latency in a hotel. > > The part that always puzzled me is why a major high-tier > chain like Hilton > can't get it right, but a Motel 6 can... :) ...sure they can but don't want to because *customers* will still come! Motel 6 on the otherhand, does not have that cachet and have to try-harder! Just Economics; nothing personal...;-) ./Randy From randy_94108 at yahoo.com Wed Feb 27 03:51:47 2013 From: randy_94108 at yahoo.com (Randy) Date: Tue, 26 Feb 2013 19:51:47 -0800 (PST) Subject: BGP RIB Collection In-Reply-To: <512D0B46.9080709@foobar.org> Message-ID: <1361937107.63906.YahooMailClassic@web184703.mail.ne1.yahoo.com> *received-routes*? If you still enable soft-reconfig-inbound on your routers(customer-facing sessions not withstanding), you most certainly hate your routers more than OP...;-) ./Randy --- On Tue, 2/26/13, Nick Hilliard wrote: > From: Nick Hilliard > Subject: Re: BGP RIB Collection > To: "chip" > Cc: "North American Network Operators Group" > Date: Tuesday, February 26, 2013, 11:21 AM > On 26/02/2013 17:24, chip wrote: > > Currently I'm gathering this data via SNMP. > > whoa, you must really hate your router to do that to it. > > > While this works it has its draw backs, it > > takes approximately 20 minutes per view, its nowhere > near real-time, and > > I'm unable to gather information for IPv6.? SNMP, > however, is faster than > > screen scraping.? All of the XML based access > methods seem to take about > > the same time as well. > > cisco: > -- > term len 0 > show bgp ipv4 unicast neigh x.y.z.w received-routes > -- > > juniper: > -- > show route receive-protocol bgp x.y.z.w | no-more > -- > > Easily scriptable using rancid or something similar.? > Of course, this sucks > because you're only seeing the route summary, not any of the > attributes. > > > project is still in its infancy.? BMP seems to be > a good solution but I've > > not found a working client implementation yet.? I > see that you can actually > > configure this on some Juniper gear but I can't seem to > locate a client to > > ingest the data the router produces. > > Can you provide a list of the clients that you have > tried?? It would save > people the effort of going through them and finding out the > same things as > you did. > > Nick > > > > From owen at delong.com Wed Feb 27 03:54:01 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Feb 2013 19:54:01 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: <512D652E.9000508@mompl.net> References: <512D652E.9000508@mompl.net> Message-ID: On Feb 26, 2013, at 5:45 PM, Jeroen van Aart wrote: > On 02/09/2013 07:55 PM, Constantine A. Murenin wrote: >> When you are staying at a 3* hotel, should you have no expectations >> that you'll be getting at least a 3Mbps pipe and at least an under >> 100ms average latency, and won't be getting a balancer that would be >> breaking up your ssh sessions? > > Correct, one should not have expectations of fast reliable internet with low latency in a hotel. > > For many reasons: > > - internet connectivity at a hotel is just another free amenity like after shyave or a hair net, be glad you can at least check your email :-) > This argument fails when compared to my real world observations. In general, my experience has been that the hotels that offer wifi as a free amenity have relatively uncomplicated systems, you get a password (if one is required at all) when you check in or when you ask for it and it just works. In contrast, the more expensive hotels that charge have elaborate systems designed to make sure they can capture that revenue and that nobody gets on without paying. These systems are often poorly implemented, poorly managed and extremely prone to various forms of failure resulting in a loss of connectivity. The people at the other end of the phone when one calls about such problems tend to think nothing of rebooting WAPs, etc. in order to try and "shotgun" the user's problem, creating a multitude of additional failures for all the other users. > - a hotel room is (should be) used for sleeping, having sex, watching the tv idly, not for work (except emergencies and the likes), even when you're on a work trip. Use an actual office for work. > This is a rather arrogant value judgment for you to think that you have a right to inflict on everyone else. > - such internet connectivity doesn't exist to begin with for the average consumer in the USA > I'm not sure I go quite that far, but, yes, it is not uncommon for people to have less than this level of connectivity in their residential environments in the US. > Granted if a hotel markets itself as a business hotel in a business area it should include at least half decent internet connectivity, otherwise forget it and be glad you can spend some time away from the hedonistic attractions of "the net". Yet my experience has been that to a large extent, the reverse is true. I am more likely to get better internet connectivity from a low-budget tourist motel in a tourist area than from a "business hotel" in a business area. Hilton owned properties are among the worst in this respect and my recent experience at the Hilton LAX has confirmed that they haven't gotten any better. Owen From wbailey at satelliteintelligencegroup.com Wed Feb 27 03:58:01 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 27 Feb 2013 03:58:01 +0000 Subject: 10 Mbit/s problem in your network In-Reply-To: <6234920.7596.1361933154017.JavaMail.root@benjamin.baylink.com> References: <512D652E.9000508@mompl.net>, <6234920.7596.1361933154017.JavaMail.root@benjamin.baylink.com> Message-ID: <8pueq6hgjq9f6a079mmgplvk.1361937477004@email.android.com> Clearly a person making a comment about high speed Internet not being important in hotel rooms has not tried to stream the type of entertainment generally viewed in a hotel room. You view a "movie" that buffers every 10 seconds, it has a fantastic way of killing the moment.. ;) >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Jay Ashworth Date: 02/26/2013 6:47 PM (GMT-08:00) To: NANOG Subject: Re: 10 Mbit/s problem in your network ----- Original Message ----- > From: "Jeroen van Aart" > - internet connectivity at a hotel is just another free amenity like > after shyave or a hair net, be glad you can at least check your email > :-) It is like hell. It is very often not one paid, but *unreasonably* expensive ($5-10 a *day*). If you don't know this, it's because you either 1) never looked, 2) were always in hotels on group rates where free access was negotiated in the contract or 3) were very very lucky. > Granted if a hotel markets itself as a business hotel in a business area > it should include at least half decent internet connectivity, otherwise > forget it and be glad you can spend some time away from the hedonistic > attractions of "the net". One word: "Conventions". No, it really *isn't* acceptable for a hotel not to have decent connectivity these days; would you tolerate a hotel where the power went out from 8-midnight every day? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From wbailey at satelliteintelligencegroup.com Wed Feb 27 04:00:12 2013 From: wbailey at satelliteintelligencegroup.com (Warren Bailey) Date: Wed, 27 Feb 2013 04:00:12 +0000 Subject: 10 Mbit/s problem in your network In-Reply-To: <1361933687.72585.YahooMailClassic@web184703.mail.ne1.yahoo.com> References: <3462.1361932217@turing-police.cc.vt.edu>, <1361933687.72585.YahooMailClassic@web184703.mail.ne1.yahoo.com> Message-ID: And the fact that a motel 6 is generally owned by a private owner, versus big box chains that are massively corporate. As Internet is free, it's a it a concern to them. The little guy has to Try harder, which leads to generally a better service. >From my Android phone on T-Mobile. The first nationwide 4G network. -------- Original message -------- From: Randy Date: 02/26/2013 6:56 PM (GMT-08:00) To: Jeroen van Aart ,Valdis.Kletnieks at vt.edu Cc: nanog at nanog.org Subject: Re: 10 Mbit/s problem in your network --- On Tue, 2/26/13, Valdis.Kletnieks at vt.edu wrote: > From: Valdis.Kletnieks at vt.edu > Subject: Re: 10 Mbit/s problem in your network > To: "Jeroen van Aart" > Cc: nanog at nanog.org > Date: Tuesday, February 26, 2013, 6:30 PM > On Tue, 26 Feb 2013 17:45:18 -0800, > Jeroen van Aart said: > > > Correct, one should not have expectations of fast > reliable internet with > > low latency in a hotel. > > The part that always puzzled me is why a major high-tier > chain like Hilton > can't get it right, but a Motel 6 can... :) ...sure they can but don't want to because *customers* will still come! Motel 6 on the otherhand, does not have that cachet and have to try-harder! Just Economics; nothing personal...;-) ./Randy From owen at delong.com Wed Feb 27 03:57:44 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Feb 2013 19:57:44 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: <25022406.7598.1361933343141.JavaMail.root@benjamin.baylink.com> References: <25022406.7598.1361933343141.JavaMail.root@benjamin.baylink.com> Message-ID: On Feb 26, 2013, at 6:49 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Valdis Kletnieks" > >> On Tue, 26 Feb 2013 17:45:18 -0800, Jeroen van Aart said: >>> Correct, one should not have expectations of fast reliable internet >>> with low latency in a hotel. >> >> The part that always puzzled me is why a major high-tier chain like >> Hilton can't get it right, but a Motel 6 can... :) > > Ironically, I suspect that it's for the same reason that East Germany has > right up to the minute telephony services these days, while West German is > still sucking hind tit: > > The big properties are, over all, likely to skew somewhat older in > building construction, and because of that, they're not built/wired > for the internal transport; too much rebar in the walls blocking wifi > and stuff like that. > In fact, many of the hotels that have solved this intelligently have simply placed DSLAMs in the phone room and run DSL to each room with a relatively inexpensive (especially when you buy 500 of them at a time) DSL modem in each room. Some also have wifi, some have wifi in the room from the DSL modem, but in most cases, these have been among the best functioning solutions in some of the larger properties. > Plus they have more corporate inertia in actually getting it done. > Hyatt does a consistently better job of this than Hilton in my experience. Same with Motel 6. I would expect them to have roughly equivalent corporate inertia. > Or, they just don't care. They don't have to. They're... oh, never mind. I think this is the larger factor, yes. Owen From jra at baylink.com Wed Feb 27 04:03:58 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 26 Feb 2013 23:03:58 -0500 (EST) Subject: 10 Mbit/s problem in your network In-Reply-To: Message-ID: <6072919.7610.1361937838269.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Owen DeLong" [ quoting me ] > > Ironically, I suspect that it's for the same reason that East Germany has > > right up to the minute telephony services these days, while West German is > > still sucking hind tit: > > > > The big properties are, over all, likely to skew somewhat older in > > building construction, and because of that, they're not built/wired > > for the internal transport; too much rebar in the walls blocking > > wifi and stuff like that. A comment off list pointed out to me that sometimes, it's the reverse: The property jumped on-board in the late nineties, putting in a system worthy of the next decade... and has never updated it, cause it's "good enough". Cheers, -- jr 'sorry to hijack your post to quote myself, Owen' a -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jeff-kell at utc.edu Wed Feb 27 04:07:50 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 26 Feb 2013 23:07:50 -0500 Subject: 10 Mbit/s problem in your network In-Reply-To: References: <25022406.7598.1361933343141.JavaMail.root@benjamin.baylink.com> Message-ID: <512D8696.4020907@utc.edu> On 2/26/2013 10:57 PM, Owen DeLong wrote: > In fact, many of the hotels that have solved this intelligently have > simply placed DSLAMs in the phone room and run DSL to each room with a > relatively inexpensive (especially when you buy 500 of them at a time) > DSL modem in each room. Some also have wifi, some have wifi in the > room from the DSL modem, but in most cases, these have been among the > best functioning solutions in some of the larger properties. While other more brain-dead properties are streaming their TV content over wireless (have seen this more than once)... Jeff From nathana at fsr.com Wed Feb 27 04:23:33 2013 From: nathana at fsr.com (Nathan Anderson) Date: Tue, 26 Feb 2013 20:23:33 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: References: <25022406.7598.1361933343141.JavaMail.root@benjamin.baylink.com> Message-ID: On Tuesday, February 26, 2013 7:58 PM, Owen DeLong wrote: > In fact, many of the hotels that have solved this intelligently have > simply > placed DSLAMs in the phone room and run DSL to each room with > a relatively inexpensive (especially when you buy 500 of them at a time) > DSL modem in each room. ...or more likely (at least in my own probably limited experience), a CMTS and cable modems instead of a DSLAM and DSL modems. Probably because so many of these hotels have an existing digital PBX system that drives all the phones in the rooms which isn't going to take very kindly to sharing its copper with a DSLAM, and because they already have coax run throughout the place to drive the televisions. Easier to share the existing coax with a CMTS than it is to stretch a bunch of new telephone wire dedicated just to DSL; I mean, at that point, you might as well just pull some Ethernet. -- Nathan Anderson First Step Internet, LLC nathana at fsr.com From jra at baylink.com Wed Feb 27 04:35:17 2013 From: jra at baylink.com (Jay Ashworth) Date: Tue, 26 Feb 2013 23:35:17 -0500 (EST) Subject: Hotel internet connectivity In-Reply-To: Message-ID: <15267450.7626.1361939717190.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Nathan Anderson" > > In fact, many of the hotels that have solved this intelligently have > > simply placed DSLAMs in the phone room and run DSL to each room with > > a relatively inexpensive (especially when you buy 500 of them at a > > time) DSL modem in each room. > > ...or more likely (at least in my own probably limited experience), a > CMTS and cable modems instead of a DSLAM and DSL modems. I don't spend a lot of time in a lot of hotels, but every hardwire I have seen with my own personal eyeballs was indeed DSL. Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jeff-kell at utc.edu Wed Feb 27 04:45:22 2013 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 26 Feb 2013 23:45:22 -0500 Subject: Hotel internet connectivity In-Reply-To: <15267450.7626.1361939717190.JavaMail.root@benjamin.baylink.com> References: <15267450.7626.1361939717190.JavaMail.root@benjamin.baylink.com> Message-ID: <512D8F62.2060702@utc.edu> On 2/26/2013 11:35 PM, Jay Ashworth wrote: > I don't spend a lot of time in a lot of hotels, but every hardwire I > have seen with my own personal eyeballs was indeed DSL. Cheers, -- jra Hrmm... Ramada Inn, Okaloosa Island resort outside Fort Walton Beach (kinda your neighborhood Jay) two years ago had Cisco LRE boxes in the room for wired connectivity (no wireless when I was there). And lots of actual ethernet elsewhere. Jeff From rjubio at gmail.com Wed Feb 27 05:35:24 2013 From: rjubio at gmail.com (Rod James Bio) Date: Wed, 27 Feb 2013 13:35:24 +0800 Subject: Question about FibroLAN Falcon-x Message-ID: <512D9B1C.2020408@gmail.com> Hello All! Just a quick question. Anybody here had experience with Falcon-X of Fibrolan? How do you rate itas a MetroE ringswitch? They have a very competitive price and we are now considering using them. P.S. I'm not sure if this kind of questions are allowed to be on this list, if notI would appreciate even a private mail to me. Thanks! -- Rod Bio From mureninc at gmail.com Wed Feb 27 05:53:38 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Tue, 26 Feb 2013 21:53:38 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: <6072919.7610.1361937838269.JavaMail.root@benjamin.baylink.com> References: <6072919.7610.1361937838269.JavaMail.root@benjamin.baylink.com> Message-ID: On 26 February 2013 20:03, Jay Ashworth wrote: > ---- Original Message ----- >> From: "Owen DeLong" > > [ quoting me ] >> > Ironically, I suspect that it's for the same reason that East Germany has >> > right up to the minute telephony services these days, while West German is >> > still sucking hind tit: >> > >> > The big properties are, over all, likely to skew somewhat older in >> > building construction, and because of that, they're not built/wired >> > for the internal transport; too much rebar in the walls blocking >> > wifi and stuff like that. > > A comment off list pointed out to me that sometimes, it's the reverse: > > The property jumped on-board in the late nineties, putting in a system > worthy of the next decade... > > and has never updated it, cause it's "good enough". Brand new Hyatt Place in NorCal, less than 2 years old, Fast Ethernet in every room: This is a smokeping of their SureWest (ADSL or FFTH) connection, all within NorCal, ~20ms latency on a good millisecond: http://www.dslreports.com/r3/smokeping.cgi?target=network.9b37669cada3f00d348b647453067844.CA1 (half-second latency is common, above 1s latency is not unheard of) This is a smokeping of their AT&T (T1?), which seems to be only marginally better, but on a good millisecond, it's only 10ms: http://www.dslreports.com/r3/smokeping.cgi?target=network.bb79d93501996d88968e851234250c6a.CA1 Time on the graph is in dslr timezone (ET), not in hotel's time (PT), but the trends are pretty obvious. Now. Good luck typing and then editing that that rm -rf in your ssh! Or picking up that conference call through a VPN. C. From owen at delong.com Wed Feb 27 05:55:52 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Feb 2013 21:55:52 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: References: <25022406.7598.1361933343141.JavaMail.root@benjamin.baylink.com> Message-ID: <039C9690-7B78-4637-8C1C-0A4872B110DF@delong.com> On Feb 26, 2013, at 8:23 PM, Nathan Anderson wrote: > On Tuesday, February 26, 2013 7:58 PM, Owen DeLong wrote: > >> In fact, many of the hotels that have solved this intelligently have >> simply >> placed DSLAMs in the phone room and run DSL to each room with >> a relatively inexpensive (especially when you buy 500 of them at a time) >> DSL modem in each room. > > ...or more likely (at least in my own probably limited experience), a CMTS and cable modems instead of a DSLAM and DSL modems. Probably because so many of these hotels have an existing digital PBX system that drives all the phones in the rooms which isn't going to take very kindly to sharing its copper with a DSLAM, and because they already have coax run throughout the place to drive the televisions. Easier to share the existing coax with a CMTS than it is to stretch a bunch of new telephone wire dedicated just to DSL; I mean, at that point, you might as well just pull some Ethernet. > I haven't encountered many CMTS-based systems in hotels where I've stayed (and I stay in quite a few every year). In most cases, the digital phone system uses 1 pair of the 2-pair wiring and the DSL modem uses the other pair. Owen From paigeadele at gmail.com Wed Feb 27 06:24:25 2013 From: paigeadele at gmail.com (Adele Thompson) Date: Tue, 26 Feb 2013 22:24:25 -0800 Subject: NYT covers China cyberthreat In-Reply-To: References: <20130220162948.87B4F422@m0005297.ppops.net> <20130221160024.GA19523@gsp.org> <2A76E400AC84B845AAC35AA19F8E7A5D0E81134F@MUNEXBE1.medline.com> <20130226114308.GA31240@gsp.org> Message-ID: On Tue, Feb 26, 2013 at 8:39 AM, Kyle Creyts wrote: > I think it is safe to say that finding a foothold inside of the United > States from which to perform/proxy an attack is not the hardest thing > in the world. I don't understand why everyone expects that major > corporations and diligent operators blocking certain countries' > prefixes will help. That being said, you make a solid point to which > people should absolutely listen: applying an understanding of your > business-needs-network-traffic baseline to your firewall rules and > heuristic network detections (in a more precise fashion than just "IPs > from country $x") is a SOLID tactic that yields huge security > benefits. Nobody who cares about security should really be able to > argue with it (plenty of those who care don't will hate it, though), > and makes life _awful_ for any attackers. > > On Tue, Feb 26, 2013 at 3:43 AM, Rich Kulawiec wrote: > > On Thu, Feb 21, 2013 at 11:47:44AM -0600, Naslund, Steve wrote: > > > > [a number of very good points ] > > > > Geoblocking, like passive OS fingerprinting (another technique that > > reduces attack surface as measured along one axis but can be defeated > > by a reasonably clueful attacker), doesn't really solve problems, per se. > > If you have a web app that's vulnerable to SQL injection attacks, then > > it's still just as hackable -- all the attacker has to do is try from > > somewhere else, from something else. > > > > But... > > > > 1. It raises the bar. And it cuts down on the noise, which is one of the > > security meta-problems we face: our logs capture so much cruft, so many > > instances of attacks and abuse and mistakes and misconfigurations and > > malfunctions, that we struggle to understand what they're trying to tell > > us. That problem is so bad that there's an entire subindustry built > > around the task of trying to reduce what's in the logs to something > > that a human brain can process in finite time. Mountains of time > > and wads of cash have been spent on the thorny problems that arise > > when we try to figure out what to pay attention to and what to ignore... > > and we still screw it up. Often. > > > > So even if the *only* effect of doing so is to shrink the size of > > the logs: that's a win. (And used judiciously, it can be a HUGE win, > > as in "several orders of magnitude".) So if your security guy is > > as busy as you say...maybe this would be a good idea. > > > > And let me note in passing that by raising the bar, it ensures that > > you're faced with a somewhat higher class of attacker. It's one > > thing to be hacked by a competent, diligent adversary who wields > > their tools with rapier-like precision; it's another to be owned > > by a script kiddie who has no idea what they're doing and doesn't > > even read the language your assets are using. That's just embarassing. > > > > 2. Outbound blocks work too, y'know. Does anybody in your marketing > > department need to reach Elbonia? If not, then why are you allowing > > packets from that group's desktops to go there? Because either > > (a) it's someone doing something they shouldn't or (b) it's something > doing > > something it shouldn't, as in a bot trying to phone home or a data > > exfiltration attack or something else unpleasant. So if there's > > no business need for that group to exchange packets with Elbonia > > or any of 82 other countries, why *aren't* you blocking that? > > > > 3. Yes, this can turn into a moderate-sized matrix of inbound and > > outbound rules. That's why make(1) and similar tools are your friends, > > because they'll let you manage this without needing to resort to scotch > > by 9:30 AM. And yes, sometimes things will break (because something's > > changed) -- but the brokeness is the best kind of brokeness: obvious, > > deterministic, repeatable, fixable. > > > > It's not hard. But it does require that you actually know what your > > own systems are doing and why. > > > > 4. "We were hacked from China" is wearing awfully damn thin as the > > feeble whining excuse of people who should have bidirectionally > firewalled > > out China from their corporate infrastructure (note: not necessarily > > their public-facing servers) years ago. And "our data was exfiltrated > > to Elbonia" is getting thin as an excuse too: if you do not have an > > organizational need to allow outbound network traffic to Elbonia, then > > why the hell are you letting so much as a single packet go there? > > > > Like I said: at least make them work for it. A little. Instead of > > doing profoundly idiotic things like the NYTimes (e.g., "infrastructure > > reachable from the planet", "using M$ software", "actually believing that > > anti-virus software will work despite a quarter-century of uninterrupted > > failure", etc.). That's not making them work for it: that's inviting > > them in, rolling out the red carpet, and handing them celebratory > champagne. > > > > ---rsk > > > > > > -- > Kyle Creyts > > Information Assurance Professional > BSidesDetroit Organizer > > I've been doing some thinking about the internet tonight and came across this e-mail by which I am intrigued. Currently we suffer from DDoS downtime on Rackspace (granted it's a very small amount of time, its a hit to our only single point of failure for which I am currently trying to solve by obtaining a /24 and an anycast address as a means of mitigation and providing a highly available HTTP cluster of load balancers. I can't help but wonder if the cost (both in ipv4 resources and cash) outweighs the worth of an environment that is sanctioned from the globe. While cloud hosting has proven to be a scalable solution for our needs, we currently are only serving US-based organizations as far as I know. Even so, the desire to grow beyond that isn't far fetched when adding networks that are still segregated from access outside of a country becomes more available (kinda like vlans.) Germany, Russia, and Spain. > > "IN vain is the net spread in the sight of anybird," especially if the > bird be as keen-eyed asPrince Bismarck. The Carlist attempts to irritateGermany > into intervention ?whether by > > firing on her gunboats, or, as report says,attempting to take prisoners > the German andAustrian representatives to Madrid in the courseof their > railway journey, or by any other means?have been, and will be, failures. > Prince Bismarck knows as well as anybody that nothingwould give so > effectual a spur to the Carlistcause as a German intervention against it, > andwe may therefore well believe his organ when ittells us that nothing > so wild as the project oflanding German troops in Spain was ever contemplated > by him. Prince Bismarck was wiseenough, even during the war with France, > whenthe German power was already in possession,and was on the spot, to > avoid anythinglike taking a part between the differentpolitical factions > into which France was divided.Is it reasonable to suppose that, after > keeping socarefully out of the net with which his feet werealmost in > contact in France, he would allow himself to be entangled in it in Spain > ? The realdanger on the Franco-Spanish frontier is not ofa German > intervention in Spain, but of jealousiesgrowing up between Germany and > France sokeen as to render a renewal of the war all butinevitable. No > doubt that would suit PrinceBismarck's book much better than a barren > intervention in Spain. No doubt his agents are notparticularly delicate > in their modes of insistingthat France shall cut off all supplies from theCarlist > forces, and in indirectly reminding Frenchmen of the difference beween > their position now,when they are kept to their internationalduties > towards Spain by the watchful eye ofGermany, and their position four yearsago, > when they made the mere suggestion of aGerman candidate for the throne of > Spain aground of affront, and ultimately a cause of war.We do not suppose > that Prince Bismarck wishesfor another big war, and all the new odium itwould > bring on the victor, but if it must come,no doubt he would like it to > come soon. It wasa good notion of his to pose as the protector ofthe > regency of Marshal Serrano in Spain, and sowin an ally south of the > Pyrenees, as well assouth of the Alps. But in spite of his no doubtsincere > wish to see Ultramontanism defeated inthe defeat of Don Carlos, it is > pretty certainthat his Spanish policy is studied much morewith a view to > crippling France, than with aview to crippling Rome.There is indeed > something encouraging in theclear evidence afforded, both by Prince Bismarck's > and by Prince GortschakofTs policyin regard to Spain?though these > policies aredifferent -that even the least teachable of thegreat European > Powers have learned the lessonthat interventions for the purpose of > settling theinternal disputes of any great nation are thesilliest of > mistakes. Germany has recognised,and has probably persuaded various other > greatPowers to recognise, the Government of Madrid,while Russia declines > to recognise it; but evenRussia carefully explains that her reason for > holding back is not any wish to strengthen the hopes ofthe Carlist > insurrection, but rather on even greaterdelicacy than that shown by the > other Powersfor the free choice of the Spanish nation, and areluctance > therefore to enter into formal relations with a Government which, since > GeneralPavin's coup Witat, has had no sanctionfrom the will of the > people. Nodoubt one may fairly smile at the reasongiven, when it comes > from the Ministerof Russia. No doubt it is quite natural to suspect that > other motives mingle with the refusal?the dislike to follow implicitly > German lead?the uueasiuess lest the example of Spain shouldbe eventually > pleaded for Republican institutions;but even though it be so, the fact > remains thatRussia offers an almost pedantically constitutional reason > for refusing to acknowledge as yetthe Government of Marshal Serrano, and > wishesto be understood as setting an example of evengreater delicacy and > greater deference to thewishes of the Spanish nation than either GreatBritain > or France. No doubt Russia Las pushedthe doctrine to an extreme, if she > has allowedher deference to the wishes of the Spanishpeople to prevent > her from recognising a Government the continuance of which she would thinka > great safeguard to the peace of Europe. Inpoint of fact, Russia, in all > probability, holds nosuch opinion. The Greek Church is too wellestablished > and too popular in Russia to makeit a matter of any account to her > whether thenew Government of Spain be Ultramontane orotherwise, while it > can never be a matter ofabsolute indifference to the Czar of Russiawhether > another European people throws offthe monarchy or not. If Don Carlos were > tosucceed, at least the Republican current ofevents would be reversed for > a time. Butwhether the success of Marshal Serrano willmean a Republican > or a Throne for Spain is amatter extremely doubtful. On the otherhand, to > neither Germany, nor England, norItaly can it fail to be a matter of some > interestwhether or not a new stimulus or a new checkis to be applied to > Ultramontane zeaL And asregards France, the Government of MarshalMacMahon > has a very difficult problem to solve.Doubtless the Extreme Right, and > with theExtreme Right the whole Sacerdotal party,would prefer to see Don > Carlos succeed, sincesuch a success would be a new ground of hopefor > Henri V. and the white flag. But thenMarshal MacMahon has been obliged to > quarrelwith the Extreme Right, who make light of hisSepteunate, and > affect to treat him as a merelocum tenena for the coming king. Hence it isessential > for him to secure a certain amount ofmoderate Liberal support, and the > regency ofMarshal Serrano is so very homogeneous a kindof power to his > own?namely, a mere excuse fordelay?that he can hardly fail to feel a > certainsympathy with its position. Add to this theextreme desirability of > conceding to Germanyall that can be conceded while the fears of quarreland > the occasions of quarrel are still so numerous,and we do not doubt that a > very wise decision hasbeen taken, even in the interest of the Government > itself, in recognising the de facto Government of Madrid. On the whole, > we regard itas a very satisfactory evidence of the progressmade in > mastering elementary Constitutionalideas, eveu by the most despotic > Powers, thatall the great Powers alike repudiate intervention > Fix this text > in Spain, and use even their fair privilege ofgiving a sort of moral > support to that one ofthe rival Governments which they think be3tcalculated > to maintain the peace of Europe, withgreat reserve and moderation. The > day of HolyAlliances to mould the internal institutions ofrefractory > countries is now, at last, probablypast, aud with these, the day of some > of themoot mischievous European combinations whichthe world has ever > seen.? Spectator. > > It is learned that the arrest of Count YonAmiin was effected without the > knowledge of theEmperor. The musing documents hare beengiven to the > Ultraniontanes by Deputy Windernorst. > From rol at witbe.net Wed Feb 27 07:53:57 2013 From: rol at witbe.net (Paul Rolland (=?UTF-8?B?44Od44O844Or44O744Ot44Op44Oz?=)) Date: Wed, 27 Feb 2013 08:53:57 +0100 Subject: BGP RIB Collection In-Reply-To: References: Message-ID: <20130227085357.63bda5f5@tux.DEF.witbe.net> Hello, On Tue, 26 Feb 2013 12:24:00 -0500 chip wrote: > I have an application that needs to gather BGP RIB data from the routers > that connect to all of our upstream providers. Basically I need to know > all the routes available from a particular provider. Currently I'm > gathering this data via SNMP. While this works it has its draw backs, it > takes approximately 20 minutes per view, its nowhere near real-time, and > I'm unable to gather information for IPv6. SNMP, however, is faster than > screen scraping. All of the XML based access methods seem to take about > the same time as well. To do that, I've set up a peering session between a router and a Linux running exabgp connected to a script in which I can do any kind of processing I want on BGP updates that are forwarded from the router to exabgp to the script. Best, Paul -- TelcoTV Awards 2011 - Witbe winner in "Innovation in Test & Measurement" Paul Rolland E-Mail : rol(at)witbe.net CTO - Witbe.net SA Tel. +33 (0)1 47 67 77 77 Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99 F-92057 Paris La Defense RIPE : PR12-RIPE LinkedIn : http://www.linkedin.com/in/paulrolland Skype : rollandpaul "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" --Mike Godwin, Electronic Frontier Foundation -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From nick at foobar.org Wed Feb 27 12:42:01 2013 From: nick at foobar.org (Nick Hilliard) Date: Wed, 27 Feb 2013 12:42:01 +0000 Subject: BGP RIB Collection In-Reply-To: <1361937107.63906.YahooMailClassic@web184703.mail.ne1.yahoo.com> References: <1361937107.63906.YahooMailClassic@web184703.mail.ne1.yahoo.com> Message-ID: <512DFF19.8070704@foobar.org> On 27/02/2013 03:51, Randy wrote: > *received-routes*? > If you still enable soft-reconfig-inbound on your routers(customer-facing sessions not withstanding), you most certainly hate your routers more than OP...;-) it impacts memory, but if your management plane has enough memory to handle it, it's a useful debugging tool. For sure, it's the first thing I throw out if the management plane RAM runs short. SNMP polling of large router lists can work out as O(n^2) CPU usage if the router stores the polled objects as linked lists or in some cases, in tree structures. This is because snmpgetnext cannot maintain a pointer to the next object, which in some situations will mean a complete tree walk operation. So your CPU requirements will scale according to (size of structure) * (average number of complete walks through the structure). If you're using linked lists, or have a naive tree implementation, "average number of complete walks through the structure" = "size of structure" / 2 for a full tree walk. I.e. you can require (n^2)/2 complete runs through the structure in order to run a full snmp dump. Obviously this isn't always the case, but there are some well known examples of where it happens. For all its faults, soft-reconfig-inbound only adds O(N) to RAM requirements and almost nothing to CPU. Nick > ./Randy > > --- On Tue, 2/26/13, Nick Hilliard wrote: > >> From: Nick Hilliard >> Subject: Re: BGP RIB Collection >> To: "chip" >> Cc: "North American Network Operators Group" >> Date: Tuesday, February 26, 2013, 11:21 AM >> On 26/02/2013 17:24, chip wrote: >>> Currently I'm gathering this data via SNMP. >> >> whoa, you must really hate your router to do that to it. >> >>> While this works it has its draw backs, it >>> takes approximately 20 minutes per view, its nowhere >> near real-time, and >>> I'm unable to gather information for IPv6. SNMP, >> however, is faster than >>> screen scraping. All of the XML based access >> methods seem to take about >>> the same time as well. >> >> cisco: >> -- >> term len 0 >> show bgp ipv4 unicast neigh x.y.z.w received-routes >> -- >> >> juniper: >> -- >> show route receive-protocol bgp x.y.z.w | no-more >> -- >> >> Easily scriptable using rancid or something similar. >> Of course, this sucks >> because you're only seeing the route summary, not any of the >> attributes. >> >>> project is still in its infancy. BMP seems to be >> a good solution but I've >>> not found a working client implementation yet. I >> see that you can actually >>> configure this on some Juniper gear but I can't seem to >> locate a client to >>> ingest the data the router produces. >> >> Can you provide a list of the clients that you have >> tried? It would save >> people the effort of going through them and finding out the >> same things as >> you did. >> >> Nick >> >> >> >> > From tritran at cox.net Wed Feb 27 06:01:26 2013 From: tritran at cox.net (Tri Tran) Date: Tue, 26 Feb 2013 22:01:26 -0800 Subject: ethernet in Socal Message-ID: <512DA136.7070909@cox.net> I'm evaluating between cBeyond, Cox, and Megapath. Anyone have experience with their ethernet over copper or fiber products? How are their reliability, service, and performance? Regards, Tri Tran From chindy at lwpca.net Wed Feb 27 12:30:43 2013 From: chindy at lwpca.net (Chris Hindy) Date: Wed, 27 Feb 2013 12:30:43 +0000 Subject: 10 Mbit/s problem in your network In-Reply-To: <6072919.7610.1361937838269.JavaMail.root@benjamin.baylink.com> Message-ID: >The property jumped on-board in the late nineties, putting in a system >worthy of the next decade... >and has never updated it, cause it's "good enough". This is more likely the root cause of this particular problem?you see a lot of crufty old access points in the big chains, at least in hotels that bought into wifi in the late 90's or early 2000's. These things are not optimized to their environments, and the environments they have to work in are pretty sucky for el-cheapo 2.4GHz radios to work in. I'm a Marriott fan, having spent at least 150 nights a year in the past three years under their sheets, and their Internet offerings range from pretty darned good (Marriott Alpharetta, newish, built in '08 or '09) to downright awful (Marriott IAD, I'm looking in your direction?) The correlation between "downright awful" and "installed early on in the cycle" is strong. Like others mention, I carry around a lightweight, portable, doesn't-take-up-much-space, was-ridiculously-cheap-at-a-Target-in-Chicago access point that I use when hotel wifi isn't up to snuff (Residence Inn North Loop, I'm looking in your direction?) -- it's cheap and easy and lets me get MLB TV on the iPad while on the road with little interruption. The point, which I've wandered away from a bit, is that a lot of these chains probably have put the wifi and network infrastructure on a ten year amortization schedule, and it's only recently wound down to $0. Hopefully that means they're going to start investing in new kit and generally improving stuff. My .02c-worth, -c On 26-02-2013 11:03 PM, "Jay Ashworth" wrote: >---- Original Message ----- >> From: "Owen DeLong" > >[ quoting me ] >> > Ironically, I suspect that it's for the same reason that East Germany >>has >> > right up to the minute telephony services these days, while West >>German is >> > still sucking hind tit: >> > >> > The big properties are, over all, likely to skew somewhat older in >> > building construction, and because of that, they're not built/wired >> > for the internal transport; too much rebar in the walls blocking >> > wifi and stuff like that. > >A comment off list pointed out to me that sometimes, it's the reverse: > >The property jumped on-board in the late nineties, putting in a system >worthy of the next decade... > >and has never updated it, cause it's "good enough". > >Cheers, >-- jr 'sorry to hijack your post to quote myself, Owen' a >-- >Jay R. Ashworth Baylink >jra at baylink.com >Designer The Things I Think RFC >2100 >Ashworth & Associates http://baylink.pitas.com 2000 Land >Rover DII >St Petersburg FL USA #natog +1 727 647 >1274 > From jared at puck.nether.net Wed Feb 27 14:26:42 2013 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 27 Feb 2013 09:26:42 -0500 Subject: 10 Mbit/s problem in your network In-Reply-To: <3462.1361932217@turing-police.cc.vt.edu> References: <512D652E.9000508@mompl.net> <3462.1361932217@turing-police.cc.vt.edu> Message-ID: The reason is Hilton outsources it to AT&T. They don't build the networks for performance in my experience. I have started to avoid some hotels that moved from level3 to AT&T for their Internet providers as they are very slow at peak times. Sad as we all know the main cost for 1g to a site is in the optics (well actually the fiber build... But after that, it costs almost nothing to light it at 1g). A pair of 20km optics is about $250. Not sure why they deliver such poor service on their wifi products. When talking to their support they always cite extraordinary usage. Jared Mauch On Feb 26, 2013, at 9:30 PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 26 Feb 2013 17:45:18 -0800, Jeroen van Aart said: > >> Correct, one should not have expectations of fast reliable internet with >> low latency in a hotel. > > The part that always puzzled me is why a major high-tier chain like Hilton > can't get it right, but a Motel 6 can... :) From jra at baylink.com Wed Feb 27 15:39:26 2013 From: jra at baylink.com (Jay Ashworth) Date: Wed, 27 Feb 2013 10:39:26 -0500 (EST) Subject: 10 Mbit/s problem in your network In-Reply-To: Message-ID: <16113033.7676.1361979566591.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Jared Mauch" > Sad as we all know the main cost for 1g to a site is in the optics > (well actually the fiber build... But after that, it costs almost > nothing to light it at 1g). A pair of 20km optics is about $250. I see that assertion a lot, and I want to correct it. The major cost, MRC, is *the router port*; I don't know what the 95%ile BW for a major hotel is going to be over a month, but I suspect that you're gonna need the whole 1Gb/s worth of port to handle the peaks. And those aren't exactly cheap -- though, by "daily commercial hotel revenue" standards, I suppose they're not *that* expensive; what kind of margins do hotels make? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274 From jjanusze at wd-tek.com Wed Feb 27 16:29:51 2013 From: jjanusze at wd-tek.com (jjanusze at wd-tek.com) Date: Wed, 27 Feb 2013 11:29:51 -0500 (EST) Subject: Fwd: Re: NYT covers China cyberthreat Message-ID: <1931359453.427291.1361982591869.open-xchange@email.1and1.com> Defense in Depth has been paid lipservice for too long, and now we are witnessing the outcome. > ---------- Original Message ---------- > From: Adele Thompson > To: Kyle Creyts > Cc: Derek Noggle , nanog at nanog.org > Date: February 27, 2013 at 1:24 AM > Subject: Re: NYT covers China cyberthreat > > On Tue, Feb 26, 2013 at 8:39 AM, Kyle Creyts wrote: > > > I think it is safe to say that finding a foothold inside of the United > > States from which to perform/proxy an attack is not the hardest thing > > in the world. I don't understand why everyone expects that major > > corporations and diligent operators blocking certain countries' > > prefixes will help. That being said, you make a solid point to which > > people should absolutely listen: applying an understanding of your > > business-needs-network-traffic baseline to your firewall rules and > > heuristic network detections (in a more precise fashion than just "IPs > > from country $x") is a SOLID tactic that yields huge security > > benefits. Nobody who cares about security should really be able to > > argue with it (plenty of those who care don't will hate it, though), > > and makes life _awful_ for any attackers. > > > > On Tue, Feb 26, 2013 at 3:43 AM, Rich Kulawiec wrote: > > > On Thu, Feb 21, 2013 at 11:47:44AM -0600, Naslund, Steve wrote: > > > > > > [a number of very good points ] > > > > > > Geoblocking, like passive OS fingerprinting (another technique that > > > reduces attack surface as measured along one axis but can be defeated > > > by a reasonably clueful attacker), doesn't really solve problems, per se. > > > If you have a web app that's vulnerable to SQL injection attacks, then > > > it's still just as hackable -- all the attacker has to do is try from > > > somewhere else, from something else. > > > > > > But... > > > > > > 1. It raises the bar. And it cuts down on the noise, which is one of the > > > security meta-problems we face: our logs capture so much cruft, so many > > > instances of attacks and abuse and mistakes and misconfigurations and > > > malfunctions, that we struggle to understand what they're trying to tell > > > us. That problem is so bad that there's an entire subindustry built > > > around the task of trying to reduce what's in the logs to something > > > that a human brain can process in finite time. Mountains of time > > > and wads of cash have been spent on the thorny problems that arise > > > when we try to figure out what to pay attention to and what to ignore... > > > and we still screw it up. Often. > > > > > > So even if the *only* effect of doing so is to shrink the size of > > > the logs: that's a win. (And used judiciously, it can be a HUGE win, > > > as in "several orders of magnitude".) So if your security guy is > > > as busy as you say...maybe this would be a good idea. > > > > > > And let me note in passing that by raising the bar, it ensures that > > > you're faced with a somewhat higher class of attacker. It's one > > > thing to be hacked by a competent, diligent adversary who wields > > > their tools with rapier-like precision; it's another to be owned > > > by a script kiddie who has no idea what they're doing and doesn't > > > even read the language your assets are using. That's just embarassing. > > > > > > 2. Outbound blocks work too, y'know. Does anybody in your marketing > > > department need to reach Elbonia? If not, then why are you allowing > > > packets from that group's desktops to go there? Because either > > > (a) it's someone doing something they shouldn't or (b) it's something > > doing > > > something it shouldn't, as in a bot trying to phone home or a data > > > exfiltration attack or something else unpleasant. So if there's > > > no business need for that group to exchange packets with Elbonia > > > or any of 82 other countries, why *aren't* you blocking that? > > > > > > 3. Yes, this can turn into a moderate-sized matrix of inbound and > > > outbound rules. That's why make(1) and similar tools are your friends, > > > because they'll let you manage this without needing to resort to scotch > > > by 9:30 AM. And yes, sometimes things will break (because something's > > > changed) -- but the brokeness is the best kind of brokeness: obvious, > > > deterministic, repeatable, fixable. > > > > > > It's not hard. But it does require that you actually know what your > > > own systems are doing and why. > > > > > > 4. "We were hacked from China" is wearing awfully damn thin as the > > > feeble whining excuse of people who should have bidirectionally > > firewalled > > > out China from their corporate infrastructure (note: not necessarily > > > their public-facing servers) years ago. And "our data was exfiltrated > > > to Elbonia" is getting thin as an excuse too: if you do not have an > > > organizational need to allow outbound network traffic to Elbonia, then > > > why the hell are you letting so much as a single packet go there? > > > > > > Like I said: at least make them work for it. A little. Instead of > > > doing profoundly idiotic things like the NYTimes (e.g., "infrastructure > > > reachable from the planet", "using M$ software", "actually believing that > > > anti-virus software will work despite a quarter-century of uninterrupted > > > failure", etc.). That's not making them work for it: that's inviting > > > them in, rolling out the red carpet, and handing them celebratory > > champagne. > > > > > > ---rsk > > > > > > > > > > > -- > > Kyle Creyts > > > > Information Assurance Professional > > BSidesDetroit Organizer > > > > > > I've been doing some thinking about the internet tonight and came across > this e-mail by which I am intrigued. Currently we suffer from DDoS downtime > on Rackspace (granted it's a very small amount of time, its a hit to our > only single point of failure for which I am currently trying to solve by > obtaining a /24 and an anycast address as a means of mitigation and > providing a highly available HTTP cluster of load balancers. I can't help > but wonder if the cost (both in ipv4 resources and cash) outweighs the > worth of an environment that is sanctioned from the globe. While cloud > hosting has proven to be a scalable solution for our needs, we currently > are only serving US-based organizations as far as I know. Even so, the > desire to grow beyond that isn't far fetched when adding networks that are > still segregated from access outside of a country becomes more available > (kinda like vlans.) > > > > > Germany, Russia, and Spain. > > > > "IN vain is the net spread in the sight of anybird," especially if the > > bird be as keen-eyed asPrince Bismarck. The Carlist attempts to > > irritateGermany > > into intervention ?whether by > > > > firing on her gunboats, or, as report says,attempting to take prisoners > > the German andAustrian representatives to Madrid in the courseof their > > railway journey, or by any other means?have been, and will be, failures. > > Prince Bismarck knows as well as anybody that nothingwould give so > > effectual a spur to the Carlistcause as a German intervention against it, > > andwe may therefore well believe his organ when ittells us that nothing > > so wild as the project oflanding German troops in Spain was ever > > contemplated > > by him. Prince Bismarck was wiseenough, even during the war with France, > > whenthe German power was already in possession,and was on the spot, to > > avoid anythinglike taking a part between the differentpolitical factions > > into which France was divided.Is it reasonable to suppose that, after > > keeping socarefully out of the net with which his feet werealmost in > > contact in France, he would allow himself to be entangled in it in Spain > > ? The realdanger on the Franco-Spanish frontier is not ofa German > > intervention in Spain, but of jealousiesgrowing up between Germany and > > France sokeen as to render a renewal of the war all butinevitable. No > > doubt that would suit PrinceBismarck's book much better than a barren > > intervention in Spain. No doubt his agents are notparticularly delicate > > in their modes of insistingthat France shall cut off all supplies from > > theCarlist > > forces, and in indirectly reminding Frenchmen of the difference beween > > their position now,when they are kept to their internationalduties > > towards Spain by the watchful eye ofGermany, and their position four > > yearsago, > > when they made the mere suggestion of aGerman candidate for the throne of > > Spain aground of affront, and ultimately a cause of war.We do not suppose > > that Prince Bismarck wishesfor another big war, and all the new odium > > itwould > > bring on the victor, but if it must come,no doubt he would like it to > > come soon. It wasa good notion of his to pose as the protector ofthe > > regency of Marshal Serrano in Spain, and sowin an ally south of the > > Pyrenees, as well assouth of the Alps. But in spite of his no doubtsincere > > wish to see Ultramontanism defeated inthe defeat of Don Carlos, it is > > pretty certainthat his Spanish policy is studied much morewith a view to > > crippling France, than with aview to crippling Rome.There is indeed > > something encouraging in theclear evidence afforded, both by Prince > > Bismarck's > > and by Prince GortschakofTs policyin regard to Spain?though these > > policies aredifferent -that even the least teachable of thegreat European > > Powers have learned the lessonthat interventions for the purpose of > > settling theinternal disputes of any great nation are thesilliest of > > mistakes. Germany has recognised,and has probably persuaded various other > > greatPowers to recognise, the Government of Madrid,while Russia declines > > to recognise it; but evenRussia carefully explains that her reason for > > holding back is not any wish to strengthen the hopes ofthe Carlist > > insurrection, but rather on even greaterdelicacy than that shown by the > > other Powersfor the free choice of the Spanish nation, and areluctance > > therefore to enter into formal relations with a Government which, since > > GeneralPavin's coup Witat, has had no sanctionfrom the will of the > > people. Nodoubt one may fairly smile at the reasongiven, when it comes > > from the Ministerof Russia. No doubt it is quite natural to suspect that > > other motives mingle with the refusal?the dislike to follow implicitly > > German lead?the uueasiuess lest the example of Spain shouldbe eventually > > pleaded for Republican institutions;but even though it be so, the fact > > remains thatRussia offers an almost pedantically constitutional reason > > for refusing to acknowledge as yetthe Government of Marshal Serrano, and > > wishesto be understood as setting an example of evengreater delicacy and > > greater deference to thewishes of the Spanish nation than either > > GreatBritain > > or France. No doubt Russia Las pushedthe doctrine to an extreme, if she > > has allowedher deference to the wishes of the Spanishpeople to prevent > > her from recognising a Government the continuance of which she would thinka > > great safeguard to the peace of Europe. Inpoint of fact, Russia, in all > > probability, holds nosuch opinion. The Greek Church is too wellestablished > > and too popular in Russia to makeit a matter of any account to her > > whether thenew Government of Spain be Ultramontane orotherwise, while it > > can never be a matter ofabsolute indifference to the Czar of Russiawhether > > another European people throws offthe monarchy or not. If Don Carlos were > > tosucceed, at least the Republican current ofevents would be reversed for > > a time. Butwhether the success of Marshal Serrano willmean a Republican > > or a Throne for Spain is amatter extremely doubtful. On the otherhand, to > > neither Germany, nor England, norItaly can it fail to be a matter of some > > interestwhether or not a new stimulus or a new checkis to be applied to > > Ultramontane zeaL And asregards France, the Government of MarshalMacMahon > > has a very difficult problem to solve.Doubtless the Extreme Right, and > > with theExtreme Right the whole Sacerdotal party,would prefer to see Don > > Carlos succeed, sincesuch a success would be a new ground of hopefor > > Henri V. and the white flag. But thenMarshal MacMahon has been obliged to > > quarrelwith the Extreme Right, who make light of hisSepteunate, and > > affect to treat him as a merelocum tenena for the coming king. Hence it > > isessential > > for him to secure a certain amount ofmoderate Liberal support, and the > > regency ofMarshal Serrano is so very homogeneous a kindof power to his > > own?namely, a mere excuse fordelay?that he can hardly fail to feel a > > certainsympathy with its position. Add to this theextreme desirability of > > conceding to Germanyall that can be conceded while the fears of quarreland > > the occasions of quarrel are still so numerous,and we do not doubt that a > > very wise decision hasbeen taken, even in the interest of the Government > > itself, in recognising the de facto Government of Madrid. On the whole, > > we regard itas a very satisfactory evidence of the progressmade in > > mastering elementary Constitutionalideas, eveu by the most despotic > > Powers, thatall the great Powers alike repudiate intervention > > Fix this > > text > > in Spain, and use even their fair privilege ofgiving a sort of moral > > support to that one ofthe rival Governments which they think be3tcalculated > > to maintain the peace of Europe, withgreat reserve and moderation. The > > day of HolyAlliances to mould the internal institutions ofrefractory > > countries is now, at last, probablypast, aud with these, the day of some > > of themoot mischievous European combinations whichthe world has ever > > seen.? Spectator. > > > > It is learned that the arrest of Count YonAmiin was effected without the > > knowledge of theEmperor. The musing documents hare beengiven to the > > Ultraniontanes by Deputy Windernorst. > > From joelja at bogus.com Wed Feb 27 16:50:28 2013 From: joelja at bogus.com (joel jaeggli) Date: Wed, 27 Feb 2013 08:50:28 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: References: <512D652E.9000508@mompl.net> <3462.1361932217@turing-police.cc.vt.edu> Message-ID: <512E3954.3070400@bogus.com> On 2/27/13 6:26 AM, Jared Mauch wrote: > The reason is Hilton outsources it to AT&T. They don't build the networks for performance in my experience. I have started to avoid some hotels that moved from level3 to AT&T for their Internet providers as they are very slow at peak times. > > Sad as we all know the main cost for 1g to a site is in the optics (well actually the fiber build... But after that, it costs almost nothing to light it at 1g). A pair of 20km optics is about $250. These manangement companies have been minimizing their cap/opex from fall 2007 through the end of 2011. They're still not spending on stuff unless it reduces their cost. > Not sure why they deliver such poor service on their wifi products. When talking to their support they always cite extraordinary usage. > > Jared Mauch > > On Feb 26, 2013, at 9:30 PM, Valdis.Kletnieks at vt.edu wrote: > >> On Tue, 26 Feb 2013 17:45:18 -0800, Jeroen van Aart said: >> >>> Correct, one should not have expectations of fast reliable internet with >>> low latency in a hotel. >> The part that always puzzled me is why a major high-tier chain like Hilton >> can't get it right, but a Motel 6 can... :) > From hschiller at google.com Wed Feb 27 18:42:48 2013 From: hschiller at google.com (Heather Schiller) Date: Wed, 27 Feb 2013 13:42:48 -0500 Subject: BGP RIB Collection In-Reply-To: References: Message-ID: info on bmpreceiver below.. On Tue, Feb 26, 2013 at 12:24 PM, chip wrote: > Hello all, > > I have an application that needs to gather BGP RIB data from the routers > that connect to all of our upstream providers. Basically I need to know > all the routes available from a particular provider. Currently I'm > gathering this data via SNMP. While this works it has its draw backs, it > takes approximately 20 minutes per view, its nowhere near real-time, and > I'm unable to gather information for IPv6. SNMP, however, is faster than > screen scraping. All of the XML based access methods seem to take about > the same time as well. > > I've been watching, with keen interest, the i2rs ietf workings, but the > project is still in its infancy. BMP seems to be a good solution but I've > not found a working client implementation yet. I see that you can actually > configure this on some Juniper gear but I can't seem to locate a client to > ingest the data the router produces. https://code.google.com/p/bmpreceiver/ and then it can be dumped where ever you want.. iirc, splunk can parse the data. --Heather > The BGP Add Paths implementation > seems to be the best choice at the moment and exabgp has a working > implementation. > > Are there any other technologies or methods of accessing this data that > I've missed or that you've found useful? > > Thanks! > > --chip > > -- > Just my $.02, your mileage may vary, batteries not included, etc.... > From owen at delong.com Wed Feb 27 19:47:16 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 27 Feb 2013 11:47:16 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: <16113033.7676.1361979566591.JavaMail.root@benjamin.baylink.com> References: <16113033.7676.1361979566591.JavaMail.root@benjamin.baylink.com> Message-ID: <1F237198-68F2-49C1-893D-4E39C939E499@delong.com> On Feb 27, 2013, at 7:39 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Jared Mauch" > >> Sad as we all know the main cost for 1g to a site is in the optics >> (well actually the fiber build... But after that, it costs almost >> nothing to light it at 1g). A pair of 20km optics is about $250. > > I see that assertion a lot, and I want to correct it. > > The major cost, MRC, is *the router port*; I don't know what the 95%ile > BW for a major hotel is going to be over a month, but I suspect that > you're gonna need the whole 1Gb/s worth of port to handle the peaks. > > And those aren't exactly cheap -- though, by "daily commercial hotel > revenue" standards, I suppose they're not *that* expensive; what kind > of margins do hotels make? > Actually, local loop usually exceeds router port. If you're at one of the data centers where we have presence, I can sell you a dual-stack Gig for <$1/Mbps. OTOH, getting a Gig-E to the datacenter from the hotel and then the additional cost of the XC are probably more than $1,000/month when combined. Possibly by some multiplier ?2. Owen From luan20176 at gmail.com Wed Feb 27 20:42:24 2013 From: luan20176 at gmail.com (Luan Nguyen) Date: Wed, 27 Feb 2013 15:42:24 -0500 Subject: Good transit provider @Hutchison Cavendish Centre Message-ID: Hi Folks, Any recommendation for a 1 Gig Transit provider at Hutchison Cavendish Centre? Has to be able to black hole DDOS attack using BGP communities. Preferable: Tier 1 provider with US present (IAD would be best) HK NSP mailing list doesn't exist anymore? Thanks. Regards, -lmn From mureninc at gmail.com Wed Feb 27 22:55:33 2013 From: mureninc at gmail.com (Constantine A. Murenin) Date: Wed, 27 Feb 2013 14:55:33 -0800 Subject: 10 Mbit/s problem in your network In-Reply-To: <1F237198-68F2-49C1-893D-4E39C939E499@delong.com> References: <16113033.7676.1361979566591.JavaMail.root@benjamin.baylink.com> <1F237198-68F2-49C1-893D-4E39C939E499@delong.com> Message-ID: On 27 February 2013 11:47, Owen DeLong wrote: > > On Feb 27, 2013, at 7:39 AM, Jay Ashworth wrote: > >> ----- Original Message ----- >>> From: "Jared Mauch" >> >>> Sad as we all know the main cost for 1g to a site is in the optics >>> (well actually the fiber build... But after that, it costs almost >>> nothing to light it at 1g). A pair of 20km optics is about $250. >> >> I see that assertion a lot, and I want to correct it. >> >> The major cost, MRC, is *the router port*; I don't know what the 95%ile >> BW for a major hotel is going to be over a month, but I suspect that >> you're gonna need the whole 1Gb/s worth of port to handle the peaks. >> >> And those aren't exactly cheap -- though, by "daily commercial hotel >> revenue" standards, I suppose they're not *that* expensive; what kind >> of margins do hotels make? >> > > Actually, local loop usually exceeds router port. > > If you're at one of the data centers where we have presence, I can sell you a dual-stack Gig for <$1/Mbps. > > OTOH, getting a Gig-E to the datacenter from the hotel and then the additional cost of the XC are probably more than $1,000/month when combined. Possibly by some multiplier ?2. > > Owen I'm not sure how you've arrived at such an assertion. I thought 20$/mo (or even below) was more like the cost of an FTTU pipe; lighting at dedicated GigE would probably bring it higher, but (prior to XC) the cost should still be comparable. Also, how about microwave links? Webpass.net seems to have some nice offerings for residential buildings in SF Bay; it would seem like their technology might be perfect for the hotel sector, too. Also, even at $2,000/month -- wouldn't this still be several times cheaper than what they pay for newspaper delivery to every room? Oh, I get it, business people require their morning newspaper, but inet, ehh -- only the kids need the internet! C. From tom at cloudflare.com Thu Feb 28 06:52:15 2013 From: tom at cloudflare.com (Tom Paseka) Date: Thu, 28 Feb 2013 14:52:15 +0800 Subject: Good transit provider @Hutchison Cavendish Centre In-Reply-To: References: Message-ID: You won't be able to get many choices there. Given its a Hutchison building, thought about Hutchison? You'll need a local loop otherwise, coverage is probably not easy too and being a hutch building, you wont get much choice. Other recommendations (if you forget about local loop issues), Pacnet, Telstra/Reach, PCCW, TATA, NTT, etc. Every provider should be able to meet your DDOS requirements. On Thu, Feb 28, 2013 at 4:42 AM, Luan Nguyen wrote: > Hi Folks, > > Any recommendation for a 1 Gig Transit provider at Hutchison Cavendish > Centre? Has to be able to black hole DDOS attack using BGP communities. > Preferable: Tier 1 provider with US present (IAD would be best) > HK NSP mailing list doesn't exist anymore? > > Thanks. > > Regards, > > -lmn >