From Jacques.Latour at cira.ca Wed Nov 1 07:16:29 2017 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Wed, 1 Nov 2017 07:16:29 +0000 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> References: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> Message-ID: JF, c¹est bon ça! This is good point JF, according to http://www.acwr.com/economic-development/rail-maps/canadian-national we seem to have a single rail on top of Lac Superior. Other than that, it¹s diverse. Is there diverse train routes and associated fibre routes? Which provider follow CP and CN?? Jacques On 2017-10-11, 3:04 PM, "NANOG on behalf of Jean-Francois Mezei" wrote: >On 2017-10-11 11:40, Jacques Latour wrote: >> Does anyone know if there's fibre resiliency between Calgary and >>Toronto over the Great lakes, I thinking redundancy could be achieved by >>using two paths one following the railroad and the other following the >>Trans-Canadian highway. Does anyone know if there is fibre following >>the Trans-Canadian highway and who owns it? > > >More than likely one around lake Superior on CP Rail tracks, and the >other along the CN tracks further north. > >Zayo in Canada is formerly CNCP telecommunications, and they are likely >first to have fibre along tracks. > >Since the Trans Canada highway in that part of Ontario is actually a 2 >lane rural road, I am not sure people would have laid fibre along it >knowing the progressive work to widen it might require frequent >relocation of the fibre. From jzamani at metasource.com Wed Nov 1 14:55:58 2017 From: jzamani at metasource.com (Jon Zamani) Date: Wed, 1 Nov 2017 14:55:58 +0000 Subject: Major ISP Issues Message-ID: <398fa25fd73e437ea47ebdad4703ee52@DRPR-EXCH-MBX1.ad.metasource.com> Who else reporting the same? CenturyLink Comcast/XFinity Seems nationwide R/S, [cid:image001.jpg at 01D352EF.3C15CF40] Jon Zamani | Sr. Network and Security Engineer MetaSource, LLC | 67 W 13490 S Suite 300 | Draper, UT 84020-8334 office 801.984.6606 | mobile 801.209.5578 | jzamani at metasource.com RFC 1925 - The 12 Truths ________________________________ NOTICE: This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended only for the use of the Individual (s) named above. MetaSource makes no expressed or implied warranty of any kind respecting the information presented and assumes no responsibility for errors and omissions. If you are not the intended recipient of this e-mail, or the employee or agent responsible for delivering this to the intended recipient, you are hereby notified that any dissemination or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately notify us by telephone at 215-788-8885 or notify us by e-mail at legal at metasource.com. Also, please mail a hardcopy of the e-mail to MetaSource at 1900 Frost Road, Suite 100, Bristol, PA 19007 via the U.S. Postal Service. We will reimburse you for all expenses incurred. From bicknell at ufp.org Wed Nov 1 17:58:26 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 1 Nov 2017 10:58:26 -0700 Subject: What's the point of prepend communities? In-Reply-To: <16e20cc1-ae53-42a8-a355-7245930a9b09@xalto.net> References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> <20171026191943.GA20822@ussenterprise.ufp.org> <1509047657.3640410.1152209288.32152D70@webmail.messagingengine.com> <20171030172411.GA21203@ussenterprise.ufp.org> <16e20cc1-ae53-42a8-a355-7245930a9b09@xalto.net> Message-ID: <20171101175826.GA58877@ussenterprise.ufp.org> In a message written on Mon, Oct 30, 2017 at 07:56:43PM +0100, Michael Hallgren wrote: > But keep in mind that 'prepend communities' are fragile: I decide by local preference whereto I send my traffic. Absolutely, but they are still very useful in many situations. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From valdis.kletnieks at vt.edu Wed Nov 1 18:34:20 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 01 Nov 2017 14:34:20 -0400 Subject: Major ISP Issues In-Reply-To: <398fa25fd73e437ea47ebdad4703ee52@DRPR-EXCH-MBX1.ad.metasource.com> References: <398fa25fd73e437ea47ebdad4703ee52@DRPR-EXCH-MBX1.ad.metasource.com> Message-ID: <22215.1509561260@turing-police.cc.vt.edu> On Wed, 01 Nov 2017 14:55:58 -0000, Jon Zamani said: > Who else reporting the same? > > CenturyLink > Comcast/XFinity > > Seems nationwide Path from my office to my home in Comcast territory (which loops all the way through 250 miles to Ashburn and back to get 2.5 miles) hasn't even blipped. So it's not everything. http://downdetector.com/status/comcast-xfinity/map/ shows some warm spots. And http://downdetector.com/status/centurylink/map/ throws an HTTP 500 error. That can't be good. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From rwebb at ropeguru.com Wed Nov 1 18:45:33 2017 From: rwebb at ropeguru.com (Robert Webb) Date: Wed, 1 Nov 2017 18:45:33 +0000 Subject: Major ISP Issues In-Reply-To: <398fa25fd73e437ea47ebdad4703ee52@DRPR-EXCH-MBX1.ad.metasource.com> References: <398fa25fd73e437ea47ebdad4703ee52@DRPR-EXCH-MBX1.ad.metasource.com> Message-ID: All looks good here in Central VA. Been on work VPN all morning and my cloud backup is running just fine. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jon Zamani Sent: Wednesday, November 1, 2017 10:56 AM To: nanog at nanog.org Subject: Major ISP Issues Who else reporting the same? CenturyLink Comcast/XFinity Seems nationwide R/S, [cid:image001.jpg at 01D352EF.3C15CF40] Jon Zamani | Sr. Network and Security Engineer MetaSource, LLC | 67 W 13490 S Suite 300 | Draper, UT 84020-8334 office 801.984.6606 | mobile 801.209.5578 | jzamani at metasource.com RFC 1925 - The 12 Truths ________________________________ NOTICE: This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended only for the use of the Individual (s) named above. MetaSource makes no expressed or implied warranty of any kind respecting the information presented and assumes no responsibility for errors and omissions. If you are not the intended recipient of this e-mail, or the employee or agent responsible for delivering this to the intended recipient, you are hereby notified that any dissemination or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please immediately notify us by telephone at 215-788-8885 or notify us by e-mail at legal at metasource.com. Also, please mail a hardcopy of the e-mail to MetaSource at 1900 Frost Road, Suite 100, Bristol, PA 19007 via the U.S. Postal Service. We will reimburse you for all expenses incurred. From mh at xalto.net Wed Nov 1 19:17:11 2017 From: mh at xalto.net (Michael Hallgren) Date: Wed, 01 Nov 2017 20:17:11 +0100 Subject: What's the point of prepend communities? In-Reply-To: <20171101175826.GA58877@ussenterprise.ufp.org> References: <6CC2F078-9D03-4B10-ACC4-DA93C8FA438A@lixfeld.ca> <4DD92793-4DFD-4AE8-A30E-66BE3A3FD5E3@lixfeld.ca> <20171026191943.GA20822@ussenterprise.ufp.org> <1509047657.3640410.1152209288.32152D70@webmail.messagingengine.com> <20171030172411.GA21203@ussenterprise.ufp.org> <16e20cc1-ae53-42a8-a355-7245930a9b09@xalto.net> <20171101175826.GA58877@ussenterprise.ufp.org> Message-ID: Yes, sometimes very much so, and often nice to combine with local-pref settings based on upstream's "geo-community-values" when available. Cheers, mh Le 1 nov. 2017 à 18:59, à 18:59, Leo Bicknell a écrit: >In a message written on Mon, Oct 30, 2017 at 07:56:43PM +0100, Michael >Hallgren wrote: >> But keep in mind that 'prepend communities' are fragile: I decide by >local preference whereto I send my traffic. > >Absolutely, but they are still very useful in many situations. > >-- >Leo Bicknell - bicknell at ufp.org >PGP keys at http://www.ufp.org/~bicknell/ From jfmezei_nanog at vaxination.ca Wed Nov 1 21:23:16 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 1 Nov 2017 17:23:16 -0400 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: References: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> Message-ID: <46506f37-0559-99ac-5948-9ea8ad987910@vaxination.ca> On 2017-11-01 03:16, Jacques Latour wrote: > JF, c¹est bon ça! > > This is good point JF, according to > http://www.acwr.com/economic-development/rail-maps/canadian-national we > seem to have a single rail on top of Lac Superior. Both CN and CP (still) have their own tracks. CP along shore of Lake Superior, CN further north. a more accurate map of CN where they have track rights or own tracks: http://cnebusiness.geomapguide.ca/?MAP=WL The black lines indicate other railways (such as CP and short lines) As CP went on a "anthing but be a railway" policy between early 1980s and a shoreholder revolt a couple years ago, not sure how many telecoms would have wanted their fibre along CP tracks that CP might tear up. (CP had requested permission to shut Thunder Bay to Sudbury in the 1980s - it was refused). It isn't clear to me what happens to fibre when a railway abandons and removes tracks. For instance, Rigaud to Ottawa on CP. Ottawa to Sudbury was sold to short line, and Ottawa-Mattawa tracks removed in 2012. CN had long ago removed its Ottawa-Sudbury tracks. So, from Ottawa to Winnipeg, unless a carrier follows rural road 17 (the trans canada in Ontario) from Ottawa to Sudbury, you are essentially stuck with the one track out of Ottawa to Smith Falls. There, the CP to Belleville, or continue to Brockville and CN to Belleville. Belleville to Toronto, the CP and CN tracks basically follow each other, sometimes distant enough to have separate crossings, often share same rail crossing barriers. And from Pickering to downtown, it's basically the Metrolinx tracks (Go Train) or go around on freight lines and then down to downtown (and follow same route up towards Sudbury). >From a "diversity" point of view, I guess you have to look at frequency of backhoe events on railway right of way. Since railways also have their own signaling fibre in the conduits, I suspect they have very few "oops, forgot there were conduits below tracks" events. Also, whether train derailments often affect fibre under tracks. CN had a few derailments along its Sudbury-Winnipeg line last year and there were no news of major telecom disruptions. Is it because of carriers having diversity in routes or because the fibre under tracks is rarely affected by derailments? So would having carrier-A and carrier-B burried same tracks be considered dangerous ? (along a road, I suspect the backhoe risks are higher since individual home owners have driveways to road and could use a backhoe without calling anyone). But along tracks, farmers would not use backhoes or other equipment over track ballast. Also: there is a big difference between a highway like the 401/417 and a road line the 17. For major highways, any upgrades/construction will involve the govt informing the carriers who would have burried cables along highway. But along rural roads like the 17, municipalities often are in charge of a strech of highway, and individual homeowners or businesses have their driveway to the road and may not call to locate cables before having fun with their backhoe. From surfer at mauigateway.com Wed Nov 1 21:31:40 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 1 Nov 2017 14:31:40 -0700 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover Message-ID: <20171101143140.3103C814@m0117568.ppops.net> --- jfmezei_nanog at vaxination.ca wrote: From: Jean-Francois Mezei It isn't clear to me what happens to fibre when a railway abandons and removes tracks. ---------------------------------------- That's an interesting question. Anyone have experience with that? scott From clayton at MNSi.Net Wed Nov 1 21:51:02 2017 From: clayton at MNSi.Net (Clayton Zekelman) Date: Wed, 01 Nov 2017 17:51:02 -0400 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: <46506f37-0559-99ac-5948-9ea8ad987910@vaxination.ca> References: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> <46506f37-0559-99ac-5948-9ea8ad987910@vaxination.ca> Message-ID: <1509573065_26460@surgemail.mnsi.net> The fibre optic cables are buried within the RoW, not on private property. It is against the law to dig without having utilities located first. At 05:23 PM 01/11/2017, Jean-Francois Mezei wrote: >But along rural roads like the 17, municipalities often are in charge of >a strech of highway, and individual homeowners or businesses have their >driveway to the road and may not call to locate cables before having fun >with their backhoe. -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From nanog at ics-il.net Thu Nov 2 01:19:58 2017 From: nanog at ics-il.net (Mike Hammett) Date: Wed, 1 Nov 2017 20:19:58 -0500 (CDT) Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: <1509573065_26460@surgemail.mnsi.net> References: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> <46506f37-0559-99ac-5948-9ea8ad987910@vaxination.ca> <1509573065_26460@surgemail.mnsi.net> Message-ID: <122173526.3244.1509585594848.JavaMail.mhammett@ThunderFuck> If it's against the law, then it should never happen, right? Also, I know a lot of people getting their own easements and not using the RoW. You can't be forced into anything except by eminent domain. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Clayton Zekelman" To: "Jean-Francois Mezei" , "Jacques Latour" , nanog at nanog.org Sent: Wednesday, November 1, 2017 4:51:02 PM Subject: Re: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover The fibre optic cables are buried within the RoW, not on private property. It is against the law to dig without having utilities located first. At 05:23 PM 01/11/2017, Jean-Francois Mezei wrote: >But along rural roads like the 17, municipalities often are in charge of >a strech of highway, and individual homeowners or businesses have their >driveway to the road and may not call to locate cables before having fun >with their backhoe. -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From SNaslund at medline.com Thu Nov 2 13:25:14 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Thu, 2 Nov 2017 13:25:14 +0000 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: <122173526.3244.1509585594848.JavaMail.mhammett@ThunderFuck> References: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> <46506f37-0559-99ac-5948-9ea8ad987910@vaxination.ca> <1509573065_26460@surgemail.mnsi.net> <122173526.3244.1509585594848.JavaMail.mhammett@ThunderFuck> Message-ID: <9578293AE169674F9A048B2BC9A081B4026BDEB8D5@MUNPRDMBXA1.medline.com> There are four facts to be aware of here. 1. Locators are not 100% especially when it comes to fiber. Databases do not always get updated and maps can have errors. They can be difficult to locate if they are not mapped because there is very little detectable metal in them. I have personally been on projects where we hit live power line stubs, gas lines, and comm cables even after reviewing the maps and have locators out. Records sometimes suck. The problem has gotten worse with the explosion in the number of carriers, you only used to have to worry about Bell, power, and gas. Now you have tons of fiber carriers, telecoms, and cable TV all updating (or failing to update) records. 2. Not everything is in public RoW, many fiber carriers have cut their own deals with landowners, railroads, etc. 3. Installers take short cuts. For example, your map and locator might show a very nice 90 degree corner but often if directionally drilled it is going to be a large sweeping turn that may very well leave the RoW. One side effect of directional boring is that no one really notices if they cut out of the RoW since there is no above ground evidence to cause a complaint. Installations going to a house or business outside the RoW may show a nice straight line on the map but if that boring rig hits a rock you better believe they will steer around it. 4. Stuff gets moved without proper coordination. Guys that put in hard lines (pipelines, sewer, water, gas mains) will often move a cable that gets in their way as long as it has enough slack to do so. They know that the coordination takes time that delays their jobs so the reality is if they have to move a cable over four or five feet, they are going to just do it.   Steven Naslund Chicago IL >From: "Clayton Zekelman" >To: "Jean-Francois Mezei" , "Jacques Latour" , nanog at nanog.org >Sent: Wednesday, November 1, 2017 4:51:02 PM >Subject: Re: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover > > > >The fibre optic cables are buried within the RoW, not on private property. > >It is against the law to dig without having utilities located first. >At 05:23 PM 01/11/2017, Jean-Francois Mezei wrote: >>But along rural roads like the 17, municipalities often are in charge >>of a strech of highway, and individual homeowners or businesses have >>their driveway to the road and may not call to locate cables before >>having fun with their backhoe. -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409 From rod.beck at unitedcablecompany.com Thu Nov 2 17:34:10 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Thu, 2 Nov 2017 17:34:10 +0000 Subject: New Cable Systems - Asia Message-ID: Good article providing an overview of recent cable builds. http://www.zdnet.com/article/facebook-amazon-softbank-ntt-sign-on-for-60tbps-jupiter-subsea-cable/ [https://zdnet4.cbsistatic.com/hub/i/r/2017/10/31/32fcd53c-09cb-4f94-9675-531750e769e2/thumbnail/770x578/abba6bef8b8f8691030aa28ae67fbec0/jupiter-subsea-cable.jpg] Facebook, Amazon, SoftBank, NTT sign on for 60Tbps Jupiter subsea cable | ZDNet www.zdnet.com A consortium of tech companies will be building out yet another Asia-Pacific subsea cable, with the 60Tbps Jupiter cable system to connect the US with Japan and the Philippines. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com 85 Király utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From bz_siege_01 at hotmail.com Thu Nov 2 18:01:10 2017 From: bz_siege_01 at hotmail.com (LF OD) Date: Thu, 2 Nov 2017 18:01:10 +0000 Subject: Are there inexpensive DWDM products? Message-ID: We have several buildings and a couple data centers spread around the city and interconnected via dark fiber. It's a very simple setup - no ROADM, no real ring, no extended layer-2 or layer-3 via the optical gear. Pretty much we just mux/demux a channel for each building so that each building sees the two data centers directly even though the fiber span may wind through a couple buildings along the way. In some cases, the distance is short enough to use colored optics in the network gear, but mostly the distances are just long enough to warrant transponder cards. All that being said, a lot of the gear is approaching end of life (support in some cases). I'm not an optical guru but I can muddle my way through with Cisco ONS and I'm aware that Ciena and Fujitsu also have similar products. We really don't have budget for a large optical refresh effort. However, we've saved some money here and there in the routing/switching arena by leveraging Arista and even Cumulus. I'm wondering if there are smaller players in the optical arena that have a good quality/price value? Again, we don't need sophisticated features... we primarily have 2-to-4 1Gb and 10Gb ports required per site, then we mux those onto a wavelength and extend it to the two data centers. Most buildings are set up the same way, each on a different wavelength so the don't even see each other... only the data centers. If you guys know of any optical gear that you can vouch for (and which costs less than a small house), we would greatly appreciate it. Thanks LFOD From cra at WPI.EDU Thu Nov 2 18:06:56 2017 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 2 Nov 2017 14:06:56 -0400 Subject: Are there inexpensive DWDM products? In-Reply-To: References: Message-ID: <20171102180656.GZ29110@angus.ind.wpi.edu> CWDM is cheaper and will probably work fine within a city. Check fs.com. On Thu, Nov 02, 2017 at 06:01:10PM +0000, LF OD wrote: > We have several buildings and a couple data centers spread around the city and interconnected via dark fiber. It's a very simple setup - no ROADM, no real ring, no extended layer-2 or layer-3 via the optical gear. > > > Pretty much we just mux/demux a channel for each building so that each building sees the two data centers directly even though the fiber span may wind through a couple buildings along the way. In some cases, the distance is short enough to use colored optics in the network gear, but mostly the distances are just long enough to warrant transponder cards. > > > All that being said, a lot of the gear is approaching end of life (support in some cases). I'm not an optical guru but I can muddle my way through with Cisco ONS and I'm aware that Ciena and Fujitsu also have similar products. We really don't have budget for a large optical refresh effort. However, we've saved some money here and there in the routing/switching arena by leveraging Arista and even Cumulus. I'm wondering if there are smaller players in the optical arena that have a good quality/price value? > > > Again, we don't need sophisticated features... we primarily have 2-to-4 1Gb and 10Gb ports required per site, then we mux those onto a wavelength and extend it to the two data centers. Most buildings are set up the same way, each on a different wavelength so the don't even see each other... only the data centers. > > > If you guys know of any optical gear that you can vouch for (and which costs less than a small house), we would greatly appreciate it. Thanks > > > LFOD From lguillory at reservetele.com Thu Nov 2 18:22:43 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Thu, 2 Nov 2017 18:22:43 +0000 Subject: Are there inexpensive DWDM products? In-Reply-To: References: Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB35A26C@RTC-EXCH01.RESERVE.LDS> These guys seem to be a white box solution for Optical. https://www.lumentum.com I see that Juniper and Infinera have both worked on solutions to work on their hardware. Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of LF OD Sent: Thursday, November 02, 2017 1:01 PM To: nanog at nanog.org Subject: Are there inexpensive DWDM products? We have several buildings and a couple data centers spread around the city and interconnected via dark fiber. It's a very simple setup - no ROADM, no real ring, no extended layer-2 or layer-3 via the optical gear. Pretty much we just mux/demux a channel for each building so that each building sees the two data centers directly even though the fiber span may wind through a couple buildings along the way. In some cases, the distance is short enough to use colored optics in the network gear, but mostly the distances are just long enough to warrant transponder cards. All that being said, a lot of the gear is approaching end of life (support in some cases). I'm not an optical guru but I can muddle my way through with Cisco ONS and I'm aware that Ciena and Fujitsu also have similar products. We really don't have budget for a large optical refresh effort. However, we've saved some money here and there in the routing/switching arena by leveraging Arista and even Cumulus. I'm wondering if there are smaller players in the optical arena that have a good quality/price value? Again, we don't need sophisticated features... we primarily have 2-to-4 1Gb and 10Gb ports required per site, then we mux those onto a wavelength and extend it to the two data centers. Most buildings are set up the same way, each on a different wavelength so the don't even see each other... only the data centers. If you guys know of any optical gear that you can vouch for (and which costs less than a small house), we would greatly appreciate it. Thanks LFOD From jabley at hopcount.ca Thu Nov 2 18:40:59 2017 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 2 Nov 2017 14:40:59 -0400 Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: <9578293AE169674F9A048B2BC9A081B4026BDEB8D5@MUNPRDMBXA1.medline.com> References: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> <46506f37-0559-99ac-5948-9ea8ad987910@vaxination.ca> <1509573065_26460@surgemail.mnsi.net> <122173526.3244.1509585594848.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B4026BDEB8D5@MUNPRDMBXA1.medline.com> Message-ID: On 2 Nov 2017, at 09:25, Naslund, Steve wrote: > There are four facts to be aware of here. > > 1. Locators are not 100% especially when it comes to fiber. I remember years ago in New Zealand there was buried fibre along the railway running north-south in the North Island that was not generally anybody's first choice of glass when trying to connect sites in Auckland and Wellington. The problem I heard described (from memory, long time ago, I am old) was that the natural vibration of the ground due to trains on rails had the effect over time of pushing conduit down the embankment away from the track, leading to fibre breaks with no corresponding obvious cause (no digging). You could bounce signals down the copper in the conduit from either side to try and figure out where the break was, but once on site you still had to find the fibre which was usually not anywhere close to where the map said it was buried. Joe From Romeo.Czumbil at tierpoint.com Thu Nov 2 18:48:27 2017 From: Romeo.Czumbil at tierpoint.com (Romeo Czumbil) Date: Thu, 2 Nov 2017 18:48:27 +0000 Subject: Are there inexpensive DWDM products? In-Reply-To: References: Message-ID: <1dfaeb86031849d58eeead8984edbe62@hwt01-ex01.tierpoint.net> CWDM option might be your best bet here. If you need more channels and you want to go to DWDM then check out Ekinops Great product and they don't charge as much as the other guys -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of LF OD Sent: Thursday, November 2, 2017 2:01 PM To: nanog at nanog.org Subject: Are there inexpensive DWDM products? We have several buildings and a couple data centers spread around the city and interconnected via dark fiber. It's a very simple setup - no ROADM, no real ring, no extended layer-2 or layer-3 via the optical gear. Pretty much we just mux/demux a channel for each building so that each building sees the two data centers directly even though the fiber span may wind through a couple buildings along the way. In some cases, the distance is short enough to use colored optics in the network gear, but mostly the distances are just long enough to warrant transponder cards. All that being said, a lot of the gear is approaching end of life (support in some cases). I'm not an optical guru but I can muddle my way through with Cisco ONS and I'm aware that Ciena and Fujitsu also have similar products. We really don't have budget for a large optical refresh effort. However, we've saved some money here and there in the routing/switching arena by leveraging Arista and even Cumulus. I'm wondering if there are smaller players in the optical arena that have a good quality/price value? Again, we don't need sophisticated features... we primarily have 2-to-4 1Gb and 10Gb ports required per site, then we mux those onto a wavelength and extend it to the two data centers. Most buildings are set up the same way, each on a different wavelength so the don't even see each other... only the data centers. If you guys know of any optical gear that you can vouch for (and which costs less than a small house), we would greatly appreciate it. Thanks LFOD From rjacobs at pslightwave.com Thu Nov 2 19:08:06 2017 From: rjacobs at pslightwave.com (Robert Jacobs) Date: Thu, 2 Nov 2017 19:08:06 +0000 Subject: Are there inexpensive DWDM products? In-Reply-To: <1dfaeb86031849d58eeead8984edbe62@hwt01-ex01.tierpoint.net> References: <1dfaeb86031849d58eeead8984edbe62@hwt01-ex01.tierpoint.net> Message-ID: We use and love Infinera XTG Muxes for our P2P extensions off the main optical core. They have a line of manageable 8 channel DWDM passive mux that you can get basic up down traps and optical information about each channel. You can use grey market or OAM tuned ten gig transponders in your switches or routers and patch into the mux. There is an option to add an amp if distances are too great. About 6K for a pair of the muxes and tuned optics are grey market so your price will vary based on the vender you purchase from. We use Precision for the grey market optics and have been very pleased with the price vs's value and support. Robert Jacobs | Network Architect & Director -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Romeo Czumbil Sent: Thursday, November 2, 2017 1:48 PM To: LF OD ; nanog at nanog.org Subject: RE: Are there inexpensive DWDM products? CWDM option might be your best bet here. If you need more channels and you want to go to DWDM then check out Ekinops Great product and they don't charge as much as the other guys -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of LF OD Sent: Thursday, November 2, 2017 2:01 PM To: nanog at nanog.org Subject: Are there inexpensive DWDM products? We have several buildings and a couple data centers spread around the city and interconnected via dark fiber. It's a very simple setup - no ROADM, no real ring, no extended layer-2 or layer-3 via the optical gear. Pretty much we just mux/demux a channel for each building so that each building sees the two data centers directly even though the fiber span may wind through a couple buildings along the way. In some cases, the distance is short enough to use colored optics in the network gear, but mostly the distances are just long enough to warrant transponder cards. All that being said, a lot of the gear is approaching end of life (support in some cases). I'm not an optical guru but I can muddle my way through with Cisco ONS and I'm aware that Ciena and Fujitsu also have similar products. We really don't have budget for a large optical refresh effort. However, we've saved some money here and there in the routing/switching arena by leveraging Arista and even Cumulus. I'm wondering if there are smaller players in the optical arena that have a good quality/price value? Again, we don't need sophisticated features... we primarily have 2-to-4 1Gb and 10Gb ports required per site, then we mux those onto a wavelength and extend it to the two data centers. Most buildings are set up the same way, each on a different wavelength so the don't even see each other... only the data centers. If you guys know of any optical gear that you can vouch for (and which costs less than a small house), we would greatly appreciate it. Thanks LFOD From bz_siege_01 at hotmail.com Thu Nov 2 19:59:03 2017 From: bz_siege_01 at hotmail.com (LF OD) Date: Thu, 2 Nov 2017 19:59:03 +0000 Subject: Are there inexpensive DWDM products? In-Reply-To: References: Message-ID: Wow... a lot of suggestions and very quickly too. CWDM may not be an option because some of the spans are just out of range, but I'm going to look at it for the short spans. Thanks for all the feedback, folks. (I'll contact some of you off-board) LFOD ________________________________ From: NANOG on behalf of LF OD Sent: Thursday, November 2, 2017 11:01 AM To: nanog at nanog.org Subject: Are there inexpensive DWDM products? We have several buildings and a couple data centers spread around the city and interconnected via dark fiber. It's a very simple setup - no ROADM, no real ring, no extended layer-2 or layer-3 via the optical gear. Pretty much we just mux/demux a channel for each building so that each building sees the two data centers directly even though the fiber span may wind through a couple buildings along the way. In some cases, the distance is short enough to use colored optics in the network gear, but mostly the distances are just long enough to warrant transponder cards. All that being said, a lot of the gear is approaching end of life (support in some cases). I'm not an optical guru but I can muddle my way through with Cisco ONS and I'm aware that Ciena and Fujitsu also have similar products. We really don't have budget for a large optical refresh effort. However, we've saved some money here and there in the routing/switching arena by leveraging Arista and even Cumulus. I'm wondering if there are smaller players in the optical arena that have a good quality/price value? Again, we don't need sophisticated features... we primarily have 2-to-4 1Gb and 10Gb ports required per site, then we mux those onto a wavelength and extend it to the two data centers. Most buildings are set up the same way, each on a different wavelength so the don't even see each other... only the data centers. If you guys know of any optical gear that you can vouch for (and which costs less than a small house), we would greatly appreciate it. Thanks LFOD From nanog at ics-il.net Thu Nov 2 20:37:49 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 2 Nov 2017 15:37:49 -0500 (CDT) Subject: Are there inexpensive DWDM products? In-Reply-To: References: Message-ID: <1844978323.4052.1509655060685.JavaMail.mhammett@ThunderFuck> fs.com DWDM with a 1310 pass through port. That way you can still run 40G or 100G over the 1310. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "LF OD" To: nanog at nanog.org Sent: Thursday, November 2, 2017 1:01:10 PM Subject: Are there inexpensive DWDM products? We have several buildings and a couple data centers spread around the city and interconnected via dark fiber. It's a very simple setup - no ROADM, no real ring, no extended layer-2 or layer-3 via the optical gear. Pretty much we just mux/demux a channel for each building so that each building sees the two data centers directly even though the fiber span may wind through a couple buildings along the way. In some cases, the distance is short enough to use colored optics in the network gear, but mostly the distances are just long enough to warrant transponder cards. All that being said, a lot of the gear is approaching end of life (support in some cases). I'm not an optical guru but I can muddle my way through with Cisco ONS and I'm aware that Ciena and Fujitsu also have similar products. We really don't have budget for a large optical refresh effort. However, we've saved some money here and there in the routing/switching arena by leveraging Arista and even Cumulus. I'm wondering if there are smaller players in the optical arena that have a good quality/price value? Again, we don't need sophisticated features... we primarily have 2-to-4 1Gb and 10Gb ports required per site, then we mux those onto a wavelength and extend it to the two data centers. Most buildings are set up the same way, each on a different wavelength so the don't even see each other... only the data centers. If you guys know of any optical gear that you can vouch for (and which costs less than a small house), we would greatly appreciate it. Thanks LFOD From nanog at ics-il.net Thu Nov 2 21:21:54 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 2 Nov 2017 16:21:54 -0500 (CDT) Subject: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover In-Reply-To: References: <048ed782-f4bd-1ae1-6bbb-e5f6cf0f3cf7@vaxination.ca> <46506f37-0559-99ac-5948-9ea8ad987910@vaxination.ca> <1509573065_26460@surgemail.mnsi.net> <122173526.3244.1509585594848.JavaMail.mhammett@ThunderFuck> <9578293AE169674F9A048B2BC9A081B4026BDEB8D5@MUNPRDMBXA1.medline.com> Message-ID: <1501892366.4167.1509657699774.JavaMail.mhammett@ThunderFuck> I believe when I've looked into it before, UP required your utility to be at the far outside edge of their ROW, so not really close to the track. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Joe Abley" To: "Steve Naslund" Cc: nanog at nanog.org Sent: Thursday, November 2, 2017 1:40:59 PM Subject: Re: Calgary <-> Toronto 100% Canadian Fibre Resiliency on failover On 2 Nov 2017, at 09:25, Naslund, Steve wrote: > There are four facts to be aware of here. > > 1. Locators are not 100% especially when it comes to fiber. I remember years ago in New Zealand there was buried fibre along the railway running north-south in the North Island that was not generally anybody's first choice of glass when trying to connect sites in Auckland and Wellington. The problem I heard described (from memory, long time ago, I am old) was that the natural vibration of the ground due to trains on rails had the effect over time of pushing conduit down the embankment away from the track, leading to fibre breaks with no corresponding obvious cause (no digging). You could bounce signals down the copper in the conduit from either side to try and figure out where the break was, but once on site you still had to find the fibre which was usually not anywhere close to where the map said it was buried. Joe From micahcroff at gmail.com Thu Nov 2 21:36:48 2017 From: micahcroff at gmail.com (Micah Croff) Date: Thu, 2 Nov 2017 14:36:48 -0700 Subject: Are there inexpensive DWDM products? In-Reply-To: <1844978323.4052.1509655060685.JavaMail.mhammett@ThunderFuck> References: <1844978323.4052.1509655060685.JavaMail.mhammett@ThunderFuck> Message-ID: I've used Adva passive DWDM MUX's and colored FlexOptix DWDM 10G optics. It worked very well with zero issues. I haven't personally used MUX's from fs.com but I've had colleagues use them and caution against them due to the quality. On Thu, Nov 2, 2017 at 1:37 PM, Mike Hammett wrote: > fs.com DWDM with a 1310 pass through port. That way you can still run 40G > or 100G over the 1310. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "LF OD" > To: nanog at nanog.org > Sent: Thursday, November 2, 2017 1:01:10 PM > Subject: Are there inexpensive DWDM products? > > We have several buildings and a couple data centers spread around the city > and interconnected via dark fiber. It's a very simple setup - no ROADM, no > real ring, no extended layer-2 or layer-3 via the optical gear. > > > Pretty much we just mux/demux a channel for each building so that each > building sees the two data centers directly even though the fiber span may > wind through a couple buildings along the way. In some cases, the distance > is short enough to use colored optics in the network gear, but mostly the > distances are just long enough to warrant transponder cards. > > > All that being said, a lot of the gear is approaching end of life (support > in some cases). I'm not an optical guru but I can muddle my way through > with Cisco ONS and I'm aware that Ciena and Fujitsu also have similar > products. We really don't have budget for a large optical refresh effort. > However, we've saved some money here and there in the routing/switching > arena by leveraging Arista and even Cumulus. I'm wondering if there are > smaller players in the optical arena that have a good quality/price value? > > > Again, we don't need sophisticated features... we primarily have 2-to-4 > 1Gb and 10Gb ports required per site, then we mux those onto a wavelength > and extend it to the two data centers. Most buildings are set up the same > way, each on a different wavelength so the don't even see each other... > only the data centers. > > > If you guys know of any optical gear that you can vouch for (and which > costs less than a small house), we would greatly appreciate it. Thanks > > > LFOD > > From brent at brentrjones.com Fri Nov 3 02:21:00 2017 From: brent at brentrjones.com (Brent Jones) Date: Thu, 2 Nov 2017 19:21:00 -0700 Subject: Are there inexpensive DWDM products? In-Reply-To: References: <1844978323.4052.1509655060685.JavaMail.mhammett@ThunderFuck> Message-ID: I've set a few people up with FS.com, and my $employer uses then for a lot of DWDM without issue. Quality bites everyone, cleaning terminations is one of the neglected steps :p On Thu, Nov 2, 2017 at 2:36 PM, Micah Croff wrote: > I've used Adva passive DWDM MUX's and colored FlexOptix DWDM 10G optics. It > worked very well with zero issues. I haven't personally used MUX's from > fs.com but I've had colleagues use them and caution against them due to > the > quality. > > On Thu, Nov 2, 2017 at 1:37 PM, Mike Hammett wrote: > > > fs.com DWDM with a 1310 pass through port. That way you can still run > 40G > > or 100G over the 1310. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ----- Original Message ----- > > > > From: "LF OD" > > To: nanog at nanog.org > > Sent: Thursday, November 2, 2017 1:01:10 PM > > Subject: Are there inexpensive DWDM products? > > > > We have several buildings and a couple data centers spread around the > city > > and interconnected via dark fiber. It's a very simple setup - no ROADM, > no > > real ring, no extended layer-2 or layer-3 via the optical gear. > > > > > > Pretty much we just mux/demux a channel for each building so that each > > building sees the two data centers directly even though the fiber span > may > > wind through a couple buildings along the way. In some cases, the > distance > > is short enough to use colored optics in the network gear, but mostly the > > distances are just long enough to warrant transponder cards. > > > > > > All that being said, a lot of the gear is approaching end of life > (support > > in some cases). I'm not an optical guru but I can muddle my way through > > with Cisco ONS and I'm aware that Ciena and Fujitsu also have similar > > products. We really don't have budget for a large optical refresh effort. > > However, we've saved some money here and there in the routing/switching > > arena by leveraging Arista and even Cumulus. I'm wondering if there are > > smaller players in the optical arena that have a good quality/price > value? > > > > > > Again, we don't need sophisticated features... we primarily have 2-to-4 > > 1Gb and 10Gb ports required per site, then we mux those onto a wavelength > > and extend it to the two data centers. Most buildings are set up the same > > way, each on a different wavelength so the don't even see each other... > > only the data centers. > > > > > > If you guys know of any optical gear that you can vouch for (and which > > costs less than a small house), we would greatly appreciate it. Thanks > > > > > > LFOD > > > > > -- Brent Jones brent at brentrjones.com From morrowc.lists at gmail.com Fri Nov 3 03:12:27 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 Nov 2017 23:12:27 -0400 Subject: Are there inexpensive DWDM products? In-Reply-To: References: <1844978323.4052.1509655060685.JavaMail.mhammett@ThunderFuck> Message-ID: On Thu, Nov 2, 2017 at 10:21 PM, Brent Jones wrote: > I've set a few people up with FS.com, and my $employer uses then for a lot > of DWDM without issue. > > as another fs.com user of cwdm muxes... yes, in the limited sample I have they work for me... you ought to be able to pair the CWDM muxes like: http://www.fs.com/products/42972.html with their 80km optics and get pretty far along... a 'city' solution shouldn't really need more than 80k, right? :) > Quality bites everyone, cleaning terminations is one of the neglected steps > :p > > On Thu, Nov 2, 2017 at 2:36 PM, Micah Croff wrote: > > > I've used Adva passive DWDM MUX's and colored FlexOptix DWDM 10G optics. > It > > worked very well with zero issues. I haven't personally used MUX's from > > fs.com but I've had colleagues use them and caution against them due to > > the > > quality. > > > > On Thu, Nov 2, 2017 at 1:37 PM, Mike Hammett wrote: > > > > > fs.com DWDM with a 1310 pass through port. That way you can still run > > 40G > > > or 100G over the 1310. > > > > > > > > > > > > > > > ----- > > > Mike Hammett > > > Intelligent Computing Solutions > > > http://www.ics-il.com > > > > > > Midwest-IX > > > http://www.midwest-ix.com > > > > > > ----- Original Message ----- > > > > > > From: "LF OD" > > > To: nanog at nanog.org > > > Sent: Thursday, November 2, 2017 1:01:10 PM > > > Subject: Are there inexpensive DWDM products? > > > > > > We have several buildings and a couple data centers spread around the > > city > > > and interconnected via dark fiber. It's a very simple setup - no ROADM, > > no > > > real ring, no extended layer-2 or layer-3 via the optical gear. > > > > > > > > > Pretty much we just mux/demux a channel for each building so that each > > > building sees the two data centers directly even though the fiber span > > may > > > wind through a couple buildings along the way. In some cases, the > > distance > > > is short enough to use colored optics in the network gear, but mostly > the > > > distances are just long enough to warrant transponder cards. > > > > > > > > > All that being said, a lot of the gear is approaching end of life > > (support > > > in some cases). I'm not an optical guru but I can muddle my way through > > > with Cisco ONS and I'm aware that Ciena and Fujitsu also have similar > > > products. We really don't have budget for a large optical refresh > effort. > > > However, we've saved some money here and there in the routing/switching > > > arena by leveraging Arista and even Cumulus. I'm wondering if there are > > > smaller players in the optical arena that have a good quality/price > > value? > > > > > > > > > Again, we don't need sophisticated features... we primarily have 2-to-4 > > > 1Gb and 10Gb ports required per site, then we mux those onto a > wavelength > > > and extend it to the two data centers. Most buildings are set up the > same > > > way, each on a different wavelength so the don't even see each other... > > > only the data centers. > > > > > > > > > If you guys know of any optical gear that you can vouch for (and which > > > costs less than a small house), we would greatly appreciate it. Thanks > > > > > > > > > LFOD > > > > > > > > > > > > -- > Brent Jones > brent at brentrjones.com > From morrowc.lists at gmail.com Fri Nov 3 03:14:18 2017 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 2 Nov 2017 23:14:18 -0400 Subject: Are there inexpensive DWDM products? In-Reply-To: References: <1844978323.4052.1509655060685.JavaMail.mhammett@ThunderFuck> Message-ID: On Thu, Nov 2, 2017 at 11:12 PM, Christopher Morrow wrote: > > > On Thu, Nov 2, 2017 at 10:21 PM, Brent Jones > wrote: > >> I've set a few people up with FS.com, and my $employer uses then for a lot >> of DWDM without issue. >> >> > as another fs.com user of cwdm muxes... yes, in the limited sample I have > they work for me... > you ought to be able to pair the CWDM muxes like: > http://www.fs.com/products/42972.html > > with their 80km optics and get pretty far along... a 'city' solution > shouldn't really need more than 80k, right? :) > > the example 80k cwdm sfp+: http://www.fs.com/products/19371.html > Quality bites everyone, cleaning terminations is one of the neglected steps >> :p >> >> On Thu, Nov 2, 2017 at 2:36 PM, Micah Croff wrote: >> >> > I've used Adva passive DWDM MUX's and colored FlexOptix DWDM 10G >> optics. It >> > worked very well with zero issues. I haven't personally used MUX's from >> > fs.com but I've had colleagues use them and caution against them due to >> > the >> > quality. >> > >> > On Thu, Nov 2, 2017 at 1:37 PM, Mike Hammett wrote: >> > >> > > fs.com DWDM with a 1310 pass through port. That way you can still run >> > 40G >> > > or 100G over the 1310. >> > > >> > > >> > > >> > > >> > > ----- >> > > Mike Hammett >> > > Intelligent Computing Solutions >> > > http://www.ics-il.com >> > > >> > > Midwest-IX >> > > http://www.midwest-ix.com >> > > >> > > ----- Original Message ----- >> > > >> > > From: "LF OD" >> > > To: nanog at nanog.org >> > > Sent: Thursday, November 2, 2017 1:01:10 PM >> > > Subject: Are there inexpensive DWDM products? >> > > >> > > We have several buildings and a couple data centers spread around the >> > city >> > > and interconnected via dark fiber. It's a very simple setup - no >> ROADM, >> > no >> > > real ring, no extended layer-2 or layer-3 via the optical gear. >> > > >> > > >> > > Pretty much we just mux/demux a channel for each building so that each >> > > building sees the two data centers directly even though the fiber span >> > may >> > > wind through a couple buildings along the way. In some cases, the >> > distance >> > > is short enough to use colored optics in the network gear, but mostly >> the >> > > distances are just long enough to warrant transponder cards. >> > > >> > > >> > > All that being said, a lot of the gear is approaching end of life >> > (support >> > > in some cases). I'm not an optical guru but I can muddle my way >> through >> > > with Cisco ONS and I'm aware that Ciena and Fujitsu also have similar >> > > products. We really don't have budget for a large optical refresh >> effort. >> > > However, we've saved some money here and there in the >> routing/switching >> > > arena by leveraging Arista and even Cumulus. I'm wondering if there >> are >> > > smaller players in the optical arena that have a good quality/price >> > value? >> > > >> > > >> > > Again, we don't need sophisticated features... we primarily have >> 2-to-4 >> > > 1Gb and 10Gb ports required per site, then we mux those onto a >> wavelength >> > > and extend it to the two data centers. Most buildings are set up the >> same >> > > way, each on a different wavelength so the don't even see each >> other... >> > > only the data centers. >> > > >> > > >> > > If you guys know of any optical gear that you can vouch for (and which >> > > costs less than a small house), we would greatly appreciate it. Thanks >> > > >> > > >> > > LFOD >> > > >> > > >> > >> >> >> >> -- >> Brent Jones >> brent at brentrjones.com >> > > From hank at efes.iucc.ac.il Fri Nov 3 05:10:49 2017 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Fri, 3 Nov 2017 07:10:49 +0200 Subject: Are there inexpensive DWDM products? In-Reply-To: References: Message-ID: <6a19f3a8-1502-b1ce-0a88-12d9c91b73c9@efes.iucc.ac.il> On 02/11/2017 20:01, LF OD wrote: Try: https://www.packetlight.com/ -Hank > We have several buildings and a couple data centers spread around the city and interconnected via dark fiber. It's a very simple setup - no ROADM, no real ring, no extended layer-2 or layer-3 via the optical gear. > > > Pretty much we just mux/demux a channel for each building so that each building sees the two data centers directly even though the fiber span may wind through a couple buildings along the way. In some cases, the distance is short enough to use colored optics in the network gear, but mostly the distances are just long enough to warrant transponder cards. > > > All that being said, a lot of the gear is approaching end of life (support in some cases). I'm not an optical guru but I can muddle my way through with Cisco ONS and I'm aware that Ciena and Fujitsu also have similar products. We really don't have budget for a large optical refresh effort. However, we've saved some money here and there in the routing/switching arena by leveraging Arista and even Cumulus. I'm wondering if there are smaller players in the optical arena that have a good quality/price value? > > > Again, we don't need sophisticated features... we primarily have 2-to-4 1Gb and 10Gb ports required per site, then we mux those onto a wavelength and extend it to the two data centers. Most buildings are set up the same way, each on a different wavelength so the don't even see each other... only the data centers. > > > If you guys know of any optical gear that you can vouch for (and which costs less than a small house), we would greatly appreciate it. Thanks > > > LFOD > From adnan.ahmed1 at gmail.com Fri Nov 3 13:26:25 2017 From: adnan.ahmed1 at gmail.com (Adnan Ahmed) Date: Fri, 3 Nov 2017 09:26:25 -0400 Subject: Are there inexpensive DWDM products? In-Reply-To: <6a19f3a8-1502-b1ce-0a88-12d9c91b73c9@efes.iucc.ac.il> References: <6a19f3a8-1502-b1ce-0a88-12d9c91b73c9@efes.iucc.ac.il> Message-ID: Also look at these guys, https://www.optelian.com/products/dwdm-optical-multiplexing/ On Fri, Nov 3, 2017 at 1:10 AM, Hank Nussbacher wrote: > On 02/11/2017 20:01, LF OD wrote: > > Try: https://www.packetlight.com/ > > -Hank > > > We have several buildings and a couple data centers spread around the > city and interconnected via dark fiber. It's a very simple setup - no > ROADM, no real ring, no extended layer-2 or layer-3 via the optical gear. > > > > > > Pretty much we just mux/demux a channel for each building so that each > building sees the two data centers directly even though the fiber span may > wind through a couple buildings along the way. In some cases, the distance > is short enough to use colored optics in the network gear, but mostly the > distances are just long enough to warrant transponder cards. > > > > > > All that being said, a lot of the gear is approaching end of life > (support in some cases). I'm not an optical guru but I can muddle my way > through with Cisco ONS and I'm aware that Ciena and Fujitsu also have > similar products. We really don't have budget for a large optical refresh > effort. However, we've saved some money here and there in the > routing/switching arena by leveraging Arista and even Cumulus. I'm > wondering if there are smaller players in the optical arena that have a > good quality/price value? > > > > > > Again, we don't need sophisticated features... we primarily have 2-to-4 > 1Gb and 10Gb ports required per site, then we mux those onto a wavelength > and extend it to the two data centers. Most buildings are set up the same > way, each on a different wavelength so the don't even see each other... > only the data centers. > > > > > > If you guys know of any optical gear that you can vouch for (and which > costs less than a small house), we would greatly appreciate it. Thanks > > > > > > LFOD > > > > From cscora at apnic.net Fri Nov 3 18:02:46 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 4 Nov 2017 04:02:46 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20171103180246.DF125B3E0@thyme.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, SANOG, PacNOG, SAFNOG, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. 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 04 Nov, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 667790 Prefixes after maximum aggregation (per Origin AS): 260185 Deaggregation factor: 2.57 Unique aggregates announced (without unneeded subnets): 322511 Total ASes present in the Internet Routing Table: 58913 Prefixes per ASN: 11.34 Origin-only ASes present in the Internet Routing Table: 50897 Origin ASes announcing only one prefix: 22398 Transit ASes present in the Internet Routing Table: 8016 Transit-only ASes present in the Internet Routing Table: 242 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 35 Max AS path prepend of ASN ( 55644) 31 Prefixes from unregistered ASNs in the Routing Table: 95 Number of instances of unregistered ASNs: 95 Number of 32-bit ASNs allocated by the RIRs: 20457 Number of 32-bit ASNs visible in the Routing Table: 16298 Prefixes from 32-bit ASNs in the Routing Table: 67031 Number of bogon 32-bit ASNs visible in the Routing Table: 112 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 398 Number of addresses announced to Internet: 2857996768 Equivalent to 170 /8s, 89 /16s and 145 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 219841 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 184650 Total APNIC prefixes after maximum aggregation: 52789 APNIC Deaggregation factor: 3.50 Prefixes being announced from the APNIC address blocks: 183706 Unique aggregates announced from the APNIC address blocks: 75656 APNIC Region origin ASes present in the Internet Routing Table: 8454 APNIC Prefixes per ASN: 21.73 APNIC Region origin ASes announcing only one prefix: 2365 APNIC Region transit ASes present in the Internet Routing Table: 1217 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 35 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3310 Number of APNIC addresses announced to Internet: 766542560 Equivalent to 45 /8s, 176 /16s and 130 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 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: 200115 Total ARIN prefixes after maximum aggregation: 96679 ARIN Deaggregation factor: 2.07 Prefixes being announced from the ARIN address blocks: 201624 Unique aggregates announced from the ARIN address blocks: 94254 ARIN Region origin ASes present in the Internet Routing Table: 18002 ARIN Prefixes per ASN: 11.20 ARIN Region origin ASes announcing only one prefix: 6656 ARIN Region transit ASes present in the Internet Routing Table: 1778 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2244 Number of ARIN addresses announced to Internet: 1110413088 Equivalent to 66 /8s, 47 /16s and 143 /24s 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, 62464-63487, 64198-64296, 393216-397212 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: 179438 Total RIPE prefixes after maximum aggregation: 87653 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 175348 Unique aggregates announced from the RIPE address blocks: 105914 RIPE Region origin ASes present in the Internet Routing Table: 24546 RIPE Prefixes per ASN: 7.14 RIPE Region origin ASes announcing only one prefix: 11215 RIPE Region transit ASes present in the Internet Routing Table: 3486 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6326 Number of RIPE addresses announced to Internet: 713549696 Equivalent to 42 /8s, 135 /16s and 231 /24s 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, 61952-62463, 64396-64495 196608-207259 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: 85724 Total LACNIC prefixes after maximum aggregation: 19069 LACNIC Deaggregation factor: 4.50 Prefixes being announced from the LACNIC address blocks: 86983 Unique aggregates announced from the LACNIC address blocks: 39126 LACNIC Region origin ASes present in the Internet Routing Table: 6538 LACNIC Prefixes per ASN: 13.30 LACNIC Region origin ASes announcing only one prefix: 1816 LACNIC Region transit ASes present in the Internet Routing Table: 1198 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4055 Number of LACNIC addresses announced to Internet: 172476000 Equivalent to 10 /8s, 71 /16s and 198 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 17766 Total AfriNIC prefixes after maximum aggregation: 3923 AfriNIC Deaggregation factor: 4.53 Prefixes being announced from the AfriNIC address blocks: 19731 Unique aggregates announced from the AfriNIC address blocks: 7234 AfriNIC Region origin ASes present in the Internet Routing Table: 1094 AfriNIC Prefixes per ASN: 18.04 AfriNIC Region origin ASes announcing only one prefix: 345 AfriNIC Region transit ASes present in the Internet Routing Table: 214 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 363 Number of AfriNIC addresses announced to Internet: 94518528 Equivalent to 5 /8s, 162 /16s and 61 /24s 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 4538 5271 4192 76 ERX-CERNET-BKB China Education and Rese 7545 4110 410 412 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2788 11128 754 KIXS-AS-KR Korea Telecom, KR 17974 2783 900 78 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2766 1499 541 BSNL-NIB National Internet Backbone, IN 45899 2405 1494 147 VNPT-AS-VN VNPT Corp, VN 9808 2396 8699 32 CMNET-GD Guangdong Mobile Communication 9394 2176 4931 27 CTTNET China TieTong Telecommunications 7552 2126 1157 65 VIETEL-AS-AP Viettel Corporation, VN 4755 2113 422 221 TATACOMM-AS TATA Communications formerl 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 6327 3335 1323 86 SHAW - Shaw Communications Inc., CA 22773 3292 2952 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2175 405 107 MEGAPATH5-US - MegaPath Corporation, US 20115 2052 2289 421 CHARTER-NET-HKY-NC - Charter Communicat 6389 2045 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 209 1942 5063 648 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1881 4035 567 AMAZON-02 - Amazon.com, Inc., US 30036 1842 330 283 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1627 237 571 CABLEONE - CABLE ONE, INC., US 701 1578 10589 627 UUNET - MCI Communications Services, In 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 39891 3387 186 23 ALJAWWALSTC-AS, SA 20940 2840 850 2051 AKAMAI-ASN1, US 8551 2499 378 42 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2064 329 427 TELLCOM-AS, TR 12389 1893 1694 717 ROSTELECOM-AS, RU 12479 1852 1064 87 UNI2-AS, ES 9121 1806 1691 17 TTNET, TR 13188 1605 100 46 TRIOLAN, UA 6849 1225 355 21 UKRTELNET, UA 8402 1206 544 14 CORBINA-AS OJSC "Vimpelcom", RU 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 3549 538 282 Telmex Colombia S.A., CO 8151 3444 3421 582 Uninet S.A. de C.V., MX 11830 2333 367 41 Instituto Costarricense de Electricidad 6503 1598 437 53 Axtel, S.A.B. de C.V., MX 7303 1484 1016 194 Telecom Argentina S.A., AR 6147 1274 377 27 Telefonica del Peru S.A.A., PE 3816 1031 509 103 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 1001 2289 179 CLARO S.A., BR 11172 913 126 86 Alestra, S. de R.L. de C.V., MX 18881 902 1060 26 TELEF�NICA BRASIL S.A, BR 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 24863 1226 398 49 LINKdotNET-AS, EG 37611 778 91 8 Afrihost, ZA 36903 704 354 142 MT-MPLS, MA 36992 668 1383 31 ETISALAT-MISR, EG 24835 515 850 15 RAYA-AS, EG 8452 506 1730 17 TE-AS TE-AS, EG 29571 431 36 10 CITelecom-AS, CI 37492 420 367 77 ORANGE-, TN 15399 352 35 7 WANANCHI-, KE 23889 302 103 14 MauritiusTelecom, MU 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 4538 5271 4192 76 ERX-CERNET-BKB China Education and Rese 7545 4110 410 412 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3549 538 282 Telmex Colombia S.A., CO 8151 3444 3421 582 Uninet S.A. de C.V., MX 39891 3387 186 23 ALJAWWALSTC-AS, SA 6327 3335 1323 86 SHAW - Shaw Communications Inc., CA 22773 3292 2952 157 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 20940 2840 850 2051 AKAMAI-ASN1, US 4766 2788 11128 754 KIXS-AS-KR Korea Telecom, KR 17974 2783 900 78 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 4110 3698 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3387 3364 ALJAWWALSTC-AS, SA 10620 3549 3267 Telmex Colombia S.A., CO 6327 3335 3249 SHAW - Shaw Communications Inc., CA 22773 3292 3135 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8151 3444 2862 Uninet S.A. de C.V., MX 17974 2783 2705 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8551 2499 2457 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 9808 2396 2364 CMNET-GD Guangdong Mobile Communication Co.Ltd. 11830 2333 2292 Instituto Costarricense de Electricidad y Telec Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 64525 PRIVATE 45.119.143.0/24 133275 GIGANTIC-AS Gigantic Infotel P 64525 PRIVATE 45.125.62.0/24 133275 GIGANTIC-AS Gigantic Infotel P 65530 PRIVATE 45.249.40.0/24 133720 SOFTCALLCOC-AS SOFT CALL CUST- 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 65534 PRIVATE 58.68.109.0/24 10201 DWL-AS-IN Dishnet Wireless Lim 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 290012147 UNALLOCATED 63.65.43.0/24 7046 RFC2270-UUNET-CUSTOMER - MCI C 3489671207 UNALLOCATED 64.53.36.0/24 10279 WCCL-AS - West Carolina Commun 65543 DOCUMENT 79.98.33.0/24 43950 SPILSBY-AS =================== Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.14.0/23 10247 NETLINE, ZA 14.192.48.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.49.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.50.0/23 10247 NETLINE, ZA 14.192.50.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.51.0/24 134833 LIHGL-HK LANLIAN INTERNATIONAL HOLDING GROUP LIMITE 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 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:15 /9:13 /10:36 /11:106 /12:285 /13:552 /14:1053 /15:1865 /16:13397 /17:7746 /18:13608 /19:25259 /20:39160 /21:43306 /22:80799 /23:66438 /24:371936 /25:848 /26:619 /27:648 /28:35 /29:21 /30:16 /31:2 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3129 3335 SHAW - Shaw Communications Inc., CA 39891 2946 3387 ALJAWWALSTC-AS, SA 22773 2529 3292 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2070 2175 MEGAPATH5-US - MegaPath Corporation, US 8551 1963 2499 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 1703 2333 Instituto Costarricense de Electricidad y Telec 30036 1613 1842 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1537 3549 Telmex Colombia S.A., CO 11492 1447 1627 CABLEONE - CABLE ONE, INC., US 34984 1370 2064 TELLCOM-AS, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1564 2:839 4:18 5:2502 6:36 8:1065 9:1 12:1854 13:165 14:1725 15:29 16:3 17:179 18:77 20:59 23:2483 24:1681 25:2 27:2367 31:1950 32:87 35:21 36:447 37:2383 38:1415 39:77 40:99 41:3045 42:517 43:1928 44:86 45:3193 46:2831 47:171 49:1336 50:1020 51:19 52:879 54:353 55:2 56:4 57:42 58:1570 59:992 60:360 61:2019 62:1741 63:1845 64:4587 65:2225 66:4453 67:2299 68:1185 69:3163 70:1129 71:588 72:2090 74:2622 75:389 76:411 77:1514 78:1553 79:1948 80:1415 81:1408 82:1060 83:747 84:986 85:1946 86:469 87:1214 88:862 89:2282 90:174 91:6227 92:1027 93:2316 94:2405 95:2675 96:648 97:352 98:957 99:101 100:153 101:1226 102:1 103:16102 104:3091 105:209 106:565 107:1737 108:831 109:2906 110:1508 111:1759 112:1244 113:1290 114:1053 115:1573 116:1645 117:1821 118:2148 119:1656 120:898 121:1075 122:2437 123:1880 124:1496 125:1818 128:957 129:663 130:446 131:1506 132:596 133:193 134:826 135:227 136:435 137:476 138:1954 139:540 140:381 141:671 142:747 143:911 144:806 145:189 146:1116 147:704 148:1490 149:613 150:712 151:995 152:720 153:300 154:925 155:747 156:716 157:746 158:600 159:1603 160:807 161:727 162:2504 163:513 164:991 165:1448 166:390 167:1335 168:3038 169:819 170:3541 171:392 172:1006 173:1896 174:818 175:775 176:1865 177:3962 178:2477 179:1124 180:2220 181:2103 182:2413 183:815 184:884 185:11268 186:3311 187:2362 188:2566 189:1924 190:8161 191:1345 192:9702 193:5865 194:4732 195:3963 196:2229 197:1270 198:5525 199:5873 200:7177 201:4628 202:10353 203:10006 204:4530 205:2861 206:3015 207:3117 208:3974 209:3884 210:3931 211:2068 212:2844 213:2578 214:860 215:67 216:5689 217:2109 218:920 219:601 220:1676 221:939 222:722 223:1287 End of report From eric at ericheather.com Sat Nov 4 01:58:01 2017 From: eric at ericheather.com (Eric C. Miller) Date: Sat, 4 Nov 2017 01:58:01 +0000 Subject: Are there inexpensive DWDM products? In-Reply-To: References: <6a19f3a8-1502-b1ce-0a88-12d9c91b73c9@efes.iucc.ac.il> Message-ID: These guys are pretty inexpensive. Take it for what it is :) https://www.sfpcables.com/cisco-cwdm-oadm-series Eric Miller, CCNP Network Engineering Consultant -----Original Message----- From: NANOG [mailto:nanog-bounces+eric=ericheather.com at nanog.org] On Behalf Of Adnan Ahmed Sent: Friday, November 3, 2017 9:26 AM To: Hank Nussbacher Cc: nanog at nanog.org Subject: Re: Are there inexpensive DWDM products? Also look at these guys, https://www.optelian.com/products/dwdm-optical-multiplexing/ On Fri, Nov 3, 2017 at 1:10 AM, Hank Nussbacher wrote: > On 02/11/2017 20:01, LF OD wrote: > > Try: https://www.packetlight.com/ > > -Hank > > > We have several buildings and a couple data centers spread around > > the > city and interconnected via dark fiber. It's a very simple setup - no > ROADM, no real ring, no extended layer-2 or layer-3 via the optical gear. > > > > > > Pretty much we just mux/demux a channel for each building so that > > each > building sees the two data centers directly even though the fiber span > may wind through a couple buildings along the way. In some cases, the > distance is short enough to use colored optics in the network gear, > but mostly the distances are just long enough to warrant transponder cards. > > > > > > All that being said, a lot of the gear is approaching end of life > (support in some cases). I'm not an optical guru but I can muddle my > way through with Cisco ONS and I'm aware that Ciena and Fujitsu also > have similar products. We really don't have budget for a large optical > refresh effort. However, we've saved some money here and there in the > routing/switching arena by leveraging Arista and even Cumulus. I'm > wondering if there are smaller players in the optical arena that have > a good quality/price value? > > > > > > Again, we don't need sophisticated features... we primarily have > > 2-to-4 > 1Gb and 10Gb ports required per site, then we mux those onto a > wavelength and extend it to the two data centers. Most buildings are > set up the same way, each on a different wavelength so the don't even see each other... > only the data centers. > > > > > > If you guys know of any optical gear that you can vouch for (and > > which > costs less than a small house), we would greatly appreciate it. Thanks > > > > > > LFOD > > > > From mfidelman at meetinghouse.net Tue Nov 7 02:45:07 2017 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Mon, 6 Nov 2017 19:45:07 -0700 Subject: media are reporting "major Internet outage" Message-ID: <467c4952-f10e-2e58-cad5-99a21b5eb547@meetinghouse.net> Folks, It seems like various media outlets are reporting a "major Internet outage" - some going so far as to call it an "attack." A few headlines that crossed Facebook today: "Major internet outage hits the U.S."  (Mashable via AOL News) "Widespread Comcast internet outage across U.S. includes Massachusetts customers"  (WHDH, Channel 7 News, Boston) A couple of more detailed sources reported that issues at L3 were effecting Comcast, specifically. Kind of interesting that there's been no mention here on nanog, nor have I personally noticed any issues (as a user or a hosting provider). Tempest in a teapot? Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From toddunder at gmail.com Tue Nov 7 02:49:22 2017 From: toddunder at gmail.com (Todd Underwood) Date: Mon, 6 Nov 2017 21:49:22 -0500 Subject: media are reporting "major Internet outage" In-Reply-To: <467c4952-f10e-2e58-cad5-99a21b5eb547@meetinghouse.net> References: <467c4952-f10e-2e58-cad5-99a21b5eb547@meetinghouse.net> Message-ID: There's a whole lot of 'Comcast and L3 are having problems' on Reddit. Nothing much beyond that. On Nov 6, 2017 21:47, "Miles Fidelman" wrote: > Folks, > > It seems like various media outlets are reporting a "major Internet > outage" - some going so far as to call it an "attack." > > A few headlines that crossed Facebook today: > > "Major internet outage hits the U.S." (Mashable via AOL News) > > "Widespread Comcast internet outage across U.S. includes Massachusetts > customers" (WHDH, Channel 7 News, Boston) > > A couple of more detailed sources reported that issues at L3 were > effecting Comcast, specifically. > > Kind of interesting that there's been no mention here on nanog, nor have I > personally noticed any issues (as a user or a hosting provider). > > Tempest in a teapot? > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > From marty at cloudflare.com Tue Nov 7 02:51:06 2017 From: marty at cloudflare.com (Marty Strong) Date: Mon, 6 Nov 2017 18:51:06 -0800 Subject: media are reporting "major Internet outage" In-Reply-To: References: <467c4952-f10e-2e58-cad5-99a21b5eb547@meetinghouse.net> Message-ID: https://puck.nether.net/pipermail/outages/2017-November/thread.html Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty at cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335 > On 6 Nov 2017, at 18:49, Todd Underwood wrote: > > There's a whole lot of 'Comcast and L3 are having problems' on Reddit. > Nothing much beyond that. > > On Nov 6, 2017 21:47, "Miles Fidelman" wrote: > >> Folks, >> >> It seems like various media outlets are reporting a "major Internet >> outage" - some going so far as to call it an "attack." >> >> A few headlines that crossed Facebook today: >> >> "Major internet outage hits the U.S." (Mashable via AOL News) >> >> "Widespread Comcast internet outage across U.S. includes Massachusetts >> customers" (WHDH, Channel 7 News, Boston) >> >> A couple of more detailed sources reported that issues at L3 were >> effecting Comcast, specifically. >> >> Kind of interesting that there's been no mention here on nanog, nor have I >> personally noticed any issues (as a user or a hosting provider). >> >> Tempest in a teapot? >> >> Miles Fidelman >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is. .... Yogi Berra >> >> From chaim.rieger at gmail.com Tue Nov 7 02:53:50 2017 From: chaim.rieger at gmail.com (Chaim Rieger) Date: Mon, 6 Nov 2017 18:53:50 -0800 Subject: media are reporting "major Internet outage" In-Reply-To: References: <467c4952-f10e-2e58-cad5-99a21b5eb547@meetinghouse.net> Message-ID: See the outages list for discussions that involve outages or service disruptions. On Nov 6, 2017 18:51, "Todd Underwood" wrote: > There's a whole lot of 'Comcast and L3 are having problems' on Reddit. > Nothing much beyond that. > > On Nov 6, 2017 21:47, "Miles Fidelman" wrote: > > > Folks, > > > > It seems like various media outlets are reporting a "major Internet > > outage" - some going so far as to call it an "attack." > > > > A few headlines that crossed Facebook today: > > > > "Major internet outage hits the U.S." (Mashable via AOL News) > > > > "Widespread Comcast internet outage across U.S. includes Massachusetts > > customers" (WHDH, Channel 7 News, Boston) > > > > A couple of more detailed sources reported that issues at L3 were > > effecting Comcast, specifically. > > > > Kind of interesting that there's been no mention here on nanog, nor have > I > > personally noticed any issues (as a user or a hosting provider). > > > > Tempest in a teapot? > > > > Miles Fidelman > > > > -- > > In theory, there is no difference between theory and practice. > > In practice, there is. .... Yogi Berra > > > > > From cb.list6 at gmail.com Tue Nov 7 02:54:15 2017 From: cb.list6 at gmail.com (Ca By) Date: Tue, 07 Nov 2017 02:54:15 +0000 Subject: media are reporting "major Internet outage" In-Reply-To: <467c4952-f10e-2e58-cad5-99a21b5eb547@meetinghouse.net> References: <467c4952-f10e-2e58-cad5-99a21b5eb547@meetinghouse.net> Message-ID: On Mon, Nov 6, 2017 at 6:46 PM Miles Fidelman wrote: > Folks, > > It seems like various media outlets are reporting a "major Internet > outage" - some going so far as to call it an "attack." > > A few headlines that crossed Facebook today: > > "Major internet outage hits the U.S." (Mashable via AOL News) > > "Widespread Comcast internet outage across U.S. includes Massachusetts > customers" (WHDH, Channel 7 News, Boston) > > A couple of more detailed sources reported that issues at L3 were > effecting Comcast, specifically. > > Kind of interesting that there's been no mention here on nanog, nor have > I personally noticed any issues (as a user or a hosting provider). > Outages go outage list https://puck.nether.net/pipermail/outages/2017-November/010952.html > Tempest in a teapot? > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > > From surfer at mauigateway.com Tue Nov 7 04:08:36 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 6 Nov 2017 20:08:36 -0800 Subject: media are reporting "major Internet outage" Message-ID: <20171106200836.30F0C685@m0117164.ppops.net> --- cb.list6 at gmail.com wrote: From: Ca By Outages go outage list https://puck.nether.net/pipermail/outages/2017-November/010952.html --------------------------------------- Be sure to use outages-discussion at outages.org for this one as outages at outages.org is just for reporting the initial problem. The list had a *major* "me too" blow up on this one. scott From aaron1 at gvtc.com Tue Nov 7 13:47:28 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 7 Nov 2017 07:47:28 -0600 Subject: media are reporting "major Internet outage" In-Reply-To: <20171106200836.30F0C685@m0117164.ppops.net> References: <20171106200836.30F0C685@m0117164.ppops.net> Message-ID: <000001d357ce$f3c4d940$db4e8bc0$@gvtc.com> I wonder if that was the cause of the snapchat outage yesterday or if the snapchat outage was altogether separate from what y'all are talking about. ? -Aaron From ilissa at imillerpr.com Tue Nov 7 17:11:26 2017 From: ilissa at imillerpr.com (Ilissa Miller) Date: Tue, 7 Nov 2017 12:11:26 -0500 Subject: GO DADDY Person? Message-ID: Is there a GoDaddy person on this list? There is a domain that has been created that is 100% a bot and need to flag it immediately. Already contacted GoDaddy directly but it is still active. Please contact me off list Thanks! From smalev at hotmail.com Tue Nov 7 01:14:51 2017 From: smalev at hotmail.com (Serge Malev) Date: Tue, 7 Nov 2017 01:14:51 +0000 Subject: Need a contact at GoDaddy NOC Message-ID: Hi. Could anyone from GoDaddy NOC, please, get in touch with me off list? One of our IP addresses is being blocked from accessing an address hosting some websites at Godaddy. Even GoDaddy's support and SSO sites are blocked. Using a different IP address for outbound Source NAT makes things work. But we would like to figure out what caused blocking in the first place to make sure we stop it happening in the future. Thank you. From miesi at india.com Tue Nov 7 13:45:37 2017 From: miesi at india.com (Thomas Mieslinger) Date: Tue, 7 Nov 2017 14:45:37 +0100 Subject: someone from easydns here? dns3.easydns.org. 2620:49:3::10 unreachable from AS8560 and 6939 Message-ID: <04ff3f8b-0ca1-301a-00a1-32c6b0e1c127@india.com> Hi, can someone operating easydns nameserver check whether 2620:49:3::10 is answering? I create a atlas measurement https://atlas.ripe.net/measurements/10137819 and I can see that some AS still can reach 2620:49:3::10 but many many timeouts. For me, it stops working after 2a00:dd80:9:3::2 (AS42210) Cheers Thomas From andree+nanog at toonk.nl Tue Nov 7 18:01:55 2017 From: andree+nanog at toonk.nl (Andree Toonk) Date: Tue, 07 Nov 2017 10:01:55 -0800 Subject: media are reporting "major Internet outage" In-Reply-To: <467c4952-f10e-2e58-cad5-99a21b5eb547@meetinghouse.net> References: <467c4952-f10e-2e58-cad5-99a21b5eb547@meetinghouse.net> Message-ID: <5A01F513.6070702@toonk.nl> Yah as mentioned by others, lots of chatter on the outages list. In short, starting at 17:47 utc level3 started leaking a whole bunch of more specifics, mainly for various comcast ASns but also others like for example AS10481 (Argentina) Many of these more specific announcements for large network such as comcast were picked up by other large network such at Tata, NTT, Liberty Global (UPC) and as a result caused a major traffic shift, resulting in a choke point somewhere along the way. One an example is the prefix 98.242.128.0/17 which is normally not visible, only as the larger block 98.192.0.0/10 (AS7922). Yesterday it was visible as 98.242.128.0/17 originated via another comcast AS (20214), with transit via level3. Good replay and visual of the timeline here: https://stat.ripe.net/widget/bgplay#w.resource=98.242.128.0%2F17 Cheers Andree My secret spy satellite informs me that Miles Fidelman wrote On 2017-11-06, 6:45 PM: > Folks, > > It seems like various media outlets are reporting a "major Internet > outage" - some going so far as to call it an "attack." > > A few headlines that crossed Facebook today: > > "Major internet outage hits the U.S." (Mashable via AOL News) > > "Widespread Comcast internet outage across U.S. includes Massachusetts > customers" (WHDH, Channel 7 News, Boston) > > A couple of more detailed sources reported that issues at L3 were > effecting Comcast, specifically. > > Kind of interesting that there's been no mention here on nanog, nor have > I personally noticed any issues (as a user or a hosting provider). > > Tempest in a teapot? > > Miles Fidelman > From amitchell at isipp.com Tue Nov 7 18:23:10 2017 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Tue, 7 Nov 2017 11:23:10 -0700 Subject: GO DADDY Person? In-Reply-To: References: Message-ID: > > Is there a GoDaddy person on this list? > > There is a domain that has been created that is 100% a bot and need to flag > it immediately. Ilissa, may we share this directly with our GoDaddy contact, including your contact information? Anne Anne P. Mitchell, Attorney at Law Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Legal Counsel: The CyberGreen Institute Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Elevations Credit Union Member Council Member, Board of Directors, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From freedman at freedman.net Tue Nov 7 20:22:37 2017 From: freedman at freedman.net (Avi Freedman) Date: Tue, 7 Nov 2017 15:22:37 -0500 (EST) Subject: Network nerd poker night 11/8 in Seattle Message-ID: <20171107202237.9A897DF75@freedman.net> If there are any network+poker nerds in the Seattle area tomorrow, we have 5 seats left at a network nerd poker night I'm hosting tomorrow night. Attendees are from cloud, content provider, hosting, infra services, travel, and SaaS analytics industries. We'll have food, drinks, a training session, and will be running ~3 single-table No Limit Texas Hold'em tournaments. If there's time/interest afterwards I may also initiate anyone interested into the wonders of Pot Limit Omaha. Prizes will be Bose head sets, to avoid corporate gift issues with playing for or awarding $. It's at the W Hotel in Bellevue, at 6pm tomorrow night. The focus is poker, socializing, and free-form network tech, business, and policy nerd discussions. Travel and gadget geeking allowed as well. Kentik is sponsoring the space, tables, and professional dealers, and we'll have a < 5 minute sponsor presentation. RSVP / info @ https://www.greenvelope.com/viewer/?ActivityCode=.public:ab155c3532ca4bd5ad563ff222b6a338393435313037#details If it overflows we'll cut off RSVPs at the URL and/or let people know by email. We're also going to organize to do another in Seattle in Feb and larger ones in NY and the Bay area in Q1, so if you have interest or ideas for format or quick content topics we could cover, please let me know. One thing we're considering is adding a table for heads-up battles - participants to decide if they want to add peering as part of the stakes. Thanks, Avi From me at nek0.net Tue Nov 7 21:01:49 2017 From: me at nek0.net (Stanislaw) Date: Tue, 07 Nov 2017 23:01:49 +0200 Subject: Juniper MX80 strange dst MAC address behavior Message-ID: <60a16e8a2845768db0acb48c18fd1d49@nek0.net> Today I was investigating strange unknown unicast traffic in LAN of IX which I operate. It was about 200 kbps of constant unknown unicast load. Unknown unicast is a rare ocasion in IX LAN as participants MAC addresses are almost persistent. I added a server in the vlan and started sniffing: all the unicast was coming from one participant MAC. One of the frames: XX:XX:XX:XX:ee:98 > 5e:5c:ab:31:c0:cb, ethertype IPv4 (0x0800), length 1434: XX.XX.16.30.80 > XX.XX.76.137.41934: Flags [.], seq 1619512599:1619513967, ack 3595347045, win 235, options [nop,nop,TS val 3650267181 ecr 1841068329], length 1368: HTTP Okay, destination MAC 5e:5c:ab:31:c0:cb isn't really in switches FDB table. I looked up the routing table and figured out that router announcing the bestpath for XX.XX.76.137 has MAC 5e:5e:ab:31:c0:cb. So customers sent a frame to: 5e:*5c*:ab:31:c0:cb The right address should be : 5e:*5e*:ab:31:c0:cb I tried next packet in dump, the same story: customer sends to: *90*:c6:9a:*e5*:2f:c1 right mac is : *b0*:c6:9a:*e4*:2f:c1 I converted differencing bytes to binary representation: 90: 10010000 b0: 10110000 e5: 11100101 e4: 11100100 I guess all the unknown unicast frames MAC addresses were having the same slightly difference from the right ones. So the router in general works fine (it has several gigabits of traffic in the IX) but sometimes it changes one or two bits in frame's destination MAC address. My guess it is caused by a large ARP table on customer's router. The router may have some tricky lookup algorithm preceding constant calculating speed over accuracy. I called their NOC, they said it is Juniper MX80 and also confirmed that it has more than 4k ARPs. Have anybody encountered with that kind of issue? From job at instituut.net Tue Nov 7 21:07:13 2017 From: job at instituut.net (Job Snijders) Date: Tue, 7 Nov 2017 22:07:13 +0100 Subject: Juniper MX80 strange dst MAC address behavior In-Reply-To: <60a16e8a2845768db0acb48c18fd1d49@nek0.net> References: <60a16e8a2845768db0acb48c18fd1d49@nek0.net> Message-ID: This smells like broken memory. I recommend to open a TAC/JTAC case. Kind regards, Job From cook at cookreport.com Tue Nov 7 21:08:29 2017 From: cook at cookreport.com (Gordon Cook) Date: Tue, 7 Nov 2017 16:08:29 -0500 Subject: Network nerd poker night 11/8 in Seattle In-Reply-To: <20171107202237.9A897DF75@freedman.net> References: <20171107202237.9A897DF75@freedman.net> Message-ID: Hi Avi long time no talk regards Gordon > On Nov 7, 2017, at 3:22 PM, Avi Freedman wrote: > > > If there are any network+poker nerds in the Seattle area tomorrow, we have 5 seats left at a network nerd poker night I'm hosting tomorrow night. > > Attendees are from cloud, content provider, hosting, infra services, travel, and SaaS analytics industries. > > We'll have food, drinks, a training session, and will be running ~3 single-table No Limit Texas Hold'em tournaments. > > If there's time/interest afterwards I may also initiate anyone interested into the wonders of Pot Limit Omaha. > > Prizes will be Bose head sets, to avoid corporate gift issues with playing for or awarding $. > > It's at the W Hotel in Bellevue, at 6pm tomorrow night. > > The focus is poker, socializing, and free-form network tech, business, and policy nerd discussions. Travel and gadget geeking allowed as well. Kentik is sponsoring the space, tables, and professional dealers, and we'll have a < 5 minute sponsor presentation. > > RSVP / info @ https://www.greenvelope.com/viewer/?ActivityCode=.public:ab155c3532ca4bd5ad563ff222b6a338393435313037#details > > If it overflows we'll cut off RSVPs at the URL and/or let people know by email. > > We're also going to organize to do another in Seattle in Feb and larger ones in NY and the Bay area in Q1, so if you have interest or ideas for format or quick content topics we could cover, please let me know. One thing we're considering is adding a table for heads-up battles - participants to decide if they want to add peering as part of the stakes. > > Thanks, > > Avi > From ahebert at pubnix.net Tue Nov 7 21:13:40 2017 From: ahebert at pubnix.net (Alain Hebert) Date: Tue, 7 Nov 2017 16:13:40 -0500 Subject: Juniper MX80 strange dst MAC address behavior In-Reply-To: References: <60a16e8a2845768db0acb48c18fd1d49@nek0.net> Message-ID: <0dcdfb89-219e-278f-21a6-cd7e594fde93@pubnix.net>     Last time I was able to smell broken memory was during the "core" days when a lead shorted. ----- 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 11/07/17 16:07, Job Snijders wrote: > This smells like broken memory. > > I recommend to open a TAC/JTAC case. > > Kind regards, > > Job > From mfidelman at meetinghouse.net Tue Nov 7 21:27:16 2017 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Tue, 07 Nov 2017 14:27:16 -0700 Subject: Network nerd poker night 11/8 in Seattle Message-ID: <20171107212721.87274CC2E7@server1.neighborhoods.net> Doesn't anybody play real poker any more? You know, 5 card draw, 7 card stud.  Oh for a good game of high-stakes 7 card high-low stud. Miles Fidelman -------- Original message --------From: Gordon Cook Date: 11/7/17 2:08 PM (GMT-07:00) To: Avi Freedman Cc: "nanog at nanog.org list" Subject: Re: Network nerd poker night 11/8 in Seattle Hi Avi long time no talk regards Gordon > On Nov 7, 2017, at 3:22 PM, Avi Freedman wrote: > > > If there are any network+poker nerds in the Seattle area tomorrow, we have 5 seats left at a network nerd poker night I'm hosting tomorrow night. > > Attendees are from cloud, content provider, hosting, infra services, travel, and SaaS analytics industries. > > We'll have food, drinks, a training session, and will be running ~3 single-table No Limit Texas Hold'em tournaments.  > > If there's time/interest afterwards I may also initiate anyone interested into the wonders of Pot Limit Omaha. > > Prizes will be Bose head sets, to avoid corporate gift issues with playing for or awarding $. > > It's at the W Hotel in Bellevue, at 6pm tomorrow night. > > The focus is poker, socializing, and free-form network tech, business, and policy nerd discussions.  Travel and gadget geeking allowed as well.  Kentik is sponsoring the space, tables, and professional dealers, and we'll have a < 5 minute sponsor presentation. > > RSVP / info @ https://www.greenvelope.com/viewer/?ActivityCode=.public:ab155c3532ca4bd5ad563ff222b6a338393435313037#details > > If it overflows we'll cut off RSVPs at the URL and/or let people know by email. > > We're also going to organize to do another in Seattle in Feb and larger ones in NY and the Bay area in Q1, so if you have interest or ideas for format or quick content topics we could cover, please let me know.  One thing we're considering is adding a table for heads-up battles - participants to decide if they want to add peering as part of the stakes. > > Thanks, > > Avi > From me at nek0.net Tue Nov 7 22:06:50 2017 From: me at nek0.net (Stanislaw) Date: Wed, 08 Nov 2017 00:06:50 +0200 Subject: Juniper QFX5100 VLAN flood input filter doesn't work Message-ID: Hello, list (again), I've been trying to use VLAN BUM traffic filter on QFX5100. The configuration on the test VLAN was quite trivial: Model: qfx5100-48s-6q Junos: 17.2R2.8 # show vlans Testvlan vlan-id 4030; forwarding-options { filter { input Testvlan-ingress; } flood { input Testvlan-flood; } } I connected two linux hosts to the test VLAN: # show interfaces ge-0/0/42 unit 0 { family ethernet-switching { vlan { members Testvlan; } } } # show interfaces ge-0/0/43 unit 0 { family ethernet-switching { vlan { members Testvlan; } } } The firewall filter wwas quite simple: # show firewall family ethernet-switching filter Testvlan-ingress term accept { then accept; } The flood input filter I was trying to use. According to the documentation, only Broadcast, Unknown unicast and Multicast (BUM) traffic goes here. The regular unicast traffic should be left intact by it. # show firewall family ethernet-switching filter Testvlan-flood term allow_arp { from { ether-type arp; } then accept; } term allow_ipv6_ns { from { destination-mac-address { 33:33:ff:00:00:00/24; } ether-type 0x86dd; } then accept; } term discard_all { then discard; } I started hosts to ping (and snif) each other.. And I saw only ARP requests/responses. "show ethernet-switching table" displayed that both hosts MAC were successfully learned, thus traffic between them should be considered as regular unicast. However, the last term in Testvlan-flood filter was blocking it. If I replace it with "accept" - traffic begins to flow. Are any Juniper QFX gurus here? I would really appreciate some advice. From tim at southern-internet.com Tue Nov 7 20:26:17 2017 From: tim at southern-internet.com (Tim Cailloux) Date: Tue, 07 Nov 2017 15:26:17 -0500 Subject: Network nerd poker night 11/8 in Seattle In-Reply-To: <20171107202237.9A897DF75@freedman.net> References: <20171107202237.9A897DF75@freedman.net> Message-ID: <1510086377.3219529.1164898160.153899C9@webmail.messagingengine.com> This sounds very awesome, and much better than when I first read this as a poker party for the DoD address space (11.0.0.0/8). ¯\_(ツ)_/¯ tim -- Tim Cailloux tim at southern-internet.com On Tue, Nov 7, 2017, at 15:22, Avi Freedman wrote: > > If there are any network+poker nerds in the Seattle area tomorrow, we > have 5 seats left at a network nerd poker night I'm hosting tomorrow > night. > > Attendees are from cloud, content provider, hosting, infra services, > travel, and SaaS analytics industries. > > We'll have food, drinks, a training session, and will be running ~3 > single-table No Limit Texas Hold'em tournaments. > > If there's time/interest afterwards I may also initiate anyone interested > into the wonders of Pot Limit Omaha. > > Prizes will be Bose head sets, to avoid corporate gift issues with > playing for or awarding $. > > It's at the W Hotel in Bellevue, at 6pm tomorrow night. > > The focus is poker, socializing, and free-form network tech, business, > and policy nerd discussions. Travel and gadget geeking allowed as well. > Kentik is sponsoring the space, tables, and professional dealers, and > we'll have a < 5 minute sponsor presentation. > > RSVP / info @ > https://www.greenvelope.com/viewer/?ActivityCode=.public:ab155c3532ca4bd5ad563ff222b6a338393435313037#details > > If it overflows we'll cut off RSVPs at the URL and/or let people know by > email. > > We're also going to organize to do another in Seattle in Feb and larger > ones in NY and the Bay area in Q1, so if you have interest or ideas for > format or quick content topics we could cover, please let me know. One > thing we're considering is adding a table for heads-up battles - > participants to decide if they want to add peering as part of the stakes. > > Thanks, > > Avi > From lists at silverlakeinternet.com Wed Nov 8 23:31:49 2017 From: lists at silverlakeinternet.com (Brett A Mansfield) Date: Wed, 8 Nov 2017 16:31:49 -0700 Subject: Out of country blocker for streaming services Message-ID: <0565EFC0-94D0-4C2D-AC76-1AFFE920104F@silverlakeinternet.com> Anyone able to tell me who the best person/company to contact is to get my subnet unblocked by all of the streaming providers? They all say I’m using a VPN service or an unblocker. This is a subnet I just leased from another provider. Shows it is in NJ but I use the IPs in Utah. Thank you, Brett A Mansfield From edugas at unknowndevice.ca Thu Nov 9 01:08:06 2017 From: edugas at unknowndevice.ca (Eric Dugas) Date: Wed, 8 Nov 2017 20:08:06 -0500 Subject: Out of country blocker for streaming services In-Reply-To: <0565EFC0-94D0-4C2D-AC76-1AFFE920104F@silverlakeinternet.com> References: <0565EFC0-94D0-4C2D-AC76-1AFFE920104F@silverlakeinternet.com> Message-ID: Contact the company you're leasing the subnet from and ask them to update the geo location to your particular location(s). It's going to take time, usually around two to four weeks to get updated at MaxMind, ipinfodb.com, etc. I have to add that leasing subnets is a bad idea in general and this one of the reasons. Good luck Eric On Nov 8 2017, at 6:31 pm, Brett A Mansfield wrote: > Anyone able to tell me who the best person/company to contact is to get my subnet unblocked by all of the streaming providers? > > They all say I’m using a VPN service or an unblocker. This is a subnet I just leased from another provider. > > Shows it is in NJ but I use the IPs in Utah. > > Thank you, > Brett A Mansfield From Mark_Feldman at comcast.com Thu Nov 9 18:22:11 2017 From: Mark_Feldman at comcast.com (Feldman, Mark) Date: Thu, 9 Nov 2017 18:22:11 +0000 Subject: New Jersey auth servers Message-ID: If someone responsible for or with connections to those running the state.nj.us/nj.gov auth name servers would contact me off list, it would be appreciated. We're having some resolution issues that appear to be due to DNS/network config at or near those auths. Mark Comcast T&P Core Network Servies From aaron1 at gvtc.com Thu Nov 9 19:45:16 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Thu, 9 Nov 2017 13:45:16 -0600 Subject: time warner-charter-spectrum route server looking glass Message-ID: <000601d35993$4461efd0$cd25cf70$@gvtc.com> Regarding Time Warner Cable (TWC AS 11427) , does anyone know of a route server (telnet) or looking glass (web based) for looking at bgp/ip routes and traceroutes from the inside the AS 11427 ? -Aaron From jared at puck.nether.net Thu Nov 9 20:04:55 2017 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 Nov 2017 15:04:55 -0500 Subject: time warner-charter-spectrum route server looking glass In-Reply-To: <000601d35993$4461efd0$cd25cf70$@gvtc.com> References: <000601d35993$4461efd0$cd25cf70$@gvtc.com> Message-ID: <81B0C0C6-1F5E-4B2C-B890-3A5769B4193E@puck.nether.net> > On Nov 9, 2017, at 2:45 PM, Aaron Gould wrote: > > Regarding Time Warner Cable (TWC AS 11427) , does anyone know of a route > server (telnet) or looking glass (web based) for looking at bgp/ip routes > and traceroutes from the inside the AS 11427 ? I tend to use RIPE Atlas for this. If you need credits let me know and I will send you some. - jared From rod.beck at unitedcablecompany.com Fri Nov 10 11:46:46 2017 From: rod.beck at unitedcablecompany.com (Rod Beck) Date: Fri, 10 Nov 2017 11:46:46 +0000 Subject: Weekend Reading - New Undersea Cable Systems Message-ID: Marea provides Trans-Atlantic connectivity via Virginia to Spain. Much needed diversity given the dominance of NYC-London. Facebook and Microsoft were principal backers. https://www.digitaltrends.com/cool-tech/microsoft-facebook-marea-undersea-cable-complete/ Indigo links Singapore and Jarkarta to Australia. Open cable design which involves spectrum sharing and allows each consortium member to select a different DWDM technology. Uses existing cable landing stations. https://www.subpartners.net/indigo.html Project to connect Indonesia, Singapore and Malaysia via an unrepeatered cable system. Cities include Bantam, Singapore, Mersing, and Lumpur (Cyberjaya). Non-consortium cable. http://www.seacablex.com/ Wet cable to connect Toronto to Buffalo. Dark fiber pairs. http://www.marketwired.com/press-release/crosslake-fibre-to-build-submarine-cable-connecting-long-island-to-wall-new-jersey-2237925.htm New low latency, high capacity cable connecting Marseille to Singapore and HK. Standard consortium model. Marseille/Singapore express route is 138 milliseconds. http://www.aaeone.com/ Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com 85 Király utca, 1077 Budapest rod.beck at unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png] From cscora at apnic.net Fri Nov 10 18:02:51 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 11 Nov 2017 04:02:51 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20171110180251.7AEBBB3E0@thyme.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, SANOG, PacNOG, SAFNOG, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. 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 11 Nov, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 668655 Prefixes after maximum aggregation (per Origin AS): 260785 Deaggregation factor: 2.56 Unique aggregates announced (without unneeded subnets): 323939 Total ASes present in the Internet Routing Table: 58967 Prefixes per ASN: 11.34 Origin-only ASes present in the Internet Routing Table: 50941 Origin ASes announcing only one prefix: 22406 Transit ASes present in the Internet Routing Table: 8026 Transit-only ASes present in the Internet Routing Table: 239 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 44 Max AS path prepend of ASN ( 55644) 41 Prefixes from unregistered ASNs in the Routing Table: 86 Number of instances of unregistered ASNs: 86 Number of 32-bit ASNs allocated by the RIRs: 20551 Number of 32-bit ASNs visible in the Routing Table: 16368 Prefixes from 32-bit ASNs in the Routing Table: 67078 Number of bogon 32-bit ASNs visible in the Routing Table: 31 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 376 Number of addresses announced to Internet: 2859891296 Equivalent to 170 /8s, 118 /16s and 122 /24s Percentage of available address space announced: 77.2 Percentage of allocated address space announced: 77.2 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 220528 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 184517 Total APNIC prefixes after maximum aggregation: 52837 APNIC Deaggregation factor: 3.49 Prefixes being announced from the APNIC address blocks: 183573 Unique aggregates announced from the APNIC address blocks: 76274 APNIC Region origin ASes present in the Internet Routing Table: 8464 APNIC Prefixes per ASN: 21.69 APNIC Region origin ASes announcing only one prefix: 2363 APNIC Region transit ASes present in the Internet Routing Table: 1208 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 44 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3326 Number of APNIC addresses announced to Internet: 766641376 Equivalent to 45 /8s, 178 /16s and 4 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 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: 200702 Total ARIN prefixes after maximum aggregation: 96754 ARIN Deaggregation factor: 2.07 Prefixes being announced from the ARIN address blocks: 202165 Unique aggregates announced from the ARIN address blocks: 94512 ARIN Region origin ASes present in the Internet Routing Table: 18011 ARIN Prefixes per ASN: 11.22 ARIN Region origin ASes announcing only one prefix: 6661 ARIN Region transit ASes present in the Internet Routing Table: 1787 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2254 Number of ARIN addresses announced to Internet: 1112638752 Equivalent to 66 /8s, 81 /16s and 133 /24s 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, 62464-63487, 64198-64296, 393216-397212 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: 179762 Total RIPE prefixes after maximum aggregation: 88012 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 175712 Unique aggregates announced from the RIPE address blocks: 106400 RIPE Region origin ASes present in the Internet Routing Table: 24574 RIPE Prefixes per ASN: 7.15 RIPE Region origin ASes announcing only one prefix: 11230 RIPE Region transit ASes present in the Internet Routing Table: 3495 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6350 Number of RIPE addresses announced to Internet: 713337216 Equivalent to 42 /8s, 132 /16s and 169 /24s 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, 61952-62463, 64396-64495 196608-207259 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: 85828 Total LACNIC prefixes after maximum aggregation: 19196 LACNIC Deaggregation factor: 4.47 Prefixes being announced from the LACNIC address blocks: 87105 Unique aggregates announced from the LACNIC address blocks: 39203 LACNIC Region origin ASes present in the Internet Routing Table: 6557 LACNIC Prefixes per ASN: 13.28 LACNIC Region origin ASes announcing only one prefix: 1804 LACNIC Region transit ASes present in the Internet Routing Table: 1201 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4075 Number of LACNIC addresses announced to Internet: 172368864 Equivalent to 10 /8s, 70 /16s and 35 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 17758 Total AfriNIC prefixes after maximum aggregation: 3922 AfriNIC Deaggregation factor: 4.53 Prefixes being announced from the AfriNIC address blocks: 19724 Unique aggregates announced from the AfriNIC address blocks: 7235 AfriNIC Region origin ASes present in the Internet Routing Table: 1091 AfriNIC Prefixes per ASN: 18.08 AfriNIC Region origin ASes announcing only one prefix: 347 AfriNIC Region transit ASes present in the Internet Routing Table: 215 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 363 Number of AfriNIC addresses announced to Internet: 94434048 Equivalent to 5 /8s, 160 /16s and 243 /24s 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 4538 5258 4192 76 ERX-CERNET-BKB China Education and Rese 7545 4101 410 409 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2789 11128 755 KIXS-AS-KR Korea Telecom, KR 17974 2780 916 76 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2760 1498 549 BSNL-NIB National Internet Backbone, IN 45899 2359 1489 155 VNPT-AS-VN VNPT Corp, VN 9394 2175 4931 26 CTTNET China TieTong Telecommunications 7552 2156 1157 65 VIETEL-AS-AP Viettel Corporation, VN 9808 2130 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2115 422 221 TATACOMM-AS TATA Communications formerl 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 6327 3320 1323 86 SHAW - Shaw Communications Inc., CA 22773 3295 2952 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2175 405 107 MEGAPATH5-US - MegaPath Corporation, US 20115 2052 2289 421 CHARTER-NET-HKY-NC - Charter Communicat 6389 2025 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 209 1944 5063 646 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1887 4051 575 AMAZON-02 - Amazon.com, Inc., US 30036 1847 330 274 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1655 236 579 CABLEONE - CABLE ONE, INC., US 701 1551 10589 627 UUNET - MCI Communications Services, In 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 39891 3387 186 23 ALJAWWALSTC-AS, SA 20940 2841 850 2053 AKAMAI-ASN1, US 8551 2498 378 42 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2062 329 427 TELLCOM-AS, TR 12479 1901 1066 102 UNI2-AS, ES 12389 1895 1696 716 ROSTELECOM-AS, RU 9121 1826 1691 17 TTNET, TR 13188 1605 100 46 TRIOLAN, UA 6849 1227 355 21 UKRTELNET, UA 8402 1218 544 14 CORBINA-AS OJSC "Vimpelcom", RU 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 3545 536 316 Telmex Colombia S.A., CO 8151 3444 3424 583 Uninet S.A. de C.V., MX 11830 2337 367 41 Instituto Costarricense de Electricidad 6503 1597 437 53 Axtel, S.A.B. de C.V., MX 7303 1486 1016 201 Telecom Argentina S.A., AR 6147 1273 377 27 Telefonica del Peru S.A.A., PE 3816 1031 509 103 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 1002 2289 179 CLARO S.A., BR 11172 912 126 85 Alestra, S. de R.L. de C.V., MX 18881 903 1062 27 TELEF�NICA BRASIL S.A, BR 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 24863 1209 398 50 LINKdotNET-AS, EG 37611 793 91 8 Afrihost, ZA 36903 705 354 143 MT-MPLS, MA 36992 634 1383 31 ETISALAT-MISR, EG 8452 515 1730 17 TE-AS TE-AS, EG 24835 465 850 15 RAYA-AS, EG 29571 435 36 10 CITelecom-AS, CI 37492 425 367 77 ORANGE-, TN 15399 342 35 7 WANANCHI-, KE 37342 331 32 1 MOVITEL, MZ 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 4538 5258 4192 76 ERX-CERNET-BKB China Education and Rese 7545 4101 410 409 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3545 536 316 Telmex Colombia S.A., CO 8151 3444 3424 583 Uninet S.A. de C.V., MX 39891 3387 186 23 ALJAWWALSTC-AS, SA 6327 3320 1323 86 SHAW - Shaw Communications Inc., CA 22773 3295 2952 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 20940 2841 850 2053 AKAMAI-ASN1, US 4766 2789 11128 755 KIXS-AS-KR Korea Telecom, KR 17974 2780 916 76 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 4101 3692 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3387 3364 ALJAWWALSTC-AS, SA 6327 3320 3234 SHAW - Shaw Communications Inc., CA 10620 3545 3229 Telmex Colombia S.A., CO 22773 3295 3139 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8151 3444 2861 Uninet S.A. de C.V., MX 17974 2780 2704 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8551 2498 2456 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 2337 2296 Instituto Costarricense de Electricidad y Telec 9829 2760 2211 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 290012147 UNALLOCATED 63.65.43.0/24 7046 RFC2270-UUNET-CUSTOMER - MCI C 3489671207 UNALLOCATED 64.53.36.0/24 10279 WCCL-AS - West Carolina Commun 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 64111 UNALLOCATED 98.159.5.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64111 UNALLOCATED 98.159.7.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64111 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.12.0/22 55427 BROADLINK-AS-AP Broadlink Nepal, NP 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 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:15 /9:13 /10:36 /11:106 /12:285 /13:551 /14:1060 /15:1861 /16:13358 /17:7750 /18:13561 /19:25199 /20:38943 /21:43304 /22:80936 /23:66652 /24:372814 /25:842 /26:618 /27:650 /28:35 /29:21 /30:16 /31:2 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3114 3320 SHAW - Shaw Communications Inc., CA 39891 2946 3387 ALJAWWALSTC-AS, SA 22773 2532 3295 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2070 2175 MEGAPATH5-US - MegaPath Corporation, US 8551 1962 2498 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 1707 2337 Instituto Costarricense de Electricidad y Telec 30036 1617 1847 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1539 3545 Telmex Colombia S.A., CO 11492 1476 1655 CABLEONE - CABLE ONE, INC., US 34984 1370 2062 TELLCOM-AS, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1569 2:840 4:18 5:2500 6:36 8:1067 9:1 12:1853 13:169 14:1725 15:29 16:3 17:181 18:76 20:59 21:1 23:2496 24:1923 25:2 27:2364 31:1949 32:87 35:21 36:455 37:2420 38:1420 39:77 40:100 41:2993 42:516 43:1938 44:82 45:3239 46:2793 47:180 49:1365 50:1033 51:28 52:879 54:354 55:3 56:4 57:42 58:1567 59:991 60:362 61:1990 62:1735 63:1844 64:4611 65:2233 66:4456 67:2303 68:1195 69:3162 70:1131 71:588 72:2098 74:2677 75:387 76:415 77:1498 78:1562 79:1926 80:1414 81:1409 82:1055 83:756 84:999 85:1946 86:469 87:1212 88:873 89:2291 90:174 91:6225 92:1028 93:2321 94:2406 95:2666 96:657 97:352 98:957 99:101 100:153 101:1537 102:1 103:16175 104:3170 105:210 106:562 107:1750 108:817 109:2910 110:1514 111:1733 112:1281 113:1279 114:1064 115:1602 116:1710 117:1640 118:2146 119:1653 120:762 121:1085 122:2434 123:1873 124:1502 125:1797 128:941 129:652 130:445 131:1521 132:603 133:193 134:843 135:228 136:420 137:486 138:1955 139:530 140:371 141:672 142:745 143:908 144:802 145:191 146:1130 147:697 148:1502 149:615 150:721 151:1009 152:719 153:303 154:933 155:750 156:724 157:752 158:596 159:1600 160:817 161:727 162:2537 163:514 164:996 165:1464 166:392 167:1345 168:3069 169:822 170:3533 171:396 172:1006 173:1891 174:821 175:774 176:1867 177:3964 178:2490 179:1127 180:2227 181:2105 182:2415 183:809 184:880 185:11366 186:3305 187:2329 188:2534 189:1922 190:8187 191:1267 192:9710 193:5870 194:4751 195:3952 196:2226 197:1392 198:5542 199:5881 200:7183 201:4650 202:10373 203:10004 204:4521 205:2856 206:3065 207:3099 208:3982 209:3876 210:3929 211:2064 212:2828 213:2581 214:844 215:63 216:5694 217:2118 218:888 219:596 220:1676 221:923 222:719 223:1211 End of report From tknchris at gmail.com Fri Nov 10 20:10:38 2017 From: tknchris at gmail.com (chris) Date: Fri, 10 Nov 2017 15:10:38 -0500 Subject: 95 Christopher Colombus Message-ID: Hello, Just wondering if anyone on the list is an existing tenant at 95 Christopher Colombus Jersey City NJ which has equipment already and/or a few RU of free rack space. We have a small project so renting a full cage etc isnt really practical. If you are in the building (real equipment not virtual presence via an NNI or something like that) please ping me off list. Thanks! chris From fgont at si6networks.com Sat Nov 11 01:14:28 2017 From: fgont at si6networks.com (Fernando Gont) Date: Fri, 10 Nov 2017 22:14:28 -0300 Subject: IPv6 first hop security on a budget? In-Reply-To: References: Message-ID: On 05/05/2017 08:27 PM, Joel Whitehouse wrote: > What's a good budget option for switching a small lab or office ipv6 > with RA Guard, DHCP6 snooping, and ICMP6 snooping? > If you do deploy this, please take a look at the issues discussed in RFC7113. Similar stuff is likely to apply to DHCPv6 snooping et al. 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 From saku at ytti.fi Sat Nov 11 05:00:47 2017 From: saku at ytti.fi (Saku Ytti) Date: Sat, 11 Nov 2017 14:00:47 +0900 Subject: IPv6 first hop security on a budget? In-Reply-To: References: Message-ID: Not suggesting there is no use case of RA Guard, DHCP6 Snooping, ICMP6 snooping, as I deployed IPv4 equivalent pretty much the day they were available on 3560. You might want to consider de-perimeterisation. Do you offer way to connect to intranet from Internet? If so, why not use same method in office, and have equivalent 0 trust on office infra? Additional benefit is OPEX reduction by not having users submit tickets 'X works from VPN but not from office' and vice versa. On 6 May 2017 at 08:27, Joel Whitehouse wrote: > What's a good budget option for switching a small lab or office ipv6 with RA > Guard, DHCP6 snooping, and ICMP6 snooping? -- ++ytti From joelja at bogus.com Sat Nov 11 06:28:03 2017 From: joelja at bogus.com (joel jaeggli) Date: Sat, 11 Nov 2017 14:28:03 +0800 Subject: IPv6 first hop security on a budget? In-Reply-To: References: Message-ID: <8c420b19-88e4-d82a-79b5-dbfab12836ee@bogus.com> On 11/11/17 09:14, Fernando Gont wrote: > On 05/05/2017 08:27 PM, Joel Whitehouse wrote: >> What's a good budget option for switching a small lab or office ipv6 >> with RA Guard, DHCP6 snooping, and ICMP6 snooping? >> > > If you do deploy this, please take a look at the issues discussed in > RFC7113. Similar stuff is likely to apply to DHCPv6 snooping et al. experiences vary, if you're looking to experience them first hand, warts implementation details and all, juniper ex2300c, cisco 3560cx are both small variants of both providers lower-end layer2/3 switches and are relatively inexpensive, fairly feature rich platforms. https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960cx_3650cx/software/release/15-2_3_e/configuration/guide/b_1523e_consolidated_2960cx_3560cx_cg/b_consolidated_152ex_2960-X_cg_chapter_0110000.pdf https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/router-advertisement-guard-edit-fo.html joel > Thanks! > > Best regards, > From jesse.n at westlandreg.com Sun Nov 12 03:08:35 2017 From: jesse.n at westlandreg.com (Jesse Nowlin) Date: Sat, 11 Nov 2017 22:08:35 -0500 Subject: Conference? Message-ID: Hey All, I know it's the weekend and all, but I wonder if any of you would be interested in this conference I am building for IT Support Professionals? We are all IT Pro's here, many of you in support, and you may be able to sympathize with my frustration with the lack of actual learning conferences out there, compared to the outright pitchfests we attend each year. For your consideration, my new business, tabgeeks.com I set out as an IT manager working together with my wife to give us an option to go to an event focused on learning, more specifically learning the wide array of topics we need to work with on a daily basis, instead of the thousand dollar events where only a small percentage is useful to you. I invite you to attend, and as your humble founder, invite your feedback, and ideas in how we can make this the greatest IT Support conference in the nation (outside of making it free ;-) ) Thank you for your time, and I am sorry if you feel this is too much of a marketing email. Jesse Nowlin IT Manager O: (310) 639-7130 X 217 M: (310) 579-6665 E: jesse.n at westlandreg.com 520 W. Willow St. Long Beach, CA 90806 www.westlandrealestategroup.com From dovid at telecurve.com Mon Nov 13 20:25:47 2017 From: dovid at telecurve.com (Dovid Bender) Date: Mon, 13 Nov 2017 15:25:47 -0500 Subject: Looking for help @ 60 Hudson Message-ID: Hi All, Sorry in advance and if this is not allowed. My 9-5 has hardware at 60 Hudson in cabinets that are on the smaller side. Every time we build out it's neat and pretty, over time it becomes a mess. Looking to hire a consultant that can come on site and advise the "correct" way of building out new cabinets so we can keep things in order as we grow. If you have anyone that would fit please send me an email off list. TIA. Dovid From nanog at ics-il.net Mon Nov 13 20:49:25 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 13 Nov 2017 14:49:25 -0600 (CST) Subject: Looking for help @ 60 Hudson In-Reply-To: References: Message-ID: <1256682467.102.1510606160277.JavaMail.mhammett@ThunderFuck> Keep the humans out of the rack and you should be fine. Where should I send the invoice? :-p ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Dovid Bender" To: "NANOG" Sent: Monday, November 13, 2017 2:25:47 PM Subject: Looking for help @ 60 Hudson Hi All, Sorry in advance and if this is not allowed. My 9-5 has hardware at 60 Hudson in cabinets that are on the smaller side. Every time we build out it's neat and pretty, over time it becomes a mess. Looking to hire a consultant that can come on site and advise the "correct" way of building out new cabinets so we can keep things in order as we grow. If you have anyone that would fit please send me an email off list. TIA. Dovid From sethm at rollernet.us Mon Nov 13 21:30:25 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 13 Nov 2017 13:30:25 -0800 Subject: Looking for help @ 60 Hudson In-Reply-To: <1256682467.102.1510606160277.JavaMail.mhammett@ThunderFuck> References: <1256682467.102.1510606160277.JavaMail.mhammett@ThunderFuck> Message-ID: <5e69245a-b0e6-cfa2-29d6-747dcbd397c4@rollernet.us> On 11/13/17 12:49, Mike Hammett wrote: > Keep the humans out of the rack and you should be fine. > > Where should I send the invoice?:-P It's easy to keep a rack nice if you take the time. I've spent hours removing and replacing cables in neatly dressed bundles because equipment changes required a different length/type cable, but sometimes that's what you gotta do to keep things neat and tidy. ~Seth From cra at WPI.EDU Mon Nov 13 22:05:35 2017 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 13 Nov 2017 17:05:35 -0500 Subject: Looking for help @ 60 Hudson In-Reply-To: <5e69245a-b0e6-cfa2-29d6-747dcbd397c4@rollernet.us> References: <1256682467.102.1510606160277.JavaMail.mhammett@ThunderFuck> <5e69245a-b0e6-cfa2-29d6-747dcbd397c4@rollernet.us> Message-ID: <20171113220535.GB23668@angus.ind.wpi.edu> On Mon, Nov 13, 2017 at 01:30:25PM -0800, Seth Mattinen wrote: > On 11/13/17 12:49, Mike Hammett wrote: > >Keep the humans out of the rack and you should be fine. > > > >Where should I send the invoice?:-P > > > It's easy to keep a rack nice if you take the time. I've spent hours > removing and replacing cables in neatly dressed bundles because > equipment changes required a different length/type cable, but > sometimes that's what you gotta do to keep things neat and tidy. Exactly. Most people do not want to spend the time to do it properly. From math at sizone.org Tue Nov 14 01:04:13 2017 From: math at sizone.org (Ken Chase) Date: Mon, 13 Nov 2017 20:04:13 -0500 Subject: keeping your cabinet clean (was Re: Looking for help @ 60 Hudson) In-Reply-To: <20171113220535.GB23668@angus.ind.wpi.edu> References: <1256682467.102.1510606160277.JavaMail.mhammett@ThunderFuck> <5e69245a-b0e6-cfa2-29d6-747dcbd397c4@rollernet.us> <20171113220535.GB23668@angus.ind.wpi.edu> Message-ID: <20171114010413.GB9461@sizone.org> Some tricks I've learned managing multicustomer/shared cabinets over the last 20+ years...sorry it's long, but I think there's some good info on keeping things clean and maintaining sanity. Please send your protips. Most of this is lower-end 1-4U sized mixes of gear specific and specific to cabinets that have 2-6U+ flux per quarter with some rushed installs. Huge one-time 12U blade installs of $1M appliances usually lend to gorgeous cable management schemes (and proper budgets) being included. No such lux here! TL;DR: thin premade ethernet of exact lengths and multiple random colours (never black!), use min gauge required power cable thickness of exact length, face A/B PDU's backwards on one side of rack cable management on other side, never get less than 30" wide x 36" deep cabinet (if not, wider better than deeper), premeasure vert mount rail positions to be compatible with rail length/ front of server clearance, prewire front of rack power/ether if needed (leave string too), practice tooless rail removal while you can still get in above/below, rack similar-depth gear together, switches face backwards (with front-to-back airflow switch config option of course) on rail-shelves not ears (that bend over time anyway) so they can be extracted out front and easily replaced in emergency. Details: Installing in 30" wide x 36" long cabinets makes all the diff over 24" x 30". A/B 0U PDUs on one side, cable wrangling ladders on other. More room = more flexbility. (If have no side panels and no neighbours, 24x30" is ok). 36" deep allows facing the PDUs backwards not sideways - cableheads extend backwards, not into the rail-tail path/airflow/etc. Worth getting the 90degree-bent-head cables too if you need the spare inches. (I ofset my PDUs vertically by 1/2 a plug-spacing distance so cable from left one fits between cableheads of right one.) Avoid racks that don't use cagenuts. Prethreaded holes get abused and stripped. Try to get the right size of cagenut, there's a few standards out there. Some will fit - poorly. (Either they fall out under weight or you end up trying to force them in with a thin screwdriver - I've seen people stab themselves in the hand. Ask for a cagenut tool (J-hooked shaped piece of metal that looks like a bent desktop-case PCI slot cover.) Having many power cables of varying lengths is key (but why doesnt anyone make 15" and 21" power cables?). Not having ziptied loops of 12ga wire hanging around made things much nicer (and better airflow). More $ but worth sanity. Esp. with varied coloured heads. Great for tracing (see ethernet below). Wire the gauge required - I find 10ga (6' long..) wire delivered with 100VA-max server configs often. Too thick to manage properly and usually unnecessary. But check your warranties and theoretical max power envelopes. Yes, full rack solns w/extendible arms exist but generally require vendor compatibility. Expensive too. Great for one time well-funded installs. Not practical for varied species installed over longer periods. Prewire any front-of-rack-powered gear when you first get the rack. I have 5 pairs (A/B) going to the front permanently ziptied and labelled - 3x2 in use for my back-facing switches, 1 for a small piece of gear (low watt microtik), others spare. Also prewire some proper length (multiple colours of) ether. Fishing ether through the side can be impossible in a full cabinet in a dense row (we're in APC pods). I leave string in there too (probably will use it for a twinax pull to the microtik soon, and pull more string with). Curse vendors for not picking a standard side (left vs right) for power ingress! (ibm and dell vs supermicro, sun and hp, IIRC?) Beware Dell's long fins/tails on their rails - won't fit in a 30" cabinet if your vert mount rails are too far back - or it blocks the power cord head on the pdu if it faces sideways/etc. And beware max/min rail extension - Dell seems 'longest', with many min. rail lengths of 25.5". I think I saw min. 26.5" once. Also had a cx jam a long Dell rail's tail into his fully assigned cabinet - in between a powercable head and the pdu body it was plugged into. BZZT! Took 20 min to get a monkey to reset at central panel. Thank proper cabinet grounding cables, right?) If you have an entirely empty cabinet to start with, grab a few different rails and ensure your cab's vertical mount rails are all within spacing spec. and give door-closing clearance to server noses. (See reference tables.) Moving them later can be impossible (though with sunfire rails that slid to varying lengths, it worked out luckily!) Must admit Dell's tooless rail installs are awesome now. Better than supermicro's and sun's (Sunfires). Learn how to derack them before you install, and practice a few times while you can still get your fingers/tools in from above/below. Make notes on how it works. Trying to guess how to derack a single U rail sandwiched in with no other access can be nearly impossible, especially an old EOL one with no identifying marks to google. Try to rack similar depth gear together. Nothing like having 1U 27" long Intels sandwiching 1U of 3/4 depth supermicro between them - cant get your hands in to do anything. 2U minimum together, but 3+ is better. Stash a headlamp in the rack too to see into these wells. Having more switchports than necessary (3 redundant 48 port switches with avg 2xc/box, avg 1.5U per box, 42U cabinet) allows 4' ethernet cables to be put in at exactly 3.75' extension into a switchport - minimal extra slack, just enough to manage the cable and keep it unstressed. Folding spare cable into management ladders makes manual tracing hard, and is bad form. Crimping your own rj45 ends for exact lengths is risky. Done it many times (and once saw a tech do it before a bgp session timed out on a damaged live cable! :), but results are poorer than factory crimps and dont resist stress well. ('Sides, do you have 8 different colour spools? See below.) Switch racking - I'd rather them on shelves not ears - then you can pull out your backwards-facing switch ass-first from front of the cabinet and slide the replacement in without moving cables too far -- trying to get the ears past the cabling can be heinous (and most ears cause major cantilevering due to deep heavy switches - after a few years I find things are bent from weight, impinging on the U below). There are thin little 3" wide rail-edge 'shelves' you can get, but your switch may not give the spare vertical mm required (about 3-4mm) - works best with 2u+ sized gear where there's spare mm play. Proper cable management trays/guides between the switches is great too (though eats U). Your density/financials will determine if that's viable. Its worth the U/sanity usually. Out of U for cable mgmt but have spare depth? Bungee cords won't work as anchor points to ziptie too - they sag in the heat over time. But rubber bungees ('tarp straps') work great. Though not for full 100m ether lengths, narrow gauge ethernet is key. You can fit like 8-12 of them into a run of what 4-5 took previously. I've had zero issues with them with rack-lengths of cable. Worth the $. I wish there was thin bicolour ethernet - it's sexy to have all your ether coloured the same (or same per category - red mgmt, yellow public, white internal) -- but then you need to know where the failed port 34 cable is... tracing identically coloured cables can suck, your eyes start playing tricks looking at 30 cables in a twisting bundle that you ziptied too tight trying to be pretty - and under tension, yanking on them may not identify the right cable properly -- even with labels (you stop trusting them anyway after the first couple errors or when job security is thin). I tend to use as many random colours as possible -- and note it in the switch configs. If the switch config doesnt match, slow down and check things twice from scratch. (Keep many colours and lengths handy for new installs! Blue is so ugly - peach ftw, amirite?). Note that no pattern of colour use will work - wire all mgmt ports as one colour, or all ports of one server one colour - either way, you assume the colour means the cable is wired a certain way, and that leads to errors. With no pattern, no dangerous assumptions are made - must check with the switch config. Maxing out #s of different colours leads to easier identification/fewer chances of neighbouring cables of same colour. If the management layer of your company doenst have to slave over racks, this is likely not an option. They like the pretty and impractical stuff best of course. Labelling only works so well - in 100-120F exhaust paths most glue just melts off. One client I had no input on the install for has 100s of little silvery labels littering the floor/lower U of their cabinet. So pretty! And goey cables. And thank god they're all white! Makes tracing so easy! :P (Of course no one ever wires black ethernet, right? That's a capital offence!) /kc On Mon, Nov 13, 2017 at 05:05:35PM -0500, Chuck Anderson said: >On Mon, Nov 13, 2017 at 01:30:25PM -0800, Seth Mattinen wrote: >> On 11/13/17 12:49, Mike Hammett wrote: >> >Keep the humans out of the rack and you should be fine. >> > >> >Where should I send the invoice?:-P >> >> >> It's easy to keep a rack nice if you take the time. I've spent hours >> removing and replacing cables in neatly dressed bundles because >> equipment changes required a different length/type cable, but >> sometimes that's what you gotta do to keep things neat and tidy. > >Exactly. Most people do not want to spend the time to do it properly. -- Ken Chase - math at sizone.org Guelph Canada From grgombas at cisco.com Tue Nov 14 02:36:04 2017 From: grgombas at cisco.com (Greg Gombas -X (grgombas)) Date: Tue, 14 Nov 2017 02:36:04 +0000 Subject: Issues with 4-octet BGP AS and Akamai? Message-ID: <481f0df49b4e4b719481810a54218ee7@XCH-RCD-005.cisco.com> Hello BGP and/or Akamai experts, Has anyone come across issues with using the new 4-octet BGP AS number format and reaching websites hosted by Akamai? One of my customers currently uses the AS number of one of their partner companies, which is in the standard 2-octed AS format. They were recently assigned their own AS which is in the 4-octet AS format. When they advertise their networks using the 2-octet AS number everything works fine, they can browse to all websites and all their outbound and inbound internet traffic works perfectly. However when they stop advertising their networks using the 2-octet AS and advertise their networks using the new 4-octet AS number, they lose reachability to a number of websites, all of which seem to be hosted by Akamai, including www.cisco.com, www.dell.com, and a number of others. Websites that are not hosted by Akamai work just fine. We checked their route advertisements from several looking glass servers and the routes seem to be propagating properly, albeit there may be a number of older routers still out there that don't understand the new 4 octet BGP AS format. For example, their AS shows up as AS_TRANS 23456 on some looking glass routers. My understanding is the 4-octet ASN's have been out for quite some time now, so any interoperability issues should have been resolved by now. But could there be some old BGP speakers who don't understand the new format or the translated AS 23456 format and drop the routes? Has anyone experienced similar issues when using the new format 4 byte BGP ASN's? Any thoughts on who at Akamai we can speak to in order to troubleshoot this further? Thanks, Greg [http://www.cisco.com/web/europe/images/email/signature/logo05.jpg] Gregory Gombas CCIE# 19649 - R&S Network Consulting Engineer Advanced Services grgombas at cisco.com Office: +1-212-714-4497 Mobile: +1-201-675-9457 Cisco Systems Limited One Penn Plaza 6th & 9th Floors New York, NY 10119 United States Cisco.com [Think before you print.]Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From opentext.dhofstee at gmail.com Tue Nov 14 09:12:01 2017 From: opentext.dhofstee at gmail.com (David Hofstee) Date: Tue, 14 Nov 2017 10:12:01 +0100 Subject: keeping your cabinet clean (was Re: Looking for help @ 60 Hudson) In-Reply-To: <20171114010413.GB9461@sizone.org> References: <1256682467.102.1510606160277.JavaMail.mhammett@ThunderFuck> <5e69245a-b0e6-cfa2-29d6-747dcbd397c4@rollernet.us> <20171113220535.GB23668@angus.ind.wpi.edu> <20171114010413.GB9461@sizone.org> Message-ID: Care to share some pics? David On 14 November 2017 at 02:04, Ken Chase wrote: > Some tricks I've learned managing multicustomer/shared cabinets over the > last > 20+ years...sorry it's long, but I think there's some good info on keeping > things clean and maintaining sanity. Please send your protips. > > Most of this is lower-end 1-4U sized mixes of gear specific and specific to > cabinets that have 2-6U+ flux per quarter with some rushed installs. Huge > one-time 12U blade installs of $1M appliances usually lend to gorgeous > cable > management schemes (and proper budgets) being included. No such lux here! > > TL;DR: thin premade ethernet of exact lengths and multiple random colours > (never black!), use min gauge required power cable thickness of exact > length, face A/B PDU's backwards on one side of rack cable management on > other side, never get less than 30" wide x 36" deep cabinet (if not, > wider > better than deeper), premeasure vert mount rail positions to be > compatible > with rail length/ front of server clearance, prewire front of rack > power/ether if needed (leave string too), practice tooless rail removal > while you can still get in above/below, rack similar-depth gear together, > switches face backwards (with front-to-back airflow switch config option > of > course) on rail-shelves not ears (that bend over time anyway) so they > can be > extracted out front and easily replaced in emergency. > > Details: > > Installing in 30" wide x 36" long cabinets makes all the diff over 24" x > 30". > A/B 0U PDUs on one side, cable wrangling ladders on other. More room = > more > flexbility. (If have no side panels and no neighbours, 24x30" is ok). 36" > deep > allows facing the PDUs backwards not sideways - cableheads extend > backwards, > not into the rail-tail path/airflow/etc. Worth getting the > 90degree-bent-head > cables too if you need the spare inches. (I ofset my PDUs vertically by > 1/2 a > plug-spacing distance so cable from left one fits between cableheads of > right > one.) > > Avoid racks that don't use cagenuts. Prethreaded holes get abused and > stripped. Try to get the right size of cagenut, there's a few standards out > there. Some will fit - poorly. (Either they fall out under weight or you > end > up trying to force them in with a thin screwdriver - I've seen people stab > themselves in the hand. Ask for a cagenut tool (J-hooked shaped piece of > metal that > looks like a bent desktop-case PCI slot cover.) > > Having many power cables of varying lengths is key (but why doesnt anyone > make > 15" and 21" power cables?). Not having ziptied loops of 12ga wire hanging > around made things much nicer (and better airflow). More $ but worth > sanity. > Esp. with varied coloured heads. Great for tracing (see ethernet below). > Wire > the gauge required - I find 10ga (6' long..) wire delivered with 100VA-max > server > configs often. Too thick to manage properly and usually unnecessary. But > check > your warranties and theoretical max power envelopes. > > Yes, full rack solns w/extendible arms exist but generally require vendor > compatibility. Expensive too. Great for one time well-funded installs. Not > practical for varied species installed over longer periods. > > Prewire any front-of-rack-powered gear when you first get the rack. I have > 5 > pairs (A/B) going to the front permanently ziptied and labelled - 3x2 in > use > for my back-facing switches, 1 for a small piece of gear (low watt > microtik), > others spare. Also prewire some proper length (multiple colours of) ether. > Fishing ether through the side can be impossible in a full cabinet in a > dense > row (we're in APC pods). I leave string in there too (probably will use it > for a twinax pull to the microtik soon, and pull more string with). > > Curse vendors for not picking a standard side (left vs right) for power > ingress! > (ibm and dell vs supermicro, sun and hp, IIRC?) > > Beware Dell's long fins/tails on their rails - won't fit in a 30" cabinet > if > your vert mount rails are too far back - or it blocks the power cord head > on > the pdu if it faces sideways/etc. And beware max/min rail extension - Dell > seems 'longest', with many min. rail lengths of 25.5". I think I saw min. > 26.5" once. > > Also had a cx jam a long Dell rail's tail into his fully assigned cabinet > - in > between a powercable head and the pdu body it was plugged into. BZZT! > Took 20 > min to get a monkey to reset at central panel. Thank proper cabinet > grounding > cables, right?) > > If you have an entirely empty cabinet to start with, grab a few different > rails and ensure your cab's vertical mount rails are all within spacing > spec. > and give door-closing clearance to server noses. (See reference tables.) > Moving them later can be impossible (though with sunfire rails that slid to > varying lengths, it worked out luckily!) > > Must admit Dell's tooless rail installs are awesome now. Better than > supermicro's and sun's (Sunfires). Learn how to derack them before you > install, and practice a few times while you can still get your > fingers/tools > in from above/below. Make notes on how it works. Trying to guess how to > derack > a single U rail sandwiched in with no other access can be nearly > impossible, > especially an old EOL one with no identifying marks to google. > > Try to rack similar depth gear together. Nothing like having 1U 27" long > Intels sandwiching 1U of 3/4 depth supermicro between them - cant get your > hands in to do anything. 2U minimum together, but 3+ is better. Stash a > headlamp > in the rack too to see into these wells. > > Having more switchports than necessary (3 redundant 48 port switches with > avg > 2xc/box, avg 1.5U per box, 42U cabinet) allows 4' ethernet cables to be > put in at > exactly 3.75' extension into a switchport - minimal extra slack, just > enough > to manage the cable and keep it unstressed. Folding spare cable into > management ladders makes manual tracing hard, and is bad form. Crimping > your > own rj45 ends for exact lengths is risky. Done it many times (and once saw > a tech do > it before a bgp session timed out on a damaged live cable! :), but results > are > poorer than factory crimps and dont resist stress well. ('Sides, do you > have 8 > different colour spools? See below.) > > Switch racking - I'd rather them on shelves not ears - then you can pull > out > your backwards-facing switch ass-first from front of the cabinet and slide > the > replacement in without moving cables too far -- trying to get the ears past > the cabling can be heinous (and most ears cause major cantilevering due to > deep heavy switches - after a few years I find things are bent from weight, > impinging on the U below). There are thin little 3" wide rail-edge > 'shelves' > you can get, but your switch may not give the spare vertical mm required > (about 3-4mm) - works best with 2u+ sized gear where there's spare mm play. > > Proper cable management trays/guides between the switches is great too > (though > eats U). Your density/financials will determine if that's viable. Its worth > the U/sanity usually. > > Out of U for cable mgmt but have spare depth? Bungee cords won't work as > anchor points to ziptie too - they sag in the heat over time. But rubber > bungees ('tarp straps') work great. > > Though not for full 100m ether lengths, narrow gauge ethernet is key. You > can > fit like 8-12 of them into a run of what 4-5 took previously. I've had zero > issues with them with rack-lengths of cable. Worth the $. > > I wish there was thin bicolour ethernet - it's sexy to have all your ether > coloured the same (or same per category - red mgmt, yellow public, white > internal) -- but then you need to know where the failed port 34 cable is... > tracing identically coloured cables can suck, your eyes start playing > tricks > looking at 30 cables in a twisting bundle that you ziptied too tight > trying to > be pretty - and under tension, yanking on them may not identify the right > cable properly -- even with labels (you stop trusting them anyway after the > first couple errors or when job security is thin). > > I tend to use as many random colours as possible -- and note it in the > switch > configs. If the switch config doesnt match, slow down and check things > twice > from scratch. (Keep many colours and lengths handy for new installs! Blue > is so > ugly - peach ftw, amirite?). > > Note that no pattern of colour use will work - wire all mgmt ports as one > colour, > or all ports of one server one colour - either way, you assume the colour > means > the cable is wired a certain way, and that leads to errors. With no > pattern, > no dangerous assumptions are made - must check with the switch config. > Maxing out > #s of different colours leads to easier identification/fewer chances of > neighbouring > cables of same colour. > > If the management layer of your company doenst have to slave over racks, > this > is likely not an option. They like the pretty and impractical stuff best > of course. > > Labelling only works so well - in 100-120F exhaust paths most glue just > melts > off. One client I had no input on the install for has 100s of little > silvery > labels littering the floor/lower U of their cabinet. So pretty! And goey > cables. And thank god they're all white! Makes tracing so easy! :P > > (Of course no one ever wires black ethernet, right? That's a capital > offence!) > > /kc > > > On Mon, Nov 13, 2017 at 05:05:35PM -0500, Chuck Anderson said: > >On Mon, Nov 13, 2017 at 01:30:25PM -0800, Seth Mattinen wrote: > >> On 11/13/17 12:49, Mike Hammett wrote: > >> >Keep the humans out of the rack and you should be fine. > >> > > >> >Where should I send the invoice?:-P > >> > >> > >> It's easy to keep a rack nice if you take the time. I've spent hours > >> removing and replacing cables in neatly dressed bundles because > >> equipment changes required a different length/type cable, but > >> sometimes that's what you gotta do to keep things neat and tidy. > > > >Exactly. Most people do not want to spend the time to do it properly. > > -- > Ken Chase - math at sizone.org Guelph Canada > -- -- My opinion is mine. From job at ntt.net Tue Nov 14 16:36:25 2017 From: job at ntt.net (Job Snijders) Date: Tue, 14 Nov 2017 17:36:25 +0100 Subject: Issues with 4-octet BGP AS and Akamai? In-Reply-To: <481f0df49b4e4b719481810a54218ee7@XCH-RCD-005.cisco.com> References: <481f0df49b4e4b719481810a54218ee7@XCH-RCD-005.cisco.com> Message-ID: <20171114163625.GD1109@Vurt.local> Hi, What prefix and ASN is this about? Are you sure you are advertising from an AS4 capable router? Do you see the expected 4-byte ASN as origin in a aggregator looking glass like http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=www.nlnog.net ? Kind regards, Job From jared at puck.nether.net Tue Nov 14 16:42:17 2017 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 14 Nov 2017 11:42:17 -0500 Subject: Issues with 4-octet BGP AS and Akamai? In-Reply-To: <481f0df49b4e4b719481810a54218ee7@XCH-RCD-005.cisco.com> References: <481f0df49b4e4b719481810a54218ee7@XCH-RCD-005.cisco.com> Message-ID: <52274612-9567-4B90-8FA5-0E378B7E57AC@puck.nether.net> Can you share details? Did you contact akamai? Feel free to ping me offline. - Jared > On Nov 13, 2017, at 9:36 PM, Greg Gombas -X (grgombas) wrote: > > Hello BGP and/or Akamai experts, > > Has anyone come across issues with using the new 4-octet BGP AS number format and reaching websites hosted by Akamai? > > One of my customers currently uses the AS number of one of their partner companies, which is in the standard 2-octed AS format. They were recently assigned their own AS which is in the 4-octet AS format. > > When they advertise their networks using the 2-octet AS number everything works fine, they can browse to all websites and all their outbound and inbound internet traffic works perfectly. > > However when they stop advertising their networks using the 2-octet AS and advertise their networks using the new 4-octet AS number, they lose reachability to a number of websites, all of which seem to be hosted by Akamai, including www.cisco.com, www.dell.com, and a number of others. Websites that are not hosted by Akamai work just fine. > > We checked their route advertisements from several looking glass servers and the routes seem to be propagating properly, albeit there may be a number of older routers still out there that don't understand the new 4 octet BGP AS format. > For example, their AS shows up as AS_TRANS 23456 on some looking glass routers. > > My understanding is the 4-octet ASN's have been out for quite some time now, so any interoperability issues should have been resolved by now. But could there be some old BGP speakers who don't understand the new format or the translated AS 23456 format and drop the routes? > > Has anyone experienced similar issues when using the new format 4 byte BGP ASN's? > > Any thoughts on who at Akamai we can speak to in order to troubleshoot this further? > > Thanks, > Greg > > > [http://www.cisco.com/web/europe/images/email/signature/logo05.jpg] > > Gregory Gombas > CCIE# 19649 - R&S > Network Consulting Engineer > Advanced Services > grgombas at cisco.com > Office: +1-212-714-4497 > Mobile: +1-201-675-9457 > > Cisco Systems Limited > One Penn Plaza > 6th & 9th Floors > New York, NY 10119 > United States > Cisco.com > > > > > > [Think before you print.]Think before you print. > > This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > From hvgeekwtrvl at gmail.com Tue Nov 14 18:16:14 2017 From: hvgeekwtrvl at gmail.com (james machado) Date: Tue, 14 Nov 2017 10:16:14 -0800 Subject: Issues with 4-octet BGP AS and Akamai? In-Reply-To: <481f0df49b4e4b719481810a54218ee7@XCH-RCD-005.cisco.com> References: <481f0df49b4e4b719481810a54218ee7@XCH-RCD-005.cisco.com> Message-ID: Greg, I have a 4 byte ASN and have not had any issues with reach ability, including the 2 websites you have linked. James From tyler at tgconrad.com Tue Nov 14 18:30:14 2017 From: tyler at tgconrad.com (Tyler Conrad) Date: Tue, 14 Nov 2017 10:30:14 -0800 Subject: Issues with 4-octet BGP AS and Akamai? In-Reply-To: References: <481f0df49b4e4b719481810a54218ee7@XCH-RCD-005.cisco.com> Message-ID: Are you advertising out multiple circuits? Check the pathing both directions if you can. A lot of CDNs enforce uRPF strict. On Tuesday, November 14, 2017, james machado wrote: > Greg, > > I have a 4 byte ASN and have not had any issues with reach ability, > including the 2 websites you have linked. > > James > From jared at puck.nether.net Tue Nov 14 19:19:52 2017 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 14 Nov 2017 14:19:52 -0500 Subject: Issues with 4-octet BGP AS and Akamai? In-Reply-To: References: <481f0df49b4e4b719481810a54218ee7@XCH-RCD-005.cisco.com> <20171114163625.GD1109@Vurt.local> Message-ID: <1ACA3ADA-B804-4B63-896B-A5DD043BEC34@puck.nether.net> It should be noted that AS_TRANS aka 23456 shouldn’t be visible on the global internet and many people may filter that on AS4_PATH cable devices. The fact that you’re seeing an AS_TRANS path from the Telia LG is likely an indication that route may be not fully internet visible. It’s fairly suspicious that someone in 2017 is still having that issue. There’s a chance that is being filtered if someone is putting AS_TRANS in the AS4_PATH, but it does appear the route is fully visible: https://stat.ripe.net/widget/routing-history#w.resource=216.165.0.0/17&w.normalise_visibility=true Note that the routes in red have low visibility, which includes some of the CIDR blocks you specified. https://stat.ripe.net/216.165.124.0%2F23#tabId=routing - Jared > On Nov 14, 2017, at 12:36 PM, Greg Gombas -X (grgombas) wrote: > > Thank you all for your assistance thus far. I wanted to confirm with my customer that it was okay to share more details and they said it was okay. We did just send an email to Akamai net support and awaiting their reply. > > The customer is NYULH (AS 394666). They currently use NYU (AS 12) for internet connectivity. They advertise the following prefixes to NYU: > > 216.165.124.0/24 > 216.165.125.0/24 > 216.165.126.0/24 > 216.165.127.0/24 > > NYU aggregates the above prefixes, strips NYULH's AS number, and replaces it with their own AS number (AS 12). > The aggregates are as follows: > > 216.165.124.0/23 > 216.165.126.0/23 > > Below is a sample /23 route seen from one of the looking glass servers with origin AS 12: > > 216.165.124.0/23 > [DIGITALOCEAN3 2017-11-11 from 162.243.188.2] * (100/-) [AS12i] > Type: BGP unicast univ > BGP.origin: IGP > BGP.as_path: 393406 3630 12 > BGP.next_hop: 162.243.188.2 > BGP.local_pref: 100 > BGP.atomic_aggr: > BGP.aggregator: 192.168.255.3 AS12 > BGP.community: (14061,2000) (14061,2002) (14061,3000) (14061,3001) (65363,714) (65363,2906) (65363,13335) (65363,13414) (65363,14061) (65363,20940) (65363,32934) (65363,41690) (65363,46489) (65363,65340) > BGP.ext_community: (RPKI Origin Validation State: not-found) > > With their routes originating from AS 12, all their internet connectivity works fine. > > However when they failover to their secondary path which is F5 Silverline DDOS protection over Optimimum Lightpath, they are unable to connect to any Akamai hosted websites. > The difference between their primary path and secondary path is that the secondary path does not strip their origin AS 394666. > > To answer Job's question, yes the originating router is AS4 capable. I checked the looking glass link you provided and see the correct origin AS 394666. See below: > > 216.165.124.0/24 > [DIGITALOCEAN5 14:14:44 from 5.101.111.2] * (100/-) [AS394666i] > Type: BGP unicast univ > BGP.origin: IGP > BGP.as_path: 202109 2914 55002 394666 > BGP.next_hop: 5.101.111.2 > BGP.local_pref: 100 > BGP.community: (2914,410) (2914,1203) (2914,2201) (2914,3200) (14061,2100) (14061,2101) (14061,4000) (14061,4001) > BGP.ext_community: (RPKI Origin Validation State: not-found) > > However we noticed some of Level 3's looking glass routers only see the AS_Trans 23456 as shown in the output below. I'm assuming that means some of Level3's routers are not AS4 capable, but does that mean they will drop the routes? > > Report generated from: car1.jan1 > > Route results for 216.165.124.0/24 from Jackson, MS > > BGP routing table entry for 216.165.124.0/24 > Paths: (2 available, best #2) > 1299 55002 23456 > AS-path translation: { TELIANET DEFENSENET-1 AS23456 } > ear3.Dallas1 (metric 43807) > Origin IGP, metric 100000, localpref 86, valid, internal > Community: North_America Lclprf_86 United_States Level3_Peer Dallas Level3:10497 > Originator: ear3.Dallas1 > 1299 55002 23456 > AS-path translation: { TELIANET DEFENSENET-1 AS23456 } > ear3.Dallas1 (metric 43807) > Origin IGP, metric 100000, localpref 86, valid, internal, best > Community: North_America Lclprf_86 United_States Level3_Peer Dallas Level3:10497 > Originator: ear3.Dallas1 > > Thanks, > Greg > > Gregory Gombas > CCIE# 19649 - R&S > Network Consulting Engineer > Advanced Services > grgombas at cisco.com > Office: +1-212-714-4497 > Mobile: +1-201-675-9457 > Cisco Systems Limited > One Penn Plaza > 6th & 9th Floors > New York, NY 10119 > United States > Cisco.com > > > > > > Think before you print. > This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > -----Original Message----- > From: Job Snijders [mailto:job at ntt.net] > Sent: Tuesday, November 14, 2017 11:36 AM > To: Greg Gombas -X (grgombas) > Cc: nanog at nanog.org > Subject: Re: Issues with 4-octet BGP AS and Akamai? > > Hi, > > What prefix and ASN is this about? > > Are you sure you are advertising from an AS4 capable router? > > Do you see the expected 4-byte ASN as origin in a aggregator looking glass like http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=www.nlnog.net ? > > Kind regards, > > Job From aaron1 at gvtc.com Tue Nov 14 20:06:06 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Tue, 14 Nov 2017 14:06:06 -0600 Subject: Issues with 4-octet BGP AS and Akamai? In-Reply-To: <481f0df49b4e4b719481810a54218ee7@XCH-RCD-005.cisco.com> References: <481f0df49b4e4b719481810a54218ee7@XCH-RCD-005.cisco.com> Message-ID: <000601d35d84$01f2c530$05d84f90$@gvtc.com> About who to speak with at Akamai... please forgive me if any of this contact info is out-of-date, as I'm pulling from my notes from an old network diagram... Akamai Customer Care - 877-425-2832 Akamai NOCC - 877-625-2624 - 877-6-akamai (same as above) - 617-444-3007 - nocc-shift at akamai.com - (if you do anything that would your cluster, give them at least 3 hours notice and give them IP of cluster - hardware issues and 24x7 contact: nocc-tix at akamai.com +1-877-6AKAMAI Akamai Network Support - traffic issues: netsupport-tix at akamai.com +1-888-421-1003 -Aaron From hvgeekwtrvl at gmail.com Wed Nov 15 00:40:04 2017 From: hvgeekwtrvl at gmail.com (james machado) Date: Tue, 14 Nov 2017 16:40:04 -0800 Subject: Issues with 4-octet BGP AS and Akamai? In-Reply-To: References: <481f0df49b4e4b719481810a54218ee7@XCH-RCD-005.cisco.com> Message-ID: Greg, I don't see a routing database object for your routes pointing too your AS394666 /24's, I only see one for AS12 for the /23 and /24's. It is possible (and probable) you are being filtered due to that. james route: 216.165.124.0/23 descr: NEW YORK UNIVERSITY (added by MAINT-AS6517) origin: AS12 remarks: This route object was registered by Global Cloud Xchange MAINT-AS6517 on behalf of their customer: NEW YORK UNIVERSITY notify: support at relianceglobalcom.com mnt-by: MAINT-AS6517 changed: support at globalcloudxchange.com 20160506 #00:49:14Z source: RADB (125-127) route: 216.165.127.0/24 descr: New York University Medical Center (maintained by NYU NOC) origin: AS12 mnt-by: MAINT-AS12 changed: noc at nyu.edu 20121121 #16:23:31Z source: RADB From woody at pch.net Wed Nov 15 05:19:45 2017 From: woody at pch.net (Bill Woodcock) Date: Tue, 14 Nov 2017 21:19:45 -0800 Subject: GCSC critical infrastructure protection questions: your input needed. Message-ID: One of PCH’s long-term efforts has been to encourage governments to restrict their use of offensive cyber attacks against civilian networks. As you might imagine, this is a reasonably popular idea everywhere except the US, Russia, and China. We’ve successfully gotten that effort out of the U.N., where it was floundering, and into a well-supported stand-alone commission. It’s being taken very seriously by governments, and will be one of the most important topics under discussion at the Global Conference on Cyberspace in Delhi next week. The work has been divided into two working-groups: one is addressing the question of what a norm should say (i.e. “Governments shouldn’t cyber-attack X”). The other is addressing the question of what infrastructures should be protected (i.e. what is the X that shouldn’t be attacked). I’m chairing that second working group. The main thing we’re delivering in Delhi is the result of a survey of what infrastructure people think should be protected. That survey is still open, and we’d like as many people to respond as possible. So, please consider doing so. It’ll only take a couple of minutes, and it’s a critical part of an admittedly very lengthy process to make your life easier. https://www.surveymonkey.com/r/criticalinfrastructure Much appreciated, -Bill Links in case you want to pursue further reading on the things I’ve mentioned above: https://en.wikipedia.org/wiki/Eligible_Receiver_97 https://lawfareblog.com/un-gge-failed-international-law-cyberspace-doomed-well https://cyberstability.org/about/ https://gccs2017.in https://en.wikipedia.org/wiki/Global_Conference_on_CyberSpace -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From bill at herrin.us Wed Nov 15 05:59:28 2017 From: bill at herrin.us (William Herrin) Date: Wed, 15 Nov 2017 00:59:28 -0500 Subject: GCSC critical infrastructure protection questions: your input needed. In-Reply-To: References: Message-ID: On Wed, Nov 15, 2017 at 12:19 AM, Bill Woodcock wrote: > One of PCH’s long-term efforts has been to encourage governments to > restrict their use of offensive cyber attacks against civilian networks. > As you might imagine, this is a reasonably popular idea everywhere except > the US, Russia, and China. We’ve successfully gotten that effort out of > the U.N., where it was floundering, and into a well-supported stand-alone > commission. It’s being taken very seriously by governments, and will be > one of the most important topics under discussion at the Global Conference > on Cyberspace in Delhi next week. > > The work has been divided into two working-groups: one is addressing the > question of what a norm should say (i.e. “Governments shouldn’t > cyber-attack X”). The other is addressing the question of what > infrastructures should be protected (i.e. what is the X that shouldn’t be > attacked). I’m chairing that second working group. The main thing we’re > delivering in Delhi is the result of a survey of what infrastructure people > think should be protected. That survey is still open, and we’d like as > many people to respond as possible. So, please consider doing so. It’ll > only take a couple of minutes, and it’s a critical part of an admittedly > very lengthy process to make your life easier. > Hi Bill, Aren't there already laws of war that forbid targeting civilians and civilian infrastructure as well as laying out the combatants' duties to mitigate collateral damage from strikes on government personnel and facilities? Is there some reason these laws should not continue to apply when the attacks are carried out with bits instead of bombs? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From george.herbert at gmail.com Wed Nov 15 06:53:59 2017 From: george.herbert at gmail.com (George William Herbert) Date: Tue, 14 Nov 2017 22:53:59 -0800 Subject: GCSC critical infrastructure protection questions: your input needed. In-Reply-To: References: Message-ID: That's a good question. Part of the problem is that the line between defense and offense, between intelligence gathering and attacking is more muddy than with "real weapons". Movies aside, you don't do intelligence gathering with guns in peacetime. Bringing guns makes it paramilitary operations and is or borders on an act of war, shots fired or not. If we just define cyber operations as weapons then most of what gets done is on that border. Independent ops (criminal, commercial) from state A into state B can lead to claims of A harboring terrorists. If that keeps up, B may legitimately take offensive real world responses. Like droning a hacker house or hostile cyber intelligence company. Actions like Microsoft disabling botnets remotely approach incidental acts of war worldwide. Accidentally doing damage in the course of non offensive intelligence gathering becomes MUCH worse. Government workers/ military who've been engaged in those activities may be seized as terrorists if they travel abroad. Gets ugly fast. Not simple. -george Sent from my iPhone > On Nov 14, 2017, at 9:59 PM, William Herrin wrote: > >> On Wed, Nov 15, 2017 at 12:19 AM, Bill Woodcock wrote: >> >> One of PCH’s long-term efforts has been to encourage governments to >> restrict their use of offensive cyber attacks against civilian networks. >> As you might imagine, this is a reasonably popular idea everywhere except >> the US, Russia, and China. We’ve successfully gotten that effort out of >> the U.N., where it was floundering, and into a well-supported stand-alone >> commission. It’s being taken very seriously by governments, and will be >> one of the most important topics under discussion at the Global Conference >> on Cyberspace in Delhi next week. >> >> The work has been divided into two working-groups: one is addressing the >> question of what a norm should say (i.e. “Governments shouldn’t >> cyber-attack X”). The other is addressing the question of what >> infrastructures should be protected (i.e. what is the X that shouldn’t be >> attacked). I’m chairing that second working group. The main thing we’re >> delivering in Delhi is the result of a survey of what infrastructure people >> think should be protected. That survey is still open, and we’d like as >> many people to respond as possible. So, please consider doing so. It’ll >> only take a couple of minutes, and it’s a critical part of an admittedly >> very lengthy process to make your life easier. >> > > Hi Bill, > > Aren't there already laws of war that forbid targeting civilians and > civilian infrastructure as well as laying out the combatants' duties to > mitigate collateral damage from strikes on government personnel and > facilities? Is there some reason these laws should not continue to apply > when the attacks are carried out with bits instead of bombs? > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: From woody at pch.net Wed Nov 15 08:21:42 2017 From: woody at pch.net (Bill Woodcock) Date: Wed, 15 Nov 2017 00:21:42 -0800 Subject: GCSC critical infrastructure protection questions: your input needed. In-Reply-To: References: Message-ID: > On Nov 14, 2017, at 9:59 PM, William Herrin wrote: > > Aren't there already laws of war that forbid targeting civilians and civilian infrastructure as well as laying out the combatants' duties to mitigate collateral damage from strikes on government personnel and facilities? Is there some reason these laws should not continue to apply when the attacks are carried out with bits instead of bombs? Because… cyber! I mean, it would be really _nice_ if they thought the way you do, but they don’t. They figure the old rules don’t also apply in a new venue. Also, the rules by which _war_ is conducted don’t apply when it’s not a _war_. And it’s essentially never a _war_ anymore. Militaries are very clear that they won’t listen to anyone else about how they should conduct themselves when they’re at war. This is an effort to create a norm governing their behavior when they’re not at war, and have less excuse or leeway or whatever. -Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From grgombas at cisco.com Tue Nov 14 17:36:04 2017 From: grgombas at cisco.com (Greg Gombas -X (grgombas)) Date: Tue, 14 Nov 2017 17:36:04 +0000 Subject: Issues with 4-octet BGP AS and Akamai? In-Reply-To: <20171114163625.GD1109@Vurt.local> References: <481f0df49b4e4b719481810a54218ee7@XCH-RCD-005.cisco.com> <20171114163625.GD1109@Vurt.local> Message-ID: Thank you all for your assistance thus far. I wanted to confirm with my customer that it was okay to share more details and they said it was okay. We did just send an email to Akamai net support and awaiting their reply. The customer is NYULH (AS 394666). They currently use NYU (AS 12) for internet connectivity. They advertise the following prefixes to NYU: 216.165.124.0/24 216.165.125.0/24 216.165.126.0/24 216.165.127.0/24 NYU aggregates the above prefixes, strips NYULH's AS number, and replaces it with their own AS number (AS 12). The aggregates are as follows: 216.165.124.0/23 216.165.126.0/23 Below is a sample /23 route seen from one of the looking glass servers with origin AS 12: 216.165.124.0/23 [DIGITALOCEAN3 2017-11-11 from 162.243.188.2] * (100/-) [AS12i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 393406 3630 12 BGP.next_hop: 162.243.188.2 BGP.local_pref: 100 BGP.atomic_aggr: BGP.aggregator: 192.168.255.3 AS12 BGP.community: (14061,2000) (14061,2002) (14061,3000) (14061,3001) (65363,714) (65363,2906) (65363,13335) (65363,13414) (65363,14061) (65363,20940) (65363,32934) (65363,41690) (65363,46489) (65363,65340) BGP.ext_community: (RPKI Origin Validation State: not-found) With their routes originating from AS 12, all their internet connectivity works fine. However when they failover to their secondary path which is F5 Silverline DDOS protection over Optimimum Lightpath, they are unable to connect to any Akamai hosted websites. The difference between their primary path and secondary path is that the secondary path does not strip their origin AS 394666. To answer Job's question, yes the originating router is AS4 capable. I checked the looking glass link you provided and see the correct origin AS 394666. See below: 216.165.124.0/24 [DIGITALOCEAN5 14:14:44 from 5.101.111.2] * (100/-) [AS394666i] Type: BGP unicast univ BGP.origin: IGP BGP.as_path: 202109 2914 55002 394666 BGP.next_hop: 5.101.111.2 BGP.local_pref: 100 BGP.community: (2914,410) (2914,1203) (2914,2201) (2914,3200) (14061,2100) (14061,2101) (14061,4000) (14061,4001) BGP.ext_community: (RPKI Origin Validation State: not-found) However we noticed some of Level 3's looking glass routers only see the AS_Trans 23456 as shown in the output below. I'm assuming that means some of Level3's routers are not AS4 capable, but does that mean they will drop the routes? Report generated from: car1.jan1 Route results for 216.165.124.0/24 from Jackson, MS BGP routing table entry for 216.165.124.0/24 Paths: (2 available, best #2) 1299 55002 23456 AS-path translation: { TELIANET DEFENSENET-1 AS23456 } ear3.Dallas1 (metric 43807) Origin IGP, metric 100000, localpref 86, valid, internal Community: North_America Lclprf_86 United_States Level3_Peer Dallas Level3:10497 Originator: ear3.Dallas1 1299 55002 23456 AS-path translation: { TELIANET DEFENSENET-1 AS23456 } ear3.Dallas1 (metric 43807) Origin IGP, metric 100000, localpref 86, valid, internal, best Community: North_America Lclprf_86 United_States Level3_Peer Dallas Level3:10497 Originator: ear3.Dallas1 Thanks, Greg Gregory Gombas CCIE# 19649 - R&S Network Consulting Engineer Advanced Services grgombas at cisco.com Office: +1-212-714-4497 Mobile: +1-201-675-9457 Cisco Systems Limited One Penn Plaza 6th & 9th Floors New York, NY 10119 United States Cisco.com Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html -----Original Message----- From: Job Snijders [mailto:job at ntt.net] Sent: Tuesday, November 14, 2017 11:36 AM To: Greg Gombas -X (grgombas) Cc: nanog at nanog.org Subject: Re: Issues with 4-octet BGP AS and Akamai? Hi, What prefix and ASN is this about? Are you sure you are advertising from an AS4 capable router? Do you see the expected 4-byte ASN as origin in a aggregator looking glass like http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=www.nlnog.net ? Kind regards, Job From grgombas at cisco.com Tue Nov 14 19:02:19 2017 From: grgombas at cisco.com (Greg Gombas -X (grgombas)) Date: Tue, 14 Nov 2017 19:02:19 +0000 Subject: Issues with 4-octet BGP AS and Akamai? In-Reply-To: References: <481f0df49b4e4b719481810a54218ee7@XCH-RCD-005.cisco.com> Message-ID: Hi Tyler, Unfortunately we had a limited window to test so could not check the reverse path. During our failover testing we stopped advertising out the primary path and only advertised out the secondary path. Routes are advertised out the secondary path through a DDOS prevention company called F5 Silverline which is reached via a GRE tunnel running over the Optimum Lightpath network. So outgoing traffic would go from NYULH going out the Optimum Lightpath circuit and return traffic coming in on F5 Silverline’s network then tunneled over Optimum Lightpath back to NYULH. So traffic was definitely routing asymmetrically. However F5 Silverline assured us they have many customers using a similar setup but have no issues with Akamai. I would think that many customers using similar DDOS prevention services such as F5 Silverline and Prolexic are routing asymmetrically as well, wouldn’t uRPF be affecting them all? Thanks, Greg [http://www.cisco.com/web/europe/images/email/signature/logo05.jpg] Gregory Gombas CCIE# 19649 – R&S Network Consulting Engineer Advanced Services grgombas at cisco.com Office: +1-212-714-4497 Mobile: +1-201-675-9457 Cisco Systems Limited One Penn Plaza 6th & 9th Floors New York, NY 10119 United States Cisco.com [Think before you print.]Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From: Tyler Conrad [mailto:tyler at tgconrad.com] Sent: Tuesday, November 14, 2017 1:30 PM To: james machado Cc: Greg Gombas -X (grgombas) ; nanog at nanog.org Subject: Re: Issues with 4-octet BGP AS and Akamai? Are you advertising out multiple circuits? Check the pathing both directions if you can. A lot of CDNs enforce uRPF strict. On Tuesday, November 14, 2017, james machado > wrote: Greg, I have a 4 byte ASN and have not had any issues with reach ability, including the 2 websites you have linked. James From Jamie.S.Bowden at raytheon.com Tue Nov 14 19:36:19 2017 From: Jamie.S.Bowden at raytheon.com (Jamie Bowden) Date: Tue, 14 Nov 2017 19:36:19 +0000 Subject: Looking for help @ 60 Hudson In-Reply-To: <5e69245a-b0e6-cfa2-29d6-747dcbd397c4@rollernet.us> References: <1256682467.102.1510606160277.JavaMail.mhammett@ThunderFuck> <5e69245a-b0e6-cfa2-29d6-747dcbd397c4@rollernet.us> Message-ID: <18dec3fdc5814c20b50faece07f04c60@SN1F00802MB0045.008f.mgd2.msft.net> >On Behalf Of Seth Mattinen > >On 11/13/17 12:49, Mike Hammett wrote: >> Keep the humans out of the rack and you should be fine. >> >> Where should I send the invoice?:-P > > >It's easy to keep a rack nice if you take the time. I've spent hours >removing and replacing cables in neatly dressed bundles because >equipment changes required a different length/type cable, but sometimes >that's what you gotta do to keep things neat and tidy. Go that way really fast. If something gets in your way, turn. I want my two dollars. -- Jamie Bowden From job at instituut.net Wed Nov 15 16:10:39 2017 From: job at instituut.net (Job Snijders) Date: Wed, 15 Nov 2017 17:10:39 +0100 Subject: Issues with 4-octet BGP AS and Akamai? In-Reply-To: References: <481f0df49b4e4b719481810a54218ee7@XCH-RCD-005.cisco.com> Message-ID: Hi James, On Wed, Nov 15, 2017 at 1:40 AM, james machado wrote: > I don't see a routing database object for your routes pointing too your > AS394666 /24's, I only see one for AS12 for the /23 and /24's. It is > possible (and probable) you are being filtered due to that. This is a really good observation, and a likely explanation! @ OP - during IP space migrations from AS A to AS B you should ensure that route objects exist for both ASNs. You may also want to double check with your upstream providers what their AS path filters look like for your circuits. Kind regards, Job From dovid at telecurve.com Thu Nov 16 17:13:58 2017 From: dovid at telecurve.com (Dovid Bender) Date: Thu, 16 Nov 2017 12:13:58 -0500 Subject: keeping your cabinet clean (was Re: Looking for help @ 60 Hudson) In-Reply-To: <20171114010413.GB9461@sizone.org> References: <1256682467.102.1510606160277.JavaMail.mhammett@ThunderFuck> <5e69245a-b0e6-cfa2-29d6-747dcbd397c4@rollernet.us> <20171113220535.GB23668@angus.ind.wpi.edu> <20171114010413.GB9461@sizone.org> Message-ID: Ken, Thanks for the in depth response. My biggest problem is that the DC gave us cabinets on the smaller side which makes them almost impossible to work with. If I was building out fresh I would prob get a cage and build out with big cabs but my boss isn't offering such luxuries..... On Mon, Nov 13, 2017 at 8:04 PM, Ken Chase wrote: > Some tricks I've learned managing multicustomer/shared cabinets over the > last > 20+ years...sorry it's long, but I think there's some good info on keeping > things clean and maintaining sanity. Please send your protips. > > Most of this is lower-end 1-4U sized mixes of gear specific and specific to > cabinets that have 2-6U+ flux per quarter with some rushed installs. Huge > one-time 12U blade installs of $1M appliances usually lend to gorgeous > cable > management schemes (and proper budgets) being included. No such lux here! > > TL;DR: thin premade ethernet of exact lengths and multiple random colours > (never black!), use min gauge required power cable thickness of exact > length, face A/B PDU's backwards on one side of rack cable management on > other side, never get less than 30" wide x 36" deep cabinet (if not, > wider > better than deeper), premeasure vert mount rail positions to be > compatible > with rail length/ front of server clearance, prewire front of rack > power/ether if needed (leave string too), practice tooless rail removal > while you can still get in above/below, rack similar-depth gear together, > switches face backwards (with front-to-back airflow switch config option > of > course) on rail-shelves not ears (that bend over time anyway) so they > can be > extracted out front and easily replaced in emergency. > > Details: > > Installing in 30" wide x 36" long cabinets makes all the diff over 24" x > 30". > A/B 0U PDUs on one side, cable wrangling ladders on other. More room = > more > flexbility. (If have no side panels and no neighbours, 24x30" is ok). 36" > deep > allows facing the PDUs backwards not sideways - cableheads extend > backwards, > not into the rail-tail path/airflow/etc. Worth getting the > 90degree-bent-head > cables too if you need the spare inches. (I ofset my PDUs vertically by > 1/2 a > plug-spacing distance so cable from left one fits between cableheads of > right > one.) > > Avoid racks that don't use cagenuts. Prethreaded holes get abused and > stripped. Try to get the right size of cagenut, there's a few standards out > there. Some will fit - poorly. (Either they fall out under weight or you > end > up trying to force them in with a thin screwdriver - I've seen people stab > themselves in the hand. Ask for a cagenut tool (J-hooked shaped piece of > metal that > looks like a bent desktop-case PCI slot cover.) > > Having many power cables of varying lengths is key (but why doesnt anyone > make > 15" and 21" power cables?). Not having ziptied loops of 12ga wire hanging > around made things much nicer (and better airflow). More $ but worth > sanity. > Esp. with varied coloured heads. Great for tracing (see ethernet below). > Wire > the gauge required - I find 10ga (6' long..) wire delivered with 100VA-max > server > configs often. Too thick to manage properly and usually unnecessary. But > check > your warranties and theoretical max power envelopes. > > Yes, full rack solns w/extendible arms exist but generally require vendor > compatibility. Expensive too. Great for one time well-funded installs. Not > practical for varied species installed over longer periods. > > Prewire any front-of-rack-powered gear when you first get the rack. I have > 5 > pairs (A/B) going to the front permanently ziptied and labelled - 3x2 in > use > for my back-facing switches, 1 for a small piece of gear (low watt > microtik), > others spare. Also prewire some proper length (multiple colours of) ether. > Fishing ether through the side can be impossible in a full cabinet in a > dense > row (we're in APC pods). I leave string in there too (probably will use it > for a twinax pull to the microtik soon, and pull more string with). > > Curse vendors for not picking a standard side (left vs right) for power > ingress! > (ibm and dell vs supermicro, sun and hp, IIRC?) > > Beware Dell's long fins/tails on their rails - won't fit in a 30" cabinet > if > your vert mount rails are too far back - or it blocks the power cord head > on > the pdu if it faces sideways/etc. And beware max/min rail extension - Dell > seems 'longest', with many min. rail lengths of 25.5". I think I saw min. > 26.5" once. > > Also had a cx jam a long Dell rail's tail into his fully assigned cabinet > - in > between a powercable head and the pdu body it was plugged into. BZZT! > Took 20 > min to get a monkey to reset at central panel. Thank proper cabinet > grounding > cables, right?) > > If you have an entirely empty cabinet to start with, grab a few different > rails and ensure your cab's vertical mount rails are all within spacing > spec. > and give door-closing clearance to server noses. (See reference tables.) > Moving them later can be impossible (though with sunfire rails that slid to > varying lengths, it worked out luckily!) > > Must admit Dell's tooless rail installs are awesome now. Better than > supermicro's and sun's (Sunfires). Learn how to derack them before you > install, and practice a few times while you can still get your > fingers/tools > in from above/below. Make notes on how it works. Trying to guess how to > derack > a single U rail sandwiched in with no other access can be nearly > impossible, > especially an old EOL one with no identifying marks to google. > > Try to rack similar depth gear together. Nothing like having 1U 27" long > Intels sandwiching 1U of 3/4 depth supermicro between them - cant get your > hands in to do anything. 2U minimum together, but 3+ is better. Stash a > headlamp > in the rack too to see into these wells. > > Having more switchports than necessary (3 redundant 48 port switches with > avg > 2xc/box, avg 1.5U per box, 42U cabinet) allows 4' ethernet cables to be > put in at > exactly 3.75' extension into a switchport - minimal extra slack, just > enough > to manage the cable and keep it unstressed. Folding spare cable into > management ladders makes manual tracing hard, and is bad form. Crimping > your > own rj45 ends for exact lengths is risky. Done it many times (and once saw > a tech do > it before a bgp session timed out on a damaged live cable! :), but results > are > poorer than factory crimps and dont resist stress well. ('Sides, do you > have 8 > different colour spools? See below.) > > Switch racking - I'd rather them on shelves not ears - then you can pull > out > your backwards-facing switch ass-first from front of the cabinet and slide > the > replacement in without moving cables too far -- trying to get the ears past > the cabling can be heinous (and most ears cause major cantilevering due to > deep heavy switches - after a few years I find things are bent from weight, > impinging on the U below). There are thin little 3" wide rail-edge > 'shelves' > you can get, but your switch may not give the spare vertical mm required > (about 3-4mm) - works best with 2u+ sized gear where there's spare mm play. > > Proper cable management trays/guides between the switches is great too > (though > eats U). Your density/financials will determine if that's viable. Its worth > the U/sanity usually. > > Out of U for cable mgmt but have spare depth? Bungee cords won't work as > anchor points to ziptie too - they sag in the heat over time. But rubber > bungees ('tarp straps') work great. > > Though not for full 100m ether lengths, narrow gauge ethernet is key. You > can > fit like 8-12 of them into a run of what 4-5 took previously. I've had zero > issues with them with rack-lengths of cable. Worth the $. > > I wish there was thin bicolour ethernet - it's sexy to have all your ether > coloured the same (or same per category - red mgmt, yellow public, white > internal) -- but then you need to know where the failed port 34 cable is... > tracing identically coloured cables can suck, your eyes start playing > tricks > looking at 30 cables in a twisting bundle that you ziptied too tight > trying to > be pretty - and under tension, yanking on them may not identify the right > cable properly -- even with labels (you stop trusting them anyway after the > first couple errors or when job security is thin). > > I tend to use as many random colours as possible -- and note it in the > switch > configs. If the switch config doesnt match, slow down and check things > twice > from scratch. (Keep many colours and lengths handy for new installs! Blue > is so > ugly - peach ftw, amirite?). > > Note that no pattern of colour use will work - wire all mgmt ports as one > colour, > or all ports of one server one colour - either way, you assume the colour > means > the cable is wired a certain way, and that leads to errors. With no > pattern, > no dangerous assumptions are made - must check with the switch config. > Maxing out > #s of different colours leads to easier identification/fewer chances of > neighbouring > cables of same colour. > > If the management layer of your company doenst have to slave over racks, > this > is likely not an option. They like the pretty and impractical stuff best > of course. > > Labelling only works so well - in 100-120F exhaust paths most glue just > melts > off. One client I had no input on the install for has 100s of little > silvery > labels littering the floor/lower U of their cabinet. So pretty! And goey > cables. And thank god they're all white! Makes tracing so easy! :P > > (Of course no one ever wires black ethernet, right? That's a capital > offence!) > > /kc > > > On Mon, Nov 13, 2017 at 05:05:35PM -0500, Chuck Anderson said: > >On Mon, Nov 13, 2017 at 01:30:25PM -0800, Seth Mattinen wrote: > >> On 11/13/17 12:49, Mike Hammett wrote: > >> >Keep the humans out of the rack and you should be fine. > >> > > >> >Where should I send the invoice?:-P > >> > >> > >> It's easy to keep a rack nice if you take the time. I've spent hours > >> removing and replacing cables in neatly dressed bundles because > >> equipment changes required a different length/type cable, but > >> sometimes that's what you gotta do to keep things neat and tidy. > > > >Exactly. Most people do not want to spend the time to do it properly. > > -- > Ken Chase - math at sizone.org Guelph Canada > From clinton at scripty.com Thu Nov 16 21:34:43 2017 From: clinton at scripty.com (Clinton Work) Date: Thu, 16 Nov 2017 14:34:43 -0700 Subject: Verizon AS701 contact for BGP route hijacking Message-ID: <1510868083.699070.1175163272.21F85BE8@webmail.messagingengine.com> Can a Verizon AS701 contact me to discuss why you are advertising BGP routes for the following TELUS AS852 address space. I tried to open a ticket with your IP NOC, but you won't open a ticket for a non-customer. 207.34.206.0/24 207.34.222.0/24 207.34.250.0/24 207.34.251.0/24 From clinton at scripty.com Thu Nov 16 22:20:24 2017 From: clinton at scripty.com (Clinton Work) Date: Thu, 16 Nov 2017 15:20:24 -0700 Subject: Verizon AS701 contact for BGP route hijacking In-Reply-To: <1510868083.699070.1175163272.21F85BE8@webmail.messagingengine.com> References: <1510868083.699070.1175163272.21F85BE8@webmail.messagingengine.com> Message-ID: <1510870824.714118.1175210768.1D19457E@webmail.messagingengine.com> The AS701 BGP routes have been removed. Thanks. On Thu, Nov 16, 2017, at 02:34 PM, Clinton Work wrote: > Can a Verizon AS701 contact me to discuss why you are advertising BGP > routes for the following TELUS AS852 address space. I tried to open a > ticket with your IP NOC, but you won't open a ticket for a non-customer. > > 207.34.206.0/24 > 207.34.222.0/24 > 207.34.250.0/24 > 207.34.251.0/24 > > From betty at nanog.org Thu Nov 16 23:15:57 2017 From: betty at nanog.org (Betty Burke ) Date: Thu, 16 Nov 2017 18:15:57 -0500 Subject: [NANOG-announce] NANOG 72 Meeting Dates Message-ID: The NANOG organization, and I personally, apologize for publishing the incorrect dates for NANOG 72 on our website and in the closing slides of NANOG 69 and NANOG 70. NANOG 72 was originally slated to start the first week of February, 2018. This changed in December 2016 for reasons explained below. Unfortunately, we did not change the NANOG website and closing slides. The website was updated in October 2017 and the closing slides at NANOG 71 showed the correct dates. For this, I apologize to our attendees and members. If you would like to discuss this in more detail, please email us at operations at nanog.org. Publication of the February meeting dates were delayed due to the difficulty in finding a venue in a preferred location large enough to host NANOG. The only acceptable venue was available on February 19-21, 2018. We updated several public meeting calendars, but failed to update the NANOG website and closing slides. Once again, please accept my sincere apology for the confusion and difficulty created by this error. I hope to see all of you in Atlanta on February 19th. Respectfully, Betty -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From cscora at apnic.net Fri Nov 17 18:02:53 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 18 Nov 2017 04:02:53 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20171117180253.203BEB3DB@thyme.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, SANOG, PacNOG, SAFNOG, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. 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 18 Nov, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 669243 Prefixes after maximum aggregation (per Origin AS): 261132 Deaggregation factor: 2.56 Unique aggregates announced (without unneeded subnets): 324419 Total ASes present in the Internet Routing Table: 59057 Prefixes per ASN: 11.33 Origin-only ASes present in the Internet Routing Table: 50996 Origin ASes announcing only one prefix: 22477 Transit ASes present in the Internet Routing Table: 8061 Transit-only ASes present in the Internet Routing Table: 237 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 33 Max AS path prepend of ASN ( 42350) 26 Prefixes from unregistered ASNs in the Routing Table: 66 Number of instances of unregistered ASNs: 66 Number of 32-bit ASNs allocated by the RIRs: 20629 Number of 32-bit ASNs visible in the Routing Table: 16445 Prefixes from 32-bit ASNs in the Routing Table: 67472 Number of bogon 32-bit ASNs visible in the Routing Table: 12 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 373 Number of addresses announced to Internet: 2860215200 Equivalent to 170 /8s, 123 /16s and 107 /24s Percentage of available address space announced: 77.3 Percentage of allocated address space announced: 77.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 221222 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 183760 Total APNIC prefixes after maximum aggregation: 52734 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 182870 Unique aggregates announced from the APNIC address blocks: 76396 APNIC Region origin ASes present in the Internet Routing Table: 8479 APNIC Prefixes per ASN: 21.57 APNIC Region origin ASes announcing only one prefix: 2375 APNIC Region transit ASes present in the Internet Routing Table: 1214 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 33 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3341 Number of APNIC addresses announced to Internet: 766706720 Equivalent to 45 /8s, 179 /16s and 4 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 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: 200928 Total ARIN prefixes after maximum aggregation: 96889 ARIN Deaggregation factor: 2.07 Prefixes being announced from the ARIN address blocks: 202381 Unique aggregates announced from the ARIN address blocks: 94639 ARIN Region origin ASes present in the Internet Routing Table: 18033 ARIN Prefixes per ASN: 11.22 ARIN Region origin ASes announcing only one prefix: 6686 ARIN Region transit ASes present in the Internet Routing Table: 1783 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2267 Number of ARIN addresses announced to Internet: 1112401952 Equivalent to 66 /8s, 77 /16s and 232 /24s 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, 62464-63487, 64198-64296, 393216-397212 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: 180372 Total RIPE prefixes after maximum aggregation: 88301 RIPE Deaggregation factor: 2.04 Prefixes being announced from the RIPE address blocks: 176264 Unique aggregates announced from the RIPE address blocks: 106583 RIPE Region origin ASes present in the Internet Routing Table: 24607 RIPE Prefixes per ASN: 7.16 RIPE Region origin ASes announcing only one prefix: 11253 RIPE Region transit ASes present in the Internet Routing Table: 3501 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 31 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6373 Number of RIPE addresses announced to Internet: 713322624 Equivalent to 42 /8s, 132 /16s and 112 /24s 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, 61952-62463, 64396-64495 196608-207259 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: 86119 Total LACNIC prefixes after maximum aggregation: 19232 LACNIC Deaggregation factor: 4.48 Prefixes being announced from the LACNIC address blocks: 87376 Unique aggregates announced from the LACNIC address blocks: 39262 LACNIC Region origin ASes present in the Internet Routing Table: 6572 LACNIC Prefixes per ASN: 13.30 LACNIC Region origin ASes announcing only one prefix: 1808 LACNIC Region transit ASes present in the Internet Routing Table: 1222 Average LACNIC Region AS path length visible: 5.1 Max LACNIC Region AS path length visible: 25 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4093 Number of LACNIC addresses announced to Internet: 172416736 Equivalent to 10 /8s, 70 /16s and 222 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 17996 Total AfriNIC prefixes after maximum aggregation: 3921 AfriNIC Deaggregation factor: 4.59 Prefixes being announced from the AfriNIC address blocks: 19979 Unique aggregates announced from the AfriNIC address blocks: 7237 AfriNIC Region origin ASes present in the Internet Routing Table: 1100 AfriNIC Prefixes per ASN: 18.16 AfriNIC Region origin ASes announcing only one prefix: 354 AfriNIC Region transit ASes present in the Internet Routing Table: 216 Average AfriNIC Region AS path length visible: 4.7 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 371 Number of AfriNIC addresses announced to Internet: 94916864 Equivalent to 5 /8s, 168 /16s and 81 /24s 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 4538 5278 4192 76 ERX-CERNET-BKB China Education and Rese 7545 4060 410 408 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2792 11128 756 KIXS-AS-KR Korea Telecom, KR 17974 2775 916 76 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2759 1499 540 BSNL-NIB National Internet Backbone, IN 45899 2342 1497 155 VNPT-AS-VN VNPT Corp, VN 7552 2233 1158 61 VIETEL-AS-AP Viettel Group, VN 9394 2168 4931 26 CTTNET China TieTong Telecommunications 9808 2122 8699 32 CMNET-GD Guangdong Mobile Communication 4755 2114 422 222 TATACOMM-AS TATA Communications formerl 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 6327 3328 1323 86 SHAW - Shaw Communications Inc., CA 22773 3301 2952 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2171 405 107 MEGAPATH5-US - MegaPath Corporation, US 20115 2054 2288 444 CHARTER-NET-HKY-NC - Charter Communicat 6389 2013 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 209 1928 5063 647 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 16509 1926 4057 585 AMAZON-02 - Amazon.com, Inc., US 30036 1845 330 300 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1660 235 578 CABLEONE - CABLE ONE, INC., US 701 1548 10589 626 UUNET - MCI Communications Services, In 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 39891 3387 186 23 ALJAWWALSTC-AS, SA 20940 2845 851 2055 AKAMAI-ASN1, US 8551 2496 378 42 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2063 329 427 TELLCOM-AS, TR 12479 1920 1066 102 UNI2-AS, ES 12389 1898 1698 718 ROSTELECOM-AS, RU 9121 1839 1691 17 TTNET, TR 13188 1604 100 52 TRIOLAN, UA 6849 1227 355 21 UKRTELNET, UA 8402 1218 544 14 CORBINA-AS OJSC "Vimpelcom", RU 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 3547 537 307 Telmex Colombia S.A., CO 8151 3448 3424 583 Uninet S.A. de C.V., MX 11830 2355 367 41 Instituto Costarricense de Electricidad 6503 1594 437 53 Axtel, S.A.B. de C.V., MX 7303 1488 1018 194 Telecom Argentina S.A., AR 6147 1219 377 27 Telefonica del Peru S.A.A., PE 3816 1030 509 103 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 1004 2290 174 CLARO S.A., BR 11172 913 126 85 Alestra, S. de R.L. de C.V., MX 18881 904 1063 28 TELEF�NICA BRASIL S.A, BR 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 24863 1207 398 48 LINKdotNET-AS, EG 37611 799 91 8 Afrihost, ZA 36903 718 361 144 MT-MPLS, MA 36992 678 1383 31 ETISALAT-MISR, EG 24835 515 850 15 RAYA-AS, EG 8452 502 1730 17 TE-AS TE-AS, EG 29571 434 36 10 CITelecom-AS, CI 37492 425 367 77 ORANGE-, TN 37342 355 32 1 MOVITEL, MZ 15399 349 35 7 WANANCHI-, KE 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 4538 5278 4192 76 ERX-CERNET-BKB China Education and Rese 7545 4060 410 408 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3547 537 307 Telmex Colombia S.A., CO 8151 3448 3424 583 Uninet S.A. de C.V., MX 39891 3387 186 23 ALJAWWALSTC-AS, SA 6327 3328 1323 86 SHAW - Shaw Communications Inc., CA 22773 3301 2952 156 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 20940 2845 851 2055 AKAMAI-ASN1, US 4766 2792 11128 756 KIXS-AS-KR Korea Telecom, KR 17974 2775 916 76 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 4060 3652 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3387 3364 ALJAWWALSTC-AS, SA 6327 3328 3242 SHAW - Shaw Communications Inc., CA 10620 3547 3240 Telmex Colombia S.A., CO 22773 3301 3145 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8151 3448 2865 Uninet S.A. de C.V., MX 17974 2775 2699 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 8551 2496 2454 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 2355 2314 Instituto Costarricense de Electricidad y Telec 9829 2759 2219 BSNL-NIB National Internet Backbone, IN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW 419333 UNALLOCATED 84.17.91.0/24 41933 IPRAGAZ-AS Istanbul/ TURKEY, T 64111 UNALLOCATED 98.159.5.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64111 UNALLOCATED 98.159.7.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64121 UNALLOCATED 98.159.9.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64111 UNALLOCATED 98.159.12.0/24 19555 KMI-NETWORK - Kinder Morgan, I 64140 UNALLOCATED 98.159.14.0/24 64121 UNKNOWN 64521 PRIVATE 103.193.197.0/24 133275 GIGANTIC-AS Gigantic Infotel P Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.12.0/22 55427 BROADLINK-AS-AP Broadlink Nepal, NP 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 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:15 /9:13 /10:36 /11:106 /12:285 /13:551 /14:1060 /15:1857 /16:13338 /17:7760 /18:13561 /19:25185 /20:38945 /21:43523 /22:81411 /23:66096 /24:373291 /25:841 /26:618 /27:650 /28:35 /29:21 /30:16 /31:2 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3122 3328 SHAW - Shaw Communications Inc., CA 39891 2946 3387 ALJAWWALSTC-AS, SA 22773 2538 3301 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2066 2171 MEGAPATH5-US - MegaPath Corporation, US 8551 1960 2496 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 11830 1725 2355 Instituto Costarricense de Electricidad y Telec 30036 1613 1845 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1539 3547 Telmex Colombia S.A., CO 11492 1479 1660 CABLEONE - CABLE ONE, INC., US 34984 1371 2063 TELLCOM-AS, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1571 2:838 4:18 5:2529 6:38 8:1071 9:1 12:1851 13:179 14:1734 15:29 16:3 17:184 18:76 20:52 21:1 23:2403 24:1935 25:2 27:2359 31:1949 32:87 35:21 36:440 37:2408 38:1468 39:76 40:99 41:3058 42:519 43:1902 44:80 45:3265 46:2805 47:183 49:1372 50:1034 51:28 52:898 54:354 55:3 56:4 57:42 58:1556 59:996 60:361 61:1993 62:1749 63:1840 64:4587 65:2246 66:4473 67:2318 68:1191 69:3181 70:1132 71:588 72:2102 74:2680 75:389 76:414 77:1521 78:1559 79:1923 80:1418 81:1404 82:1029 83:751 84:998 85:1958 86:471 87:1215 88:870 89:2300 90:173 91:6242 92:1027 93:2333 94:2405 95:2656 96:661 97:352 98:961 99:103 100:157 101:1534 102:1 103:16075 104:3183 105:213 106:564 107:1751 108:812 109:2913 110:1514 111:1731 112:1267 113:1343 114:1064 115:1604 116:1697 117:1639 118:2153 119:1628 120:759 121:1080 122:2421 123:1876 124:1485 125:1822 128:966 129:664 130:445 131:1519 132:605 133:193 134:860 135:229 136:443 137:482 138:1972 139:538 140:373 141:677 142:751 143:936 144:801 145:192 146:1127 147:700 148:1542 149:618 150:704 151:1002 152:725 153:299 154:934 155:744 156:728 157:747 158:600 159:1604 160:819 161:728 162:2536 163:518 164:919 165:1472 166:392 167:1349 168:3095 169:819 170:3565 171:398 172:1009 173:1886 174:816 175:753 176:1896 177:3957 178:2491 179:1152 180:2223 181:2101 182:2434 183:808 184:880 185:11495 186:3329 187:2296 188:2590 189:1897 190:8148 191:1304 192:9703 193:5867 194:4745 195:3970 196:2239 197:1416 198:5543 199:5875 200:7201 201:4668 202:10355 203:9941 204:4548 205:2871 206:3069 207:3096 208:3971 209:3881 210:3931 211:2060 212:2852 213:2588 214:853 215:63 216:5721 217:2118 218:877 219:598 220:1671 221:937 222:715 223:1172 End of report From jfmezei_nanog at vaxination.ca Fri Nov 17 19:45:32 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 17 Nov 2017 14:45:32 -0500 Subject: Broadcast television in an IP world Message-ID: Once ISPs became able to provide sufficient speeds to end users, video over the internet became a thing. This week, the FCC approved the ATSC3 standard. What if instead of moving to ATSC3, TV stations that broadcast OTA became OTT instead? Could the Internet handle the load? Since TV stations that are OTA are "local", wouldn't this create an instant CDN service for networks such as CBS/ABC/NBS/FOX/PBS since these networks have local presence and can feed ISPs locally? And while a small ISP serving Plattsburg NY would have no problem peering with the WPTZ server in Plattsburg, would the big guys like Comcast/Verizon be amenable to peering with TV stations in small markets? Some of them would also be selling transit to the TV station (for instance, to serve its Canadian audience, WPTZ would need transit to go outside of Comcast/Frontier and reach canadian IP networks). But a local TV station whose footprint is served by the local ISPs may not need any transit. The PAY TV servives, if HBO is any indication will also move OTT, but be served in the more traditional way, with a central feed of content going to a CDN which has presence that is local to large ISPs (or inside ISPs). We the traditional BDU (canada) MVPD (USA) is abandonned by the public and TV stations , PAY TV services and SVOD services such as Netflix are all on the Internet, would this represent a huge change in load, or just incremental growth, especially if local TV stations are served locally? Just curious to see if the current OTA and Cable distribution models will/could morph into IP based services, eliminating the "cable TV" service. From jay at west.net Fri Nov 17 21:18:23 2017 From: jay at west.net (Jay Hennigan) Date: Fri, 17 Nov 2017 13:18:23 -0800 Subject: Broadcast television in an IP world In-Reply-To: References: Message-ID: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> On 11/17/17 11:45 AM, Jean-Francois Mezei wrote: > > Once ISPs became able to provide sufficient speeds to end users, video > over the internet became a thing. > > This week, the FCC approved the ATSC3 standard. > > What if instead of moving to ATSC3, TV stations that broadcast OTA > became OTT instead? Could the Internet handle the load? Much live programming could be done without significant additional burden if the community could agree on multicast delivery standards. With YouTube's commercial offering on top of Netflix, Hulu, etc. and cable IPTV we're probably pretty close to the tipping point now. > Since TV stations that are OTA are "local", wouldn't this create an > instant CDN service for networks such as CBS/ABC/NBS/FOX/PBS since these > networks have local presence and can feed ISPs locally? > > And while a small ISP serving Plattsburg NY would have no problem > peering with the WPTZ server in Plattsburg, would the big guys like > Comcast/Verizon be amenable to peering with TV stations in small markets? This is already the case in many markets. It may not be IP peering, but there have been several recent instances where a broadcast TV transmitter is off the air due to some kind of failure and their cable feed keeps on chugging. Obviously there is some form of connection between the TV station and the cable company that doesn't rely on OTA. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From web at typo.org Fri Nov 17 21:25:51 2017 From: web at typo.org (Wayne Bouchard) Date: Fri, 17 Nov 2017 14:25:51 -0700 Subject: Broadcast television in an IP world In-Reply-To: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> Message-ID: <20171117212551.GA68074@spider.typo.org> > > And while a small ISP serving Plattsburg NY would have no problem > > peering with the WPTZ server in Plattsburg, would the big guys like > > Comcast/Verizon be amenable to peering with TV stations in small markets? > > This is already the case in many markets. It may not be IP peering, but > there have been several recent instances where a broadcast TV > transmitter is off the air due to some kind of failure and their cable > feed keeps on chugging. Obviously there is some form of connection > between the TV station and the cable company that doesn't rely on OTA. Hell, even STL links these days are often packet based. (It's often a lot simpler and cheaper than trying to operate a microwave feed.) So if you've already done the encoding, the OTA setup is simply one branch among several possible paths. -Wayne --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From lguillory at reservetele.com Fri Nov 17 21:37:14 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Fri, 17 Nov 2017 21:37:14 +0000 Subject: Broadcast television in an IP world In-Reply-To: References: Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> Have you seen what the OTA guys charge for retrans rights? They don't want to do this, I'd also bet their end game is to stop offering their feeds OTA in the end. Our retrans is going up 50% starting the 1st of the year which is just insane. I can also state that one of them specifically mentions alternative ways to receive their signals which I can assure you isn't related to quality. We have fiber to 1 OTA broadcaster, but also have to pay to get there since we're not near their studio. So while everyone is hell bent on blaming the cable companies for pricing, the only ones to blame are the programmers who continue to increase their rates. On top of that OTT is a pain requiring separate apps for every channel, awful buggy apps at that. Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jean-Francois Mezei Sent: Friday, November 17, 2017 1:46 PM To: Nanog at nanog.org Subject: Broadcast television in an IP world Once ISPs became able to provide sufficient speeds to end users, video over the internet became a thing. This week, the FCC approved the ATSC3 standard. What if instead of moving to ATSC3, TV stations that broadcast OTA became OTT instead? Could the Internet handle the load? Since TV stations that are OTA are "local", wouldn't this create an instant CDN service for networks such as CBS/ABC/NBS/FOX/PBS since these networks have local presence and can feed ISPs locally? And while a small ISP serving Plattsburg NY would have no problem peering with the WPTZ server in Plattsburg, would the big guys like Comcast/Verizon be amenable to peering with TV stations in small markets? Some of them would also be selling transit to the TV station (for instance, to serve its Canadian audience, WPTZ would need transit to go outside of Comcast/Frontier and reach canadian IP networks). But a local TV station whose footprint is served by the local ISPs may not need any transit. The PAY TV servives, if HBO is any indication will also move OTT, but be served in the more traditional way, with a central feed of content going to a CDN which has presence that is local to large ISPs (or inside ISPs). We the traditional BDU (canada) MVPD (USA) is abandonned by the public and TV stations , PAY TV services and SVOD services such as Netflix are all on the Internet, would this represent a huge change in load, or just incremental growth, especially if local TV stations are served locally? Just curious to see if the current OTA and Cable distribution models will/could morph into IP based services, eliminating the "cable TV" service. From jfmezei_nanog at vaxination.ca Fri Nov 17 22:27:36 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 17 Nov 2017 17:27:36 -0500 Subject: Broadcast television in an IP world In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> Message-ID: On 2017-11-17 16:37, Luke Guillory wrote: > Have you seen what the OTA guys charge for retrans rights? They don't want to do this, Fair point. Coming from Canada, OTA stations, because are freely available, can't charge distributors (BDUs (MVPDs in USA) so their revenues are purely from advertising. So that changes the equation. If going OTT allows them to shut down their OTA transmitters (and not pay for conversion to ATSC3) it could result in lower operating costs. In canada, BDU subsriptions are down and if the trend continues, NOT making programming available on the net means you miss the boat. In the USA, perhaps OTA stations could go to subscription model pn Internet to replace the MVPDs revenues and end retrans disputes.? From Daniel.Jameson at tdstelecom.com Fri Nov 17 22:45:59 2017 From: Daniel.Jameson at tdstelecom.com (Jameson, Daniel) Date: Fri, 17 Nov 2017 22:45:59 +0000 Subject: Broadcast television in an IP world In-Reply-To: References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> Message-ID: In the US certain channels have the *must Carry* designation. Which puts a retransmitter in a poor negotiating position, essentially the provider can charge whatever they want. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jean-Francois Mezei Sent: Friday, November 17, 2017 3:28 PM To: nanog at nanog.org Subject: Re: Broadcast television in an IP world On 2017-11-17 16:37, Luke Guillory wrote: > Have you seen what the OTA guys charge for retrans rights? They don't > want to do this, Fair point. Coming from Canada, OTA stations, because are freely available, can't charge distributors (BDUs (MVPDs in USA) so their revenues are purely from advertising. So that changes the equation. If going OTT allows them to shut down their OTA transmitters (and not pay for conversion to ATSC3) it could result in lower operating costs. In canada, BDU subsriptions are down and if the trend continues, NOT making programming available on the net means you miss the boat. In the USA, perhaps OTA stations could go to subscription model pn Internet to replace the MVPDs revenues and end retrans disputes.? From lguillory at reservetele.com Fri Nov 17 22:54:04 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Fri, 17 Nov 2017 22:54:04 +0000 Subject: Broadcast television in an IP world In-Reply-To: References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB382158@RTC-EXCH01.RESERVE.LDS> We have 1 channel out of 15 or so that's still a must carry, the others dropped that once they knew cable ops needed them so they went with the "well charge instead of requiring you to carry us" route. Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jameson, Daniel Sent: Friday, November 17, 2017 4:46 PM To: Jean-Francois Mezei; nanog at nanog.org Subject: RE: Broadcast television in an IP world In the US certain channels have the *must Carry* designation. Which puts a retransmitter in a poor negotiating position, essentially the provider can charge whatever they want. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jean-Francois Mezei Sent: Friday, November 17, 2017 3:28 PM To: nanog at nanog.org Subject: Re: Broadcast television in an IP world On 2017-11-17 16:37, Luke Guillory wrote: > Have you seen what the OTA guys charge for retrans rights? They don't > want to do this, Fair point. Coming from Canada, OTA stations, because are freely available, can't charge distributors (BDUs (MVPDs in USA) so their revenues are purely from advertising. So that changes the equation. If going OTT allows them to shut down their OTA transmitters (and not pay for conversion to ATSC3) it could result in lower operating costs. In canada, BDU subsriptions are down and if the trend continues, NOT making programming available on the net means you miss the boat. In the USA, perhaps OTA stations could go to subscription model pn Internet to replace the MVPDs revenues and end retrans disputes.? From lguillory at reservetele.com Fri Nov 17 23:01:34 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Fri, 17 Nov 2017 23:01:34 +0000 Subject: Broadcast television in an IP world In-Reply-To: References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38223A@RTC-EXCH01.RESERVE.LDS> This use to be the case. While it might lower OPX that surely won't result in lower retrans, will just be more profit for them. We're down as well on video subs, this is 99% due to rising prices. This is where it's heading for sure, in the end it will cost more as well since each will be charging more than the per sub rates we're getting charge. They'll have to in order to keep revenue the same. When ESPN offers an OTT product I have no doubt it will be near the $20 per month, for 5 channels or so? Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . From ag4ve.us at gmail.com Fri Nov 17 23:56:38 2017 From: ag4ve.us at gmail.com (shawn wilson) Date: Fri, 17 Nov 2017 18:56:38 -0500 Subject: Broadcast television in an IP world In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38223A@RTC-EXCH01.RESERVE.LDS> References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38223A@RTC-EXCH01.RESERVE.LDS> Message-ID: Besides Netflix, does anyone else offer CDN boxes for their services? I'm also guessing that most content won't benefit from multicast to homes too much? I can see where multicast benefits sports and news (and probably catching commercials for people). But in a world where I'm more than happy to pay Amazon $25-40 a show/season to avoid commercials, I'm guessing live/broadcast TV will get even less popular (I get news via YouTube - so that's not even live for me anymore). On Nov 17, 2017 18:03, "Luke Guillory" wrote: > This use to be the case. > > While it might lower OPX that surely won't result in lower retrans, will > just be more profit for them. > > We're down as well on video subs, this is 99% due to rising prices. > > This is where it's heading for sure, in the end it will cost more as well > since each will be charging more than the per sub rates we're getting > charge. They'll have to in order to keep revenue the same. > > When ESPN offers an OTT product I have no doubt it will be near the $20 > per month, for 5 channels or so? > > > > Luke Guillory > Vice President – Technology and Innovation > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > ____________________________________________________________ > _____________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by e-mail > if you have received this e-mail by mistake and delete this e-mail from > your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Luke Guillory therefore does > not accept liability for any errors or omissions in the contents of this > message, which arise as a result of e-mail transmission. . > > From lguillory at reservetele.com Sat Nov 18 00:09:18 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Sat, 18 Nov 2017 00:09:18 +0000 Subject: Broadcast television in an IP world In-Reply-To: References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38223A@RTC-EXCH01.RESERVE.LDS>, Message-ID: Google, Akamai and others. Sent from my iPhone On Nov 17, 2017, at 5:56 PM, shawn wilson > wrote: Besides Netflix, does anyone else offer CDN boxes for their services? I'm also guessing that most content won't benefit from multicast to homes too much? I can see where multicast benefits sports and news (and probably catching commercials for people). But in a world where I'm more than happy to pay Amazon $25-40 a show/season to avoid commercials, I'm guessing live/broadcast TV will get even less popular (I get news via YouTube - so that's not even live for me anymore). Luke Guillory Vice President – Technology and Innovation [cid:image77289b.JPG at 8baeeba3.43aacb76] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. On Nov 17, 2017 18:03, "Luke Guillory" > wrote: This use to be the case. While it might lower OPX that surely won't result in lower retrans, will just be more profit for them. We're down as well on video subs, this is 99% due to rising prices. This is where it's heading for sure, in the end it will cost more as well since each will be charging more than the per sub rates we're getting charge. They'll have to in order to keep revenue the same. When ESPN offers an OTT product I have no doubt it will be near the $20 per month, for 5 channels or so? Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . From baldur.norddahl at gmail.com Sat Nov 18 00:48:08 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 18 Nov 2017 01:48:08 +0100 Subject: Broadcast television in an IP world In-Reply-To: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> Message-ID: > Much live programming could be done without significant additional burden if the community could agree on multicast delivery standards. Does multicast have any future? Netflix, YouTube, et al does not use it. People want instant replay and a catalogue to select from. Except for sport events, live TV has no advantage so why even try to optimize for it? From lguillory at reservetele.com Sat Nov 18 00:51:25 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Sat, 18 Nov 2017 00:51:25 +0000 Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net>, Message-ID: <5C53350D-1044-4475-8723-CBCD3C3527E9@reservetele.com> Because local OTA channels are probably most of what people want live outside of sporting events. Sent from my iPad On Nov 17, 2017, at 6:49 PM, Baldur Norddahl > wrote: Much live programming could be done without significant additional burden if the community could agree on multicast delivery standards. Does multicast have any future? Netflix, YouTube, et al does not use it. People want instant replay and a catalogue to select from. Except for sport events, live TV has no advantage so why even try to optimize for it? Luke Guillory Vice President – Technology and Innovation [cid:image4d387c.JPG at 67228580.4c8bfb6f] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From jfmezei_nanog at vaxination.ca Sat Nov 18 02:03:52 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Fri, 17 Nov 2017 21:03:52 -0500 Subject: Broadcast television in an IP world In-Reply-To: References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38223A@RTC-EXCH01.RESERVE.LDS> Message-ID: <12051e2f-1637-68da-d200-1335e8b856f9@vaxination.ca> On 2017-11-17 18:56, shawn wilson wrote: > Besides Netflix, does anyone else offer CDN boxes for their services? This is where local TV stations are different as they are already present in the market they serve. They can connect locally, transit-free to the local ISPs. (and buy transit only for those outside of the local ISP's footprint). Of course, when CBS sells rights to a local TV station based on its antenna footprint, going OTT changes that as it allows a Burlington VT station to serve people in California in another affiliate's exclusive territory for that network. Which is why the TV stations might require "working" geolocation to be able to serve a Comcast customer in Burlington VT but not a Comcast customer in Wilmington Delaware (assuming COmcast serves both for sake of discussion). Without this, we'll see CBS offer a nationwide SVOD service (oh wait, they already do), and leave local TV station to have web based newscasts since other programming will be through CBS All Access (which, being a national service uses CDN services to get near to people). Either way, I see TV content moving to the web which means the numebvr of hours currently spent watching via OTA or Cable are moving to IP networks. An IPTV service such as Bell's already pushes that "cable TV" content through its last mile IP infrastructure, so the main difference is loss of multicast when programming originates outside the "BDU/MVPD" environment. But with more and more people watching TV "on demand", the advantages of multicast dimisnish (except for sports) because mroe a d more programmin is watched withg unicast, at which point no different from Netflix, Youtube etc. From jay at west.net Sat Nov 18 02:45:13 2017 From: jay at west.net (Jay Hennigan) Date: Fri, 17 Nov 2017 18:45:13 -0800 Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> Message-ID: <53a34787-5437-8069-80ec-e1eaa0d6fc85@west.net> On 11/17/17 4:48 PM, Baldur Norddahl wrote: >> > Much live programming could be done without significant additional burden > if the community could agree on multicast delivery standards. > > > > > Does multicast have any future? Netflix, YouTube, et al does not use it. > People want instant replay and a catalogue to select from. Except for sport > events, live TV has no advantage so why even try to optimize for it? It does for delivering live content. Local programming, news, sports, C-SPAN, etc. Canned program content such as TV series, not so much. On-demand not at all. -- -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From lists.nanog at monmotha.net Sat Nov 18 02:54:38 2017 From: lists.nanog at monmotha.net (Brandon Martin) Date: Fri, 17 Nov 2017 21:54:38 -0500 Subject: Broadcast television in an IP world In-Reply-To: <53a34787-5437-8069-80ec-e1eaa0d6fc85@west.net> References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> <53a34787-5437-8069-80ec-e1eaa0d6fc85@west.net> Message-ID: On 11/17/2017 09:45 PM, Jay Hennigan wrote: >> Does multicast have any future? Netflix, YouTube, et al does not use it. >> People want instant replay and a catalogue to select from. Except for >> sport >> events, live TV has no advantage so why even try to optimize for it? > > It does for delivering live content. Local programming, news, sports, > C-SPAN, etc. Canned program content such as TV series, not so much. > On-demand not at all. > > I can think of a few other good uses (semi- to non-topical): 1. Multi-party video conferencing. Audio is applicable, too, but the bandwidth requirements are low enough you can just unicast it all. 2. Platform upgrades for extremely popular consumer devices. Think a rolling multicast stream at a few bitrates for e.g. the latest iOS, Windows, flagship Android handset, etc. upgrades. This might or might not work better than CDN'ing the bejeezus out of it depending on your network topology. -- Brandon Martin From kburke at burlingtontelecom.com Sat Nov 18 03:26:50 2017 From: kburke at burlingtontelecom.com (Kevin Burke) Date: Sat, 18 Nov 2017 03:26:50 +0000 Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> Message-ID: >Does multicast have any future? Nope. We have a couple of gigs of multicast traffic on our network. Its pretty easy. You can't pay me enough to troubleshoot multicast between different ISP's. Multicast network look different from the Internet. One would have to change. On top of that any packet loss is a show stopper. It has no facility for retransmission. Multicast is good because its not much load on the routers. Even thinking about pushing it over WiFi makes me jump right to a server with a TCP stack or similar. So those NetFlix servers seem about as good a long term strategy as any. Save the loud fans. Video is just another application. From jay at west.net Sat Nov 18 04:01:15 2017 From: jay at west.net (Jay Hennigan) Date: Fri, 17 Nov 2017 20:01:15 -0800 Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> Message-ID: <31c64b5a-53f3-95a4-65af-e2172a3a5118@west.net> On 11/17/17 7:26 PM, Kevin Burke wrote: > Multicast network look different from the Internet. One would have to change. On top of that any packet loss is a show stopper. It has no facility for retransmission. For live streaming video, you mask the loss and keep on chugging just like you do with VoIP. The same thing happens with OTA with signal fading or a burst of RF noise or interference. The OTA broadcast transmitter doesn't retransmit when one or more receivers lose data. If the endgame is to replace OTA live TV with a packet based solution, IMHO there's a place for multicast. It's basically the same model as OTA, one transmitter and many receivers. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From jayfar at jayfar.com Sat Nov 18 07:55:59 2017 From: jayfar at jayfar.com (Jay Farrell) Date: Sat, 18 Nov 2017 02:55:59 -0500 Subject: Broadcast television in an IP world In-Reply-To: References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> Message-ID: On Fri, Nov 17, 2017 at 5:45 PM, Jameson, Daniel < Daniel.Jameson at tdstelecom.com> wrote: > In the US certain channels have the *must Carry* designation. Which puts > a retransmitter in a poor negotiating position, essentially the provider > can charge whatever they want. Under must-carry a station cannot charge the cable companies a fee. But the station can waive must-carry and then can negotiate fees. The cable company can decline to carry under those circumstances, if they don't want to pay the fee. From baldur.norddahl at gmail.com Sat Nov 18 13:17:30 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Sat, 18 Nov 2017 14:17:30 +0100 Subject: Broadcast television in an IP world In-Reply-To: <53a34787-5437-8069-80ec-e1eaa0d6fc85@west.net> References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> <53a34787-5437-8069-80ec-e1eaa0d6fc85@west.net> Message-ID: > It does for delivering live content. Local programming, news, sports, C-SPAN, etc. Canned program content such as TV series, not so much. On-demand not at all. Our network carries a lot of streaming content. We have no multicast because we offer no TV. But the customers will occasionally stream live TV directly from broadcasters. Why would I implement multicast? Does it even save me any money when the network has to be dimensioned to handle a day with no major live event with everyone just doing the usual streaming? A person watching live TV is usually not watching on demand at the same time. The same argument goes for the broadcasters. They need a CDN that will handle peak load at a time were most are watching on demand. The same CDN server can handle the times were most viewers are watching live TV. Right now we probably have TV broadcasters that only do live TV. I do not see that as being the future. And in any case I would not front the bill for them by implementing multicast in my network just so they can save a little on the CDN. From kraig at enguity.com Sat Nov 18 14:13:31 2017 From: kraig at enguity.com (Kraig Beahn) Date: Sat, 18 Nov 2017 09:13:31 -0500 Subject: Broadcast television in an IP world In-Reply-To: <5C53350D-1044-4475-8723-CBCD3C3527E9@reservetele.com> References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> <5C53350D-1044-4475-8723-CBCD3C3527E9@reservetele.com> Message-ID: The OTT side is already being implemented by a major broadcast customer of ours. Right now they simply rebroadcast their news, both live and prerecorded, i'm assuming until the national networks and syndicators will allow reasonable OTT licensing fee's. They use a product called SyncBak (for which they've also invested in heavily) and offer the streams for all of their market stations nationwide. You can in turn use a Roku or Roku like STB to ascertain the feed, live and in HD at that. We currently provide the fiber and peering facilities, and are intimately familiar with the network and video production side. Very neat product, at that... IP translator and MPEG network side: http://www.syncbak.com Example station: https://channelstore.roku.com/details/47424/wctv On Nov 17, 2017 7:53 PM, "Luke Guillory" wrote: > Because local OTA channels are probably most of what people want live > outside of sporting events. > > > > Sent from my iPad > > On Nov 17, 2017, at 6:49 PM, Baldur Norddahl mailto:baldur.norddahl at gmail.com>> wrote: > > > Much live programming could be done without significant additional burden > if the community could agree on multicast delivery standards. > > > > > Does multicast have any future? Netflix, YouTube, et al does not use it. > People want instant replay and a catalogue to select from. Except for sport > events, live TV has no advantage so why even try to optimize for it? > > > > > Luke Guillory > Vice President – Technology and Innovation > > > [cid:image4d387c.JPG at 67228580.4c8bfb6f] > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > Web: www.rtconline.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > > > > > Disclaimer: > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by e-mail > if you have received this e-mail by mistake and delete this e-mail from > your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Luke Guillory therefore does > not accept liability for any errors or omissions in the contents of this > message, which arise as a result of e-mail transmission. > > From kmedcalf at dessus.com Sat Nov 18 16:03:52 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 18 Nov 2017 09:03:52 -0700 Subject: Broadcast television in an IP world In-Reply-To: Message-ID: Looks OK on my old 12" 240i interlace CRT. However, it is not High Definition. Like everything on the Roku it is CATRS (Compressed All To Rat Shit) and motion decimated and unsuitable for display on anything bigger/more modern than a 12 240i CRT circa 1980 or so, and certainly completely unwatchable on a 80" 1080p display. And one cannot look at that SyncBak page unless one disables security and permits unwashed code free reign to execute willy nilly on the local computer. I do not have the time nor inclination to security audit their code, so there is nothing to be seen from them. This means on a balance of probabilities that they are nothing more than snake-oil salesmen. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kraig Beahn >Sent: Saturday, 18 November, 2017 07:14 >To: Luke Guillory >Cc: NANOG list >Subject: Re: Broadcast television in an IP world > >The OTT side is already being implemented by a major broadcast >customer of >ours. > >Right now they simply rebroadcast their news, both live and >prerecorded, >i'm assuming until the national networks and syndicators will allow >reasonable OTT licensing fee's. > >They use a product called SyncBak (for which they've also invested in >heavily) and offer the streams for all of their market stations >nationwide. >You can in turn use a Roku or Roku like STB to ascertain the feed, >live and >in HD at that. > >We currently provide the fiber and peering facilities, and are >intimately >familiar with the network and video production side. > >Very neat product, at that... > >IP translator and MPEG network side: >http://www.syncbak.com > >Example station: https://channelstore.roku.com/details/47424/wctv > > > > >On Nov 17, 2017 7:53 PM, "Luke Guillory" >wrote: > >> Because local OTA channels are probably most of what people want >live >> outside of sporting events. >> >> >> >> Sent from my iPad >> >> On Nov 17, 2017, at 6:49 PM, Baldur Norddahl >> mailto:baldur.norddahl at gmail.com>> wrote: >> >> >> Much live programming could be done without significant additional >burden >> if the community could agree on multicast delivery standards. >> >> >> >> >> Does multicast have any future? Netflix, YouTube, et al does not >use it. >> People want instant replay and a catalogue to select from. Except >for sport >> events, live TV has no advantage so why even try to optimize for >it? >> >> >> >> >> Luke Guillory >> Vice President – Technology and Innovation >> >> >> [cid:image4d387c.JPG at 67228580.4c8bfb6f] > >> >> Tel: 985.536.1212 >> Fax: 985.536.0300 >> Email: lguillory at reservetele.com >> Web: www.rtconline.com >> >> Reserve Telecommunications >> 100 RTC Dr >> Reserve, LA 70084 >> >> >> >> >> >> Disclaimer: >> The information transmitted, including attachments, is intended >only for >> the person(s) or entity to which it is addressed and may contain >> confidential and/or privileged material which should not >disseminate, >> distribute or be copied. Please notify Luke Guillory immediately by >e-mail >> if you have received this e-mail by mistake and delete this e-mail >from >> your system. E-mail transmission cannot be guaranteed to be secure >or >> error-free as information could be intercepted, corrupted, lost, >destroyed, >> arrive late or incomplete, or contain viruses. Luke Guillory >therefore does >> not accept liability for any errors or omissions in the contents of >this >> message, which arise as a result of e-mail transmission. >> >> From kraig at enguity.com Sat Nov 18 16:59:28 2017 From: kraig at enguity.com (Kraig Beahn) Date: Sat, 18 Nov 2017 11:59:28 -0500 Subject: Broadcast television in an IP world In-Reply-To: References: Message-ID: I wanted to note that, in no way shape or form was my previous message a vendor or technology recommendation, nor do we have any direct or indirect financial ties to either party, except that we provide the DIA fiber trunk to pass the live video content from the studio to the GDM peering point. At that point, it is GDM's responsibility to push the same traffic towards the CDN aggregator or their choosing. My message was simply an indication that portions of the broadcast industry have recognized OTT as part of their future, regardless of how its deployed, under what conditions or technological methods. On Keith's note, I wont disagree with his response, except to note that it does take at least 45Mb/s upon launching the channel, at peak, then settles down to 12-25Mb/s for simple HD news content. Not sure which CDN they are using but can find out, if you'd like to test further. I am confident that they do not have Canada in their CDN mix. On Nov 18, 2017 11:03 AM, "Keith Medcalf" wrote: > > Looks OK on my old 12" 240i interlace CRT. However, it is not High > Definition. Like everything on the Roku it is CATRS (Compressed All To Rat > Shit) and motion decimated and unsuitable for display on anything > bigger/more modern than a 12 240i CRT circa 1980 or so, and certainly > completely unwatchable on a 80" 1080p display. > > And one cannot look at that SyncBak page unless one disables security and > permits unwashed code free reign to execute willy nilly on the local > computer. I do not have the time nor inclination to security audit their > code, so there is nothing to be seen from them. This means on a balance of > probabilities that they are nothing more than snake-oil salesmen. > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven says > a lot about anticipated traffic volume. > > > >-----Original Message----- > >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Kraig Beahn > >Sent: Saturday, 18 November, 2017 07:14 > >To: Luke Guillory > >Cc: NANOG list > >Subject: Re: Broadcast television in an IP world > > > >The OTT side is already being implemented by a major broadcast > >customer of > >ours. > > > >Right now they simply rebroadcast their news, both live and > >prerecorded, > >i'm assuming until the national networks and syndicators will allow > >reasonable OTT licensing fee's. > > > >They use a product called SyncBak (for which they've also invested in > >heavily) and offer the streams for all of their market stations > >nationwide. > >You can in turn use a Roku or Roku like STB to ascertain the feed, > >live and > >in HD at that. > > > >We currently provide the fiber and peering facilities, and are > >intimately > >familiar with the network and video production side. > > > >Very neat product, at that... > > > >IP translator and MPEG network side: > >http://www.syncbak.com > > > >Example station: https://channelstore.roku.com/details/47424/wctv > > > > > > > > > >On Nov 17, 2017 7:53 PM, "Luke Guillory" > >wrote: > > > >> Because local OTA channels are probably most of what people want > >live > >> outside of sporting events. > >> > >> > >> > >> Sent from my iPad > >> > >> On Nov 17, 2017, at 6:49 PM, Baldur Norddahl > > >> mailto:baldur.norddahl at gmail.com>> wrote: > >> > >> > >> Much live programming could be done without significant additional > >burden > >> if the community could agree on multicast delivery standards. > >> > >> > >> > >> > >> Does multicast have any future? Netflix, YouTube, et al does not > >use it. > >> People want instant replay and a catalogue to select from. Except > >for sport > >> events, live TV has no advantage so why even try to optimize for > >it? > >> > >> > >> > >> > >> Luke Guillory > >> Vice President – Technology and Innovation > >> > >> > >> [cid:image4d387c.JPG at 67228580.4c8bfb6f] > > > >> > >> Tel: 985.536.1212 > >> Fax: 985.536.0300 > >> Email: lguillory at reservetele.com > >> Web: www.rtconline.com > >> > >> Reserve Telecommunications > >> 100 RTC Dr > >> Reserve, LA 70084 > >> > >> > >> > >> > >> > >> Disclaimer: > >> The information transmitted, including attachments, is intended > >only for > >> the person(s) or entity to which it is addressed and may contain > >> confidential and/or privileged material which should not > >disseminate, > >> distribute or be copied. Please notify Luke Guillory immediately by > >e-mail > >> if you have received this e-mail by mistake and delete this e-mail > >from > >> your system. E-mail transmission cannot be guaranteed to be secure > >or > >> error-free as information could be intercepted, corrupted, lost, > >destroyed, > >> arrive late or incomplete, or contain viruses. Luke Guillory > >therefore does > >> not accept liability for any errors or omissions in the contents of > >this > >> message, which arise as a result of e-mail transmission. > >> > >> > > > > From mike.lyon at gmail.com Sun Nov 19 01:55:49 2017 From: mike.lyon at gmail.com (mike.lyon at gmail.com) Date: Sat, 18 Nov 2017 17:55:49 -0800 Subject: Commodity routers/switches Message-ID: <8C5DE76F-211B-45B4-8680-936119F1E49C@gmail.com> Howdy! Looking to replace some edge routers for my small ISP. With all the various SDN platforms available along with various choices of bare-metal hardware platforms, im thinking i may go this route instead of going with Cisco/Juniper/Etc. I only need a handful of 10G uplinks. The SuperMicro SSE-G3648B and the Penguin Arctica Network switches appear to fit my needs. I am eyeing Cumulus Linux to run on these, but that isn’t set in stone. They’ll likely be getting 2 full tables along with some peers. Has anyone run SuperMicro or Penguin hardware with Cumulus in this type of scenario? What were your experiences? How is BGP convergence time on x86 hardware these days? Any insight would be appreciated. Thank You, Mike From joelja at bogus.com Sun Nov 19 03:02:50 2017 From: joelja at bogus.com (joel jaeggli) Date: Sat, 18 Nov 2017 19:02:50 -0800 Subject: Commodity routers/switches In-Reply-To: <8C5DE76F-211B-45B4-8680-936119F1E49C@gmail.com> References: <8C5DE76F-211B-45B4-8680-936119F1E49C@gmail.com> Message-ID: <3fcd299f-ae91-4bb4-d562-3e86ab2170de@bogus.com> On 11/18/17 17:55, mike.lyon at gmail.com wrote: > Howdy! > > Looking to replace some edge routers for my small ISP. With all the various SDN platforms available along with various choices of bare-metal hardware platforms, im thinking i may go this route instead of going with Cisco/Juniper/Etc. > > I only need a handful of 10G uplinks. The SuperMicro SSE-G3648B and the Penguin Arctica Network switches appear to fit my needs. > > I am eyeing Cumulus Linux to run on these, but that isn’t set in stone. > > They’ll likely be getting 2 full tables along with some peers. afaik if these are consistent with other t2/tomahawk/helix switches they're roughly 200K alpm routes installed or as few as 16K. if you install selected routes and otherwise default  or this is a peering only router, that can get you pretty far but it's not a full table by any means. https://docs.cumulusnetworks.com/display/DOCS/Routing (cumulous details on route table size and alpm routes) > Has anyone run SuperMicro or Penguin hardware with Cumulus in this type of scenario? > > What were your experiences? How is BGP convergence time on x86 hardware these days? control plane on the switches mentioned about is 2GB of ram and a dual core atom, so it's fine more or less for a datacenter TOR. It's not particularly powerful. I find out particular tooling doesn't run that well in 4GB any more so your milage may vary. the supermicro should bear a striking  resemblance to the dell 3048 that was splayed open here http://eoinpk.blogspot.com/2015/08/under-hood-of-dell-s3048-on.html > > Any insight would be appreciated. > > Thank You, > Mike > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: OpenPGP digital signature URL: From web at typo.org Sun Nov 19 04:25:58 2017 From: web at typo.org (Wayne Bouchard) Date: Sat, 18 Nov 2017 21:25:58 -0700 Subject: Broadcast television in an IP world In-Reply-To: References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38223A@RTC-EXCH01.RESERVE.LDS> Message-ID: <20171119042558.GA73649@spider.typo.org> Where the content is increasingly becoming on-demand, no, multicast isn't going to benefit folks that much. The delivery is going to pretty much remain single-stream based strictly on the time differential from one user's start point to the next even if they are both watching the same episode. So local broadcasters can benefit, yes, but the problem is that content consumption is moving rapidly away from the schedule-based paradigm. On Fri, Nov 17, 2017 at 06:56:38PM -0500, shawn wilson wrote: > Besides Netflix, does anyone else offer CDN boxes for their services? > > I'm also guessing that most content won't benefit from multicast to homes > too much? > > I can see where multicast benefits sports and news (and probably catching > commercials for people). But in a world where I'm more than happy to pay > Amazon $25-40 a show/season to avoid commercials, I'm guessing > live/broadcast TV will get even less popular (I get news via YouTube - so > that's not even live for me anymore). > > On Nov 17, 2017 18:03, "Luke Guillory" wrote: > > > This use to be the case. > > > > While it might lower OPX that surely won't result in lower retrans, will > > just be more profit for them. > > > > We're down as well on video subs, this is 99% due to rising prices. > > > > This is where it's heading for sure, in the end it will cost more as well > > since each will be charging more than the per sub rates we're getting > > charge. They'll have to in order to keep revenue the same. > > > > When ESPN offers an OTT product I have no doubt it will be near the $20 > > per month, for 5 channels or so? > > > > > > > > Luke Guillory > > Vice President ??? Technology and Innovation > > > > Tel: 985.536.1212 > > Fax: 985.536.0300 > > Email: lguillory at reservetele.com > > > > Reserve Telecommunications > > 100 RTC Dr > > Reserve, LA 70084 > > > > ____________________________________________________________ > > _____________________________________ > > > > Disclaimer: > > The information transmitted, including attachments, is intended only for > > the person(s) or entity to which it is addressed and may contain > > confidential and/or privileged material which should not disseminate, > > distribute or be copied. Please notify Luke Guillory immediately by e-mail > > if you have received this e-mail by mistake and delete this e-mail from > > your system. E-mail transmission cannot be guaranteed to be secure or > > error-free as information could be intercepted, corrupted, lost, destroyed, > > arrive late or incomplete, or contain viruses. Luke Guillory therefore does > > not accept liability for any errors or omissions in the contents of this > > message, which arise as a result of e-mail transmission. . > > > > --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From hugge at nordu.net Sun Nov 19 07:46:53 2017 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Sun, 19 Nov 2017 08:46:53 +0100 Subject: Commodity routers/switches In-Reply-To: <8C5DE76F-211B-45B4-8680-936119F1E49C@gmail.com> References: <8C5DE76F-211B-45B4-8680-936119F1E49C@gmail.com> Message-ID: <3607ab13-6ca9-faa5-5038-f3dd71516b76@nordu.net> On 2017-11-19 02:55, mike.lyon at gmail.com wrote: > Howdy! > > Looking to replace some edge routers for my small ISP. With all the various SDN platforms available along with various choices of bare-metal hardware platforms, im thinking i may go this route instead of going with Cisco/Juniper/Etc. > > I only need a handful of 10G uplinks. The SuperMicro SSE-G3648B and the Penguin Arctica Network switches appear to fit my needs. > > I am eyeing Cumulus Linux to run on these, but that isn’t set in stone. > > They’ll likely be getting 2 full tables along with some peers. > > Has anyone run SuperMicro or Penguin hardware with Cumulus in this type of scenario? > > What were your experiences? How is BGP convergence time on x86 hardware these days? > > Any insight would be appreciated. > > Thank You, > Mike > Replacing a edge-router with a switch is nothing new, however make sure you actually replace it with the correct one. The Supermicro looks like any generic Helix4-switch and is a ToR-switch for the datacenter. Its not very fitting for edge-routing. It does not have buffers at all and would make your sub-speed connections perform like shit, and also it has a tiny LPM table so you wont be able to fit anywhere near a full table in there It seems that you want a cost-effective 1G solution given that you linked SSE-G3648B? Merchant-switch silicon and edge-routing isn't very competitive on 1G/10G, both because traditional legacy-routers is somewhat cheap for 1G applications and also that 1G is virtually non-existant in datacenter enviroments these days so its hard to leverage the economy-of-scale from there on these swithces. Look at Nokias portfolio for 1G/10G routers, they still care in that segment and is in Europe a very popular choice for broadband buildouts, as is Huaweis smaller NetEngines but that might not fly that well in the US. Juniper MX150 might also work depending on how much 1G you need, but you likely need more. If you bump it up a notch to 10G/100G or 100G only the market for routing-merchant-silicon looks much better. I guess the most famous platform is the Arista 7280R that was the first Broadcom-based box that accepted 1M routes, had big buffers and didnt cost the equivalent of a bunch of new cars for a 1Tbit of capacity like J/C/N/H would charge you for a equivalent linecard to their edge-portfolios. Cisco quickly released NCS550 productline as an answer, Huawei released CE6870-line (but didnt do the LEM/LPM hack that C/A did for full tables to protect NetEngine BU), Juniper pushes QFX10K which is somewhat equal to a Broadcom Jericho-based box. The only Whitebox-vendor i know off that actually has a Jericho (qumran) based box is Agema with the AGC7648S, not sure which stand-alone NOS that actually supports this box fully. Now Jericho+ is also out and Jericho2 is around the corner so i guess we will see alot bigger and even more competetive switch-routers based on these chips. But it doesent really help much if you are operating in 1G/10G space. -- hugge From nanog at ics-il.net Sun Nov 19 15:36:23 2017 From: nanog at ics-il.net (Mike Hammett) Date: Sun, 19 Nov 2017 09:36:23 -0600 (CST) Subject: Commodity routers/switches In-Reply-To: <3607ab13-6ca9-faa5-5038-f3dd71516b76@nordu.net> References: <8C5DE76F-211B-45B4-8680-936119F1E49C@gmail.com> <3607ab13-6ca9-faa5-5038-f3dd71516b76@nordu.net> Message-ID: <49054322.1749.1511105781907.JavaMail.mhammett@ThunderFuck> Which is sad because I believe there are a ton of people using old gear (lacking modern features and security) because the old gear meets price and performance requirements. Although obviously much smaller networks (and thus potential with each one), it's easy to say there are more 1G\10G ISPs than there are 100G ISPs. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Fredrik Korsbäck" To: nanog at nanog.org Sent: Sunday, November 19, 2017 1:46:53 AM Subject: Re: Commodity routers/switches On 2017-11-19 02:55, mike.lyon at gmail.com wrote: > Howdy! > > Looking to replace some edge routers for my small ISP. With all the various SDN platforms available along with various choices of bare-metal hardware platforms, im thinking i may go this route instead of going with Cisco/Juniper/Etc. > > I only need a handful of 10G uplinks. The SuperMicro SSE-G3648B and the Penguin Arctica Network switches appear to fit my needs. > > I am eyeing Cumulus Linux to run on these, but that isn’t set in stone. > > They’ll likely be getting 2 full tables along with some peers. > > Has anyone run SuperMicro or Penguin hardware with Cumulus in this type of scenario? > > What were your experiences? How is BGP convergence time on x86 hardware these days? > > Any insight would be appreciated. > > Thank You, > Mike > Replacing a edge-router with a switch is nothing new, however make sure you actually replace it with the correct one. The Supermicro looks like any generic Helix4-switch and is a ToR-switch for the datacenter. Its not very fitting for edge-routing. It does not have buffers at all and would make your sub-speed connections perform like shit, and also it has a tiny LPM table so you wont be able to fit anywhere near a full table in there It seems that you want a cost-effective 1G solution given that you linked SSE-G3648B? Merchant-switch silicon and edge-routing isn't very competitive on 1G/10G, both because traditional legacy-routers is somewhat cheap for 1G applications and also that 1G is virtually non-existant in datacenter enviroments these days so its hard to leverage the economy-of-scale from there on these swithces. Look at Nokias portfolio for 1G/10G routers, they still care in that segment and is in Europe a very popular choice for broadband buildouts, as is Huaweis smaller NetEngines but that might not fly that well in the US. Juniper MX150 might also work depending on how much 1G you need, but you likely need more. If you bump it up a notch to 10G/100G or 100G only the market for routing-merchant-silicon looks much better. I guess the most famous platform is the Arista 7280R that was the first Broadcom-based box that accepted 1M routes, had big buffers and didnt cost the equivalent of a bunch of new cars for a 1Tbit of capacity like J/C/N/H would charge you for a equivalent linecard to their edge-portfolios. Cisco quickly released NCS550 productline as an answer, Huawei released CE6870-line (but didnt do the LEM/LPM hack that C/A did for full tables to protect NetEngine BU), Juniper pushes QFX10K which is somewhat equal to a Broadcom Jericho-based box. The only Whitebox-vendor i know off that actually has a Jericho (qumran) based box is Agema with the AGC7648S, not sure which stand-alone NOS that actually supports this box fully. Now Jericho+ is also out and Jericho2 is around the corner so i guess we will see alot bigger and even more competetive switch-routers based on these chips. But it doesent really help much if you are operating in 1G/10G space. -- hugge From Matthew.Black at csulb.edu Mon Nov 20 15:11:18 2017 From: Matthew.Black at csulb.edu (Matthew Black) Date: Mon, 20 Nov 2017 15:11:18 +0000 Subject: Broadcast television in an IP world In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38223A@RTC-EXCH01.RESERVE.LDS> References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38223A@RTC-EXCH01.RESERVE.LDS> Message-ID: Right now only 25% of cable subscribers watch sports channels like ESPN. But 100% pay up to $20 a month for ESPN et al. in their monthly subscription fees. HBO and Showtime subscribers pay for those premium services. It is well past time for sports enthusiasts to pay for their very expensive content in a sports premium package. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Luke Guillory Sent: Friday, November 17, 2017 3:02 PM To: Jean-Francois Mezei; nanog at nanog.org Subject: RE: Broadcast television in an IP world This use to be the case. While it might lower OPX that surely won't result in lower retrans, will just be more profit for them. We're down as well on video subs, this is 99% due to rising prices. This is where it's heading for sure, in the end it will cost more as well since each will be charging more than the per sub rates we're getting charge. They'll have to in order to keep revenue the same. When ESPN offers an OTT product I have no doubt it will be near the $20 per month, for 5 channels or so? Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . From lguillory at reservetele.com Mon Nov 20 16:09:40 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 20 Nov 2017 16:09:40 +0000 Subject: Broadcast television in an IP world In-Reply-To: References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38223A@RTC-EXCH01.RESERVE.LDS> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38741E@RTC-EXCH01.RESERVE.LDS> ESPN's programing fees aren't anywhere near $20 a month, they're not even $10 a month. HBO on the other hand is pretty much what the end user pays in terms of programing cost. -----Original Message----- From: Matthew Black [mailto:Matthew.Black at csulb.edu] Sent: Monday, November 20, 2017 9:11 AM To: Luke Guillory; nanog at nanog.org Subject: RE: Broadcast television in an IP world Right now only 25% of cable subscribers watch sports channels like ESPN. But 100% pay up to $20 a month for ESPN et al. in their monthly subscription fees. HBO and Showtime subscribers pay for those premium services. It is well past time for sports enthusiasts to pay for their very expensive content in a sports premium package. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Luke Guillory Sent: Friday, November 17, 2017 3:02 PM To: Jean-Francois Mezei; nanog at nanog.org Subject: RE: Broadcast television in an IP world This use to be the case. While it might lower OPX that surely won't result in lower retrans, will just be more profit for them. We're down as well on video subs, this is 99% due to rising prices. This is where it's heading for sure, in the end it will cost more as well since each will be charging more than the per sub rates we're getting charge. They'll have to in order to keep revenue the same. When ESPN offers an OTT product I have no doubt it will be near the $20 per month, for 5 channels or so? Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . From Matthew.Black at csulb.edu Mon Nov 20 16:29:39 2017 From: Matthew.Black at csulb.edu (Matthew Black) Date: Mon, 20 Nov 2017 16:29:39 +0000 Subject: Broadcast television in an IP world In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38741E@RTC-EXCH01.RESERVE.LDS> References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38223A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38741E@RTC-EXCH01.RESERVE.LDS> Message-ID: I wrote ET AL. ESPN costs $9 per month. Throw in Fox Sports and other regional sports franchise fees to get $20 a month. And then ESPN double dips by airing advertising. HBO and Showtime are commercial free. http://www.businessinsider.com/cable-satellite-tv-sub-fees-espn-networks-2017-3 -----Original Message----- From: Luke Guillory [mailto:lguillory at reservetele.com] Sent: Monday, November 20, 2017 8:10 AM To: Matthew Black; nanog at nanog.org Subject: RE: Broadcast television in an IP world ESPN's programing fees aren't anywhere near $20 a month, they're not even $10 a month. HBO on the other hand is pretty much what the end user pays in terms of programing cost. -----Original Message----- From: Matthew Black [mailto:Matthew.Black at csulb.edu] Sent: Monday, November 20, 2017 9:11 AM To: Luke Guillory; nanog at nanog.org Subject: RE: Broadcast television in an IP world Right now only 25% of cable subscribers watch sports channels like ESPN. But 100% pay up to $20 a month for ESPN et al. in their monthly subscription fees. HBO and Showtime subscribers pay for those premium services. It is well past time for sports enthusiasts to pay for their very expensive content in a sports premium package. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Luke Guillory Sent: Friday, November 17, 2017 3:02 PM To: Jean-Francois Mezei; nanog at nanog.org Subject: RE: Broadcast television in an IP world This use to be the case. While it might lower OPX that surely won't result in lower retrans, will just be more profit for them. We're down as well on video subs, this is 99% due to rising prices. This is where it's heading for sure, in the end it will cost more as well since each will be charging more than the per sub rates we're getting charge. They'll have to in order to keep revenue the same. When ESPN offers an OTT product I have no doubt it will be near the $20 per month, for 5 channels or so? Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . From lguillory at reservetele.com Mon Nov 20 16:39:32 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 20 Nov 2017 16:39:32 +0000 Subject: Broadcast television in an IP world In-Reply-To: References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38223A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38741E@RTC-EXCH01.RESERVE.LDS> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB387547@RTC-EXCH01.RESERVE.LDS> I missed the et al, sorry about that. -----Original Message----- From: Matthew Black [mailto:Matthew.Black at csulb.edu] Sent: Monday, November 20, 2017 10:30 AM To: Luke Guillory; nanog at nanog.org Subject: RE: Broadcast television in an IP world I wrote ET AL. ESPN costs $9 per month. Throw in Fox Sports and other regional sports franchise fees to get $20 a month. And then ESPN double dips by airing advertising. HBO and Showtime are commercial free. http://www.businessinsider.com/cable-satellite-tv-sub-fees-espn-networks-2017-3 -----Original Message----- From: Luke Guillory [mailto:lguillory at reservetele.com] Sent: Monday, November 20, 2017 8:10 AM To: Matthew Black; nanog at nanog.org Subject: RE: Broadcast television in an IP world ESPN's programing fees aren't anywhere near $20 a month, they're not even $10 a month. HBO on the other hand is pretty much what the end user pays in terms of programing cost. -----Original Message----- From: Matthew Black [mailto:Matthew.Black at csulb.edu] Sent: Monday, November 20, 2017 9:11 AM To: Luke Guillory; nanog at nanog.org Subject: RE: Broadcast television in an IP world Right now only 25% of cable subscribers watch sports channels like ESPN. But 100% pay up to $20 a month for ESPN et al. in their monthly subscription fees. HBO and Showtime subscribers pay for those premium services. It is well past time for sports enthusiasts to pay for their very expensive content in a sports premium package. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Luke Guillory Sent: Friday, November 17, 2017 3:02 PM To: Jean-Francois Mezei; nanog at nanog.org Subject: RE: Broadcast television in an IP world This use to be the case. While it might lower OPX that surely won't result in lower retrans, will just be more profit for them. We're down as well on video subs, this is 99% due to rising prices. This is where it's heading for sure, in the end it will cost more as well since each will be charging more than the per sub rates we're getting charge. They'll have to in order to keep revenue the same. When ESPN offers an OTT product I have no doubt it will be near the $20 per month, for 5 channels or so? Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . From Matthew.Black at csulb.edu Mon Nov 20 16:54:38 2017 From: Matthew.Black at csulb.edu (Matthew Black) Date: Mon, 20 Nov 2017 16:54:38 +0000 Subject: Broadcast television in an IP world In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB387547@RTC-EXCH01.RESERVE.LDS> References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38223A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38741E@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB387547@RTC-EXCH01.RESERVE.LDS> Message-ID: No problem, and thanks for the apology. Cable TV bills get most of us heated. 100% ala carte pricing may not be the solution, but the current model is pretty cruel to subscribers who aren't sports fans. It's likely that a premium sports package may have to charge upwards of $50-100 per month since they can no longer charge everyone. ESPN subscriber fees have skyrocketed because they can get away with charging more, just like HBO. The cable TV industry should be much more transparent about costs. -----Original Message----- From: Luke Guillory [mailto:lguillory at reservetele.com] Sent: Monday, November 20, 2017 8:40 AM To: Matthew Black; nanog at nanog.org Subject: RE: Broadcast television in an IP world I missed the et al, sorry about that. -----Original Message----- From: Matthew Black [mailto:Matthew.Black at csulb.edu] Sent: Monday, November 20, 2017 10:30 AM To: Luke Guillory; nanog at nanog.org Subject: RE: Broadcast television in an IP world I wrote ET AL. ESPN costs $9 per month. Throw in Fox Sports and other regional sports franchise fees to get $20 a month. And then ESPN double dips by airing advertising. HBO and Showtime are commercial free. http://www.businessinsider.com/cable-satellite-tv-sub-fees-espn-networks-2017-3 -----Original Message----- From: Luke Guillory [mailto:lguillory at reservetele.com] Sent: Monday, November 20, 2017 8:10 AM To: Matthew Black; nanog at nanog.org Subject: RE: Broadcast television in an IP world ESPN's programing fees aren't anywhere near $20 a month, they're not even $10 a month. HBO on the other hand is pretty much what the end user pays in terms of programing cost. -----Original Message----- From: Matthew Black [mailto:Matthew.Black at csulb.edu] Sent: Monday, November 20, 2017 9:11 AM To: Luke Guillory; nanog at nanog.org Subject: RE: Broadcast television in an IP world Right now only 25% of cable subscribers watch sports channels like ESPN. But 100% pay up to $20 a month for ESPN et al. in their monthly subscription fees. HBO and Showtime subscribers pay for those premium services. It is well past time for sports enthusiasts to pay for their very expensive content in a sports premium package. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Luke Guillory Sent: Friday, November 17, 2017 3:02 PM To: Jean-Francois Mezei; nanog at nanog.org Subject: RE: Broadcast television in an IP world This use to be the case. While it might lower OPX that surely won't result in lower retrans, will just be more profit for them. We're down as well on video subs, this is 99% due to rising prices. This is where it's heading for sure, in the end it will cost more as well since each will be charging more than the per sub rates we're getting charge. They'll have to in order to keep revenue the same. When ESPN offers an OTT product I have no doubt it will be near the $20 per month, for 5 channels or so? Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . From lguillory at reservetele.com Mon Nov 20 17:09:10 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 20 Nov 2017 17:09:10 +0000 Subject: Broadcast television in an IP world In-Reply-To: References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38223A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38741E@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB387547@RTC-EXCH01.RESERVE.LDS> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB387663@RTC-EXCH01.RESERVE.LDS> ESPN thought they could get away with it and are now feeling the push back that the end users are fed up with it. Of course being forced into the expanded basic tier meant they were part of the last group to feel it though. I don't think the current model is cruel as much as the rising price of programing has been which is only getting worse. In the end going direct will cost the end user more in the long run. ESPN has lost 100s of thousands of customers, being that 80% of their revenue comes from subs leaves a grim picture of their business model. Hell they pay 1.9B a year just for their NFL rights with a total of 7.3B a year in rights and production. Of course this doesn't drop in price as they bleed customers which also could cause an issue for advertising since I believe they have a min eyeball clause in their contracts. And unfortunately we're not able to state specifics when it comes to programing, they make sure to state that in our contracts so we can't inform customers. -----Original Message----- From: Matthew Black [mailto:Matthew.Black at csulb.edu] Sent: Monday, November 20, 2017 10:55 AM To: Luke Guillory; nanog at nanog.org Subject: RE: Broadcast television in an IP world No problem, and thanks for the apology. Cable TV bills get most of us heated. 100% ala carte pricing may not be the solution, but the current model is pretty cruel to subscribers who aren't sports fans. It's likely that a premium sports package may have to charge upwards of $50-100 per month since they can no longer charge everyone. ESPN subscriber fees have skyrocketed because they can get away with charging more, just like HBO. The cable TV industry should be much more transparent about costs. -----Original Message----- From: Luke Guillory [mailto:lguillory at reservetele.com] Sent: Monday, November 20, 2017 8:40 AM To: Matthew Black; nanog at nanog.org Subject: RE: Broadcast television in an IP world I missed the et al, sorry about that. -----Original Message----- From: Matthew Black [mailto:Matthew.Black at csulb.edu] Sent: Monday, November 20, 2017 10:30 AM To: Luke Guillory; nanog at nanog.org Subject: RE: Broadcast television in an IP world I wrote ET AL. ESPN costs $9 per month. Throw in Fox Sports and other regional sports franchise fees to get $20 a month. And then ESPN double dips by airing advertising. HBO and Showtime are commercial free. http://www.businessinsider.com/cable-satellite-tv-sub-fees-espn-networks-2017-3 -----Original Message----- From: Luke Guillory [mailto:lguillory at reservetele.com] Sent: Monday, November 20, 2017 8:10 AM To: Matthew Black; nanog at nanog.org Subject: RE: Broadcast television in an IP world ESPN's programing fees aren't anywhere near $20 a month, they're not even $10 a month. HBO on the other hand is pretty much what the end user pays in terms of programing cost. -----Original Message----- From: Matthew Black [mailto:Matthew.Black at csulb.edu] Sent: Monday, November 20, 2017 9:11 AM To: Luke Guillory; nanog at nanog.org Subject: RE: Broadcast television in an IP world Right now only 25% of cable subscribers watch sports channels like ESPN. But 100% pay up to $20 a month for ESPN et al. in their monthly subscription fees. HBO and Showtime subscribers pay for those premium services. It is well past time for sports enthusiasts to pay for their very expensive content in a sports premium package. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Luke Guillory Sent: Friday, November 17, 2017 3:02 PM To: Jean-Francois Mezei; nanog at nanog.org Subject: RE: Broadcast television in an IP world This use to be the case. While it might lower OPX that surely won't result in lower retrans, will just be more profit for them. We're down as well on video subs, this is 99% due to rising prices. This is where it's heading for sure, in the end it will cost more as well since each will be charging more than the per sub rates we're getting charge. They'll have to in order to keep revenue the same. When ESPN offers an OTT product I have no doubt it will be near the $20 per month, for 5 channels or so? Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 _________________________________________________________________________________________________ Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. . From sethm at rollernet.us Mon Nov 20 17:25:33 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 20 Nov 2017 09:25:33 -0800 Subject: Broadcast television in an IP world In-Reply-To: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB387663@RTC-EXCH01.RESERVE.LDS> References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38223A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38741E@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB387547@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB387663@RTC-EXCH01.RESERVE.LDS> Message-ID: On 11/20/17 9:09 AM, Luke Guillory wrote: > > I don't think the current model is cruel as much as the rising price of programing has been which is only getting worse. In the end going direct will cost the end user more in the long run. ESPN has lost 100s of thousands of customers, being that 80% of their revenue comes from subs leaves a grim picture of their business model. Hell they pay 1.9B a year just for their NFL rights with a total of 7.3B a year in rights and production. Of course this doesn't drop in price as they bleed customers which also could cause an issue for advertising since I believe they have a min eyeball clause in their contracts. It's certainly possible for the cost of those rights to go down if ESPN financially implodes and nobody else will pick it up at the NFL's asking price, but probably not likely. From joelja at bogus.com Mon Nov 20 17:52:54 2017 From: joelja at bogus.com (joel jaeggli) Date: Mon, 20 Nov 2017 09:52:54 -0800 Subject: Commodity routers/switches In-Reply-To: <49054322.1749.1511105781907.JavaMail.mhammett@ThunderFuck> References: <8C5DE76F-211B-45B4-8680-936119F1E49C@gmail.com> <3607ab13-6ca9-faa5-5038-f3dd71516b76@nordu.net> <49054322.1749.1511105781907.JavaMail.mhammett@ThunderFuck> Message-ID: <42ec7dc6-045e-703f-2f41-9af958dc955a@bogus.com> On 11/19/17 07:36, Mike Hammett wrote: > Which is sad because I believe there are a ton of people using old gear (lacking modern features and security) because the old gear meets price and performance requirements. Although obviously much smaller networks (and thus potential with each one), it's easy to say there are more 1G\10G ISPs than there are 100G ISPs. Feature demand drives per port costs that are not very competitively achieved on 1Gb/s switches. On the plus side the per-port cost of the 10Gb/s and mixed 10/100Gb/s switches with usefully rich features continues to slide. Some use of L2 devices for port demux for bigger iron has been done in the past, I imagine it still works for a number of use cases (cisco sells fabric extenders under a similar rational). > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Fredrik Korsbäck" > To: nanog at nanog.org > Sent: Sunday, November 19, 2017 1:46:53 AM > Subject: Re: Commodity routers/switches > > On 2017-11-19 02:55, mike.lyon at gmail.com wrote: >> Howdy! >> >> Looking to replace some edge routers for my small ISP. With all the various SDN platforms available along with various choices of bare-metal hardware platforms, im thinking i may go this route instead of going with Cisco/Juniper/Etc. >> >> I only need a handful of 10G uplinks. The SuperMicro SSE-G3648B and the Penguin Arctica Network switches appear to fit my needs. >> >> I am eyeing Cumulus Linux to run on these, but that isn’t set in stone. >> >> They’ll likely be getting 2 full tables along with some peers. >> >> Has anyone run SuperMicro or Penguin hardware with Cumulus in this type of scenario? >> >> What were your experiences? How is BGP convergence time on x86 hardware these days? >> >> Any insight would be appreciated. >> >> Thank You, >> Mike >> > Replacing a edge-router with a switch is nothing new, however make sure you actually replace it with the correct one. > > The Supermicro looks like any generic Helix4-switch and is a ToR-switch for the datacenter. Its not very fitting for > edge-routing. It does not have buffers at all and would make your sub-speed connections perform like shit, and also it > has a tiny LPM table so you wont be able to fit anywhere near a full table in there > > It seems that you want a cost-effective 1G solution given that you linked SSE-G3648B? > > Merchant-switch silicon and edge-routing isn't very competitive on 1G/10G, both because traditional legacy-routers is > somewhat cheap for 1G applications and also that 1G is virtually non-existant in datacenter enviroments these days so > its hard to leverage the economy-of-scale from there on these swithces. > > Look at Nokias portfolio for 1G/10G routers, they still care in that segment and is in Europe a very popular choice for > broadband buildouts, as is Huaweis smaller NetEngines but that might not fly that well in the US. Juniper MX150 might > also work depending on how much 1G you need, but you likely need more. > > If you bump it up a notch to 10G/100G or 100G only the market for routing-merchant-silicon looks much better. I guess > the most famous platform is the Arista 7280R that was the first Broadcom-based box that accepted 1M routes, had big > buffers and didnt cost the equivalent of a bunch of new cars for a 1Tbit of capacity like J/C/N/H would charge you for a > equivalent linecard to their edge-portfolios. > > Cisco quickly released NCS550 productline as an answer, Huawei released CE6870-line (but didnt do the LEM/LPM hack that > C/A did for full tables to protect NetEngine BU), Juniper pushes QFX10K which is somewhat equal to a Broadcom > Jericho-based box. The only Whitebox-vendor i know off that actually has a Jericho (qumran) based box is Agema with the > AGC7648S, not sure which stand-alone NOS that actually supports this box fully. > > Now Jericho+ is also out and Jericho2 is around the corner so i guess we will see alot bigger and even more competetive > switch-routers based on these chips. But it doesent really help much if you are operating in 1G/10G space. > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: OpenPGP digital signature URL: From aaron1 at gvtc.com Mon Nov 20 17:58:22 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Mon, 20 Nov 2017 11:58:22 -0600 Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> Message-ID: <000301d36229$2853fb50$78fbf1f0$@gvtc.com> Funny about the noisy fans on NF OCA servers... we had a resident actually complain about our CO being load and her hearing the high-pitched whine 24X7... her house is literally across the street in the neighborhood where one of our small datacenter/caching location is. My fellow engineer said he was going to go out there and put a fuzzy door-snake along the bottom of the door to dull the noise. Lol -Aaron From bicknell at ufp.org Mon Nov 20 18:47:11 2017 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 20 Nov 2017 10:47:11 -0800 Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> Message-ID: <20171120184711.GA52142@ussenterprise.ufp.org> In a message written on Sat, Nov 18, 2017 at 01:48:08AM +0100, Baldur Norddahl wrote: > Does multicast have any future? Netflix, YouTube, et al does not use it. > People want instant replay and a catalogue to select from. Except for sport > events, live TV has no advantage so why even try to optimize for it? Yes, but not the way you're asking. Multicast to end user workstations and between ISP's is probably dead and will never return. Multicast used in private networks, including to distribute programming to set top boxes is alive and well, often hidden in view but in use by millions. It's not just live TV, in the sense of sports. Many businesses leave on their favorite news channel 24x7x365, people still tune into topical shows (evening news, the late show) on schedules, etc. And some of them also do things like push software and guide data using multicast. -- Leo Bicknell - bicknell at ufp.org PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From bill at herrin.us Mon Nov 20 19:22:19 2017 From: bill at herrin.us (William Herrin) Date: Mon, 20 Nov 2017 14:22:19 -0500 Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> Message-ID: On Fri, Nov 17, 2017 at 7:48 PM, Baldur Norddahl wrote: > Does multicast have any future? Multicast is a fine replacement for local-lan (i.e. direct connected interface) broadcast. For video distribution, multilevel caching simply works better. It's no deep mystery why. Wide scale multicasting requires ISPs to allow the most critical inline resource (the routers) to accept fine-tuned instructions from any third party that wants to be a content head-end. For ordinary routing we don't allow anything more fine tuned that a /24 and we've been reluctant to allow that. We're somehow going to beef up the routers to allow non-paying third parties to fine-tune down to the video stream? Not happening. Multilevel caching consumes upwards of an order of magnitude more data transfer than an optimal multicast system, but it does it to the side, out of the critical path. If a node breaks, it doesn't take down the network with it. And you can slap a cheap server in place And of course caching supports time-shifting which multicast does not. Given how people consume video today, that's an important distinction. Peering in to my crystal ball, I see an abstracted caching system which isn't tied to any particular vendor. Fetch decryption keys directly from the video vendor, then find the nearest cache via a solicitation to a protocol-standard anycast IP address. The cache fetches from the next cache up. ISP deploys as many caches as it finds convenient and cost effective. Paid megacache at the top of the hierarchy located at the carrier neutral data center that's cheaper than transit for both the eyeball networks and the content providers. Data cached in chunks of arbitrary data that only mean anything to the producer and consumer but are identified in such a way that multiple consumers for the same data request the same chunk ID. And small enough chunks that real-time feeds are delayed by few enough seconds to make them practical. Unicast with a little bit of anycast. No multicast on that road map. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From mohta at necom830.hpcl.titech.ac.jp Mon Nov 20 22:14:28 2017 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 21 Nov 2017 07:14:28 +0900 Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> Message-ID: On 2017/11/21 4:22, William Herrin wrote: >> Does multicast have any future? Combined with bandwidth guarantee or prioritization, yes. > We're somehow going to beef up the routers to allow non-paying third > parties to fine-tune down to the video stream? Not happening. It is merely that third parties should pay ISPs offering multicast service for them. Amount of payment should be proportional to bandwidth used and area covered. Masataka Ohta From jfmezei_nanog at vaxination.ca Mon Nov 20 22:32:50 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Mon, 20 Nov 2017 17:32:50 -0500 Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> Message-ID: On 2017-11-20 17:14, Masataka Ohta wrote: > It is merely that third parties should pay ISPs offering multicast > service for them. Amount of payment should be proportional to > bandwidth used and area covered. Since multicast benefits the ISP the most, why should the ISP charge the content provider for multicast? The content provider (lets say local TV station that broadcasts the Superbowl) can just unicast to the ISP a single stream, and give the ISPs some pizza sized box (lets call it an "Appliance") and that box then provides unicast delivery to each customer watching the Superbowl. The ISP only wins in reduced transit/peering load, but not on the load on its distribution network. And with the switch to on-demand programming, one wonders if the cost of setting up multicast all the way from the "border" to every bit of CPE equipment is worth it if it is only truly beneficial for the Superbowl and a couple of Hollywood awards ceremonies per year. From mohta at necom830.hpcl.titech.ac.jp Mon Nov 20 23:31:32 2017 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 21 Nov 2017 08:31:32 +0900 Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> Message-ID: <8af32dee-b10d-cbf1-e4f3-ddab03ad91a7@necom830.hpcl.titech.ac.jp> Jean-Francois Mezei wrote: >> It is merely that third parties should pay ISPs offering multicast >> service for them. Amount of payment should be proportional to >> bandwidth used and area covered. > > Since multicast benefits the ISP the most, why should the ISP charge the > content provider for multicast? For prioritization, without which multicast does not work over congested links. > The content provider (lets say local TV station that broadcasts the > Superbowl) can just unicast to the ISP a single stream, and give the > ISPs some pizza sized box (lets call it an "Appliance") and that box > then provides unicast delivery to each customer watching the Superbowl. Have you considered CAPEX and OPEX of the boxes? > And with the switch to on-demand programming, one wonders if the cost of > setting up multicast all the way from the "border" to every bit of CPE > equipment is worth it if it is only truly beneficial for the Superbowl > and a couple of Hollywood awards ceremonies per year. Aren't you arguing against your boxes? Masataka Ohta From lguillory at reservetele.com Mon Nov 20 23:40:49 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Mon, 20 Nov 2017 23:40:49 +0000 Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> , Message-ID: <9AE126A8-5F2F-463F-89F9-1B22DA0638EE@reservetele.com> Why would an ISP not want to conserve edge resources? If I’m doing iptv I’m better off doing multicast which would conserve loads of BW for something popular like the Super Bowl. Especially if I’m doing this over docsis. Sent from my iPhone On Nov 20, 2017, at 4:33 PM, Jean-Francois Mezei > wrote: On 2017-11-20 17:14, Masataka Ohta wrote: It is merely that third parties should pay ISPs offering multicast service for them. Amount of payment should be proportional to bandwidth used and area covered. Since multicast benefits the ISP the most, why should the ISP charge the content provider for multicast? The content provider (lets say local TV station that broadcasts the Superbowl) can just unicast to the ISP a single stream, and give the ISPs some pizza sized box (lets call it an "Appliance") and that box then provides unicast delivery to each customer watching the Superbowl. The ISP only wins in reduced transit/peering load, but not on the load on its distribution network. And with the switch to on-demand programming, one wonders if the cost of setting up multicast all the way from the "border" to every bit of CPE equipment is worth it if it is only truly beneficial for the Superbowl and a couple of Hollywood awards ceremonies per year. Luke Guillory Vice President – Technology and Innovation [cid:image62ac68.JPG at a6fc1380.42ad82e4] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From jason at unlimitednet.us Tue Nov 21 05:17:30 2017 From: jason at unlimitednet.us (Jason Canady) Date: Tue, 21 Nov 2017 00:17:30 -0500 Subject: Amazon Streaming Department Message-ID: <5bfb22e8-0a50-afca-67d1-1f15d7f9691b@unlimitednet.us> Hello all, A while back I wrote in regarding an update on Netflix services / our IP addresses being blocked. I had helpful feedback in getting this resolved. Does anyone have a contact at Amazon for resolving IP blacklist issues on their Amazon Prime / streaming services? I have contacted their Customer Service, but they aren't very easy to work with. Thank you! Best Regards, Jason Canady Unlimited Net, LLC From baldur.norddahl at gmail.com Tue Nov 21 10:11:21 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 21 Nov 2017 11:11:21 +0100 Subject: Broadcast television in an IP world In-Reply-To: <9AE126A8-5F2F-463F-89F9-1B22DA0638EE@reservetele.com> References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> <9AE126A8-5F2F-463F-89F9-1B22DA0638EE@reservetele.com> Message-ID: Den 21. nov. 2017 00.42 skrev "Luke Guillory" : Why would an ISP not want to conserve edge resources? If I’m doing iptv I’m better off doing multicast which would conserve loads of BW for something popular like the Super Bowl. Especially if I’m doing this over docsis. You pay for 95th percentile. If that is decided by everyone watching Game of Thrones one day, then using the same resources for Super Bowl the next day will be for free. From lguillory at reservetele.com Tue Nov 21 13:58:07 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 21 Nov 2017 13:58:07 +0000 Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> <9AE126A8-5F2F-463F-89F9-1B22DA0638EE@reservetele.com>, Message-ID: <86FFAE63-66CE-41E2-ADA3-F1124D5C4537@reservetele.com> I’m not paying anything for local resources with regards to local edge delivery, that’s capital expenditures not MRCs. Our edge networks aren’t unlimited or free, so while it’s not costing me on the transit side there still are cost in terms of upgrades and so on. My point is that In some networks such as docsis conserving edge resources can be helped with multicast. Sent from my iPhone On Nov 21, 2017, at 4:12 AM, Baldur Norddahl > wrote: Den 21. nov. 2017 00.42 skrev "Luke Guillory" >: Why would an ISP not want to conserve edge resources? If I’m doing iptv I’m better off doing multicast which would conserve loads of BW for something popular like the Super Bowl. Especially if I’m doing this over docsis. You pay for 95th percentile. If that is decided by everyone watching Game of Thrones one day, then using the same resources for Super Bowl the next day will be for free. Luke Guillory Vice President – Technology and Innovation [cid:imagef9b835.JPG at 242ea556.429501f5] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From nanog at ics-il.net Tue Nov 21 14:00:09 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 21 Nov 2017 08:00:09 -0600 (CST) Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> <9AE126A8-5F2F-463F-89F9-1B22DA0638EE@reservetele.com> Message-ID: <550975981.3502.1511272806434.JavaMail.mhammett@ThunderFuck> Not all networks have unlimited nor easily upgraded access networks. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Baldur Norddahl" To: nanog at nanog.org Sent: Tuesday, November 21, 2017 4:11:21 AM Subject: Re: Broadcast television in an IP world Den 21. nov. 2017 00.42 skrev "Luke Guillory" : Why would an ISP not want to conserve edge resources? If I’m doing iptv I’m better off doing multicast which would conserve loads of BW for something popular like the Super Bowl. Especially if I’m doing this over docsis. You pay for 95th percentile. If that is decided by everyone watching Game of Thrones one day, then using the same resources for Super Bowl the next day will be for free. From lguillory at reservetele.com Tue Nov 21 14:29:33 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 21 Nov 2017 14:29:33 +0000 Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> <9AE126A8-5F2F-463F-89F9-1B22DA0638EE@reservetele.com> <86FFAE63-66CE-41E2-ADA3-F1124D5C4537@reservetele.com>, Message-ID: The comment I was originally replying to was the following. I’ve said edge resources, nothing about WAN. The content provider (lets say local TV station that broadcasts the Superbowl) can just unicast to the ISP a single stream, and give the ISPs some pizza sized box (lets call it an "Appliance") and that box then provides unicast delivery to each customer watching the Superbowl. Sent from my iPhone On Nov 21, 2017, at 8:22 AM, K. Scott Helms > wrote: It's not helpful for saving resources in DOCSIS (nor any other) edge networks. The economics mean that, as bits get sold in the US and many other places, it won't be in the foreseeable future. Customers care about popular video sources. Popular content sources have CDNs with local nodes and/or direct (low cost) connections to their CDN. That's far more efficient than allowing multicast across WAN links. K. Scott Helms Luke Guillory Vice President – Technology and Innovation [cid:image231e71.JPG at 0b2ab948.43bc9114] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. On Tue, Nov 21, 2017 at 8:58 AM, Luke Guillory > wrote: I’m not paying anything for local resources with regards to local edge delivery, that’s capital expenditures not MRCs. Our edge networks aren’t unlimited or free, so while it’s not costing me on the transit side there still are cost in terms of upgrades and so on. My point is that In some networks such as docsis conserving edge resources can be helped with multicast. Sent from my iPhone On Nov 21, 2017, at 4:12 AM, Baldur Norddahl >> wrote: Den 21. nov. 2017 00.42 skrev "Luke Guillory" >>: Why would an ISP not want to conserve edge resources? If I’m doing iptv I’m better off doing multicast which would conserve loads of BW for something popular like the Super Bowl. Especially if I’m doing this over docsis. You pay for 95th percentile. If that is decided by everyone watching Game of Thrones one day, then using the same resources for Super Bowl the next day will be for free. Luke Guillory Vice President – Technology and Innovation [cid:imagef9b835.JPG at 242ea556.429501f5] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From baldur.norddahl at gmail.com Tue Nov 21 15:00:25 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 21 Nov 2017 16:00:25 +0100 Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> <9AE126A8-5F2F-463F-89F9-1B22DA0638EE@reservetele.com> <86FFAE63-66CE-41E2-ADA3-F1124D5C4537@reservetele.com> Message-ID: The point is that you need to build the network to handle peak load of OTT streaming. If the network can handle major releases like a new season of Game of Thrones, then the network has the capacity to handle live events streamed the same way. It does not matter how you paid for that capacity. If you truly want to save a buildout at the edge, you need cache servers deeper into the network. Game of Thrones might not be as big as Super Bowl, but we will get there eventually. When we do, there is money to be saved by only managing one type of network (unicast). Den 21. nov. 2017 15.29 skrev "Luke Guillory" : > The comment I was originally replying to was the following. I’ve said edge > resources, nothing about WAN. > > The content provider (lets say local TV station that broadcasts the > > Superbowl) can just unicast to the ISP a single stream, and give the > > ISPs some pizza sized box (lets call it an "Appliance") and that box > > then provides unicast delivery to each customer watching the Superbowl. > > > > > > *Sent from my iPhone* > > On Nov 21, 2017, at 8:22 AM, K. Scott Helms wrote: > > It's not helpful for saving resources in DOCSIS (nor any other) edge > networks. The economics mean that, as bits get sold in the US and many > other places, it won't be in the foreseeable future. Customers care about > popular video sources. Popular content sources have CDNs with local nodes > and/or direct (low cost) connections to their CDN. That's far more > efficient than allowing multicast across WAN links. > > K. Scott Helms > > > > Luke Guillory > Vice President – Technology and Innovation > > > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > Web: www.rtconline.com > Reserve Telecommunications > 100 RTC Dr > > Reserve, LA 70084 > > > > > > > *Disclaimer:* > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by > e-mail if you have received this e-mail by mistake and delete this e-mail > from your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Luke Guillory therefore > does not accept liability for any errors or omissions in the contents of > this message, which arise as a result of e-mail transmission. > > On Tue, Nov 21, 2017 at 8:58 AM, Luke Guillory > wrote: > >> I’m not paying anything for local resources with regards to local edge >> delivery, that’s capital expenditures not MRCs. >> >> Our edge networks aren’t unlimited or free, so while it’s not costing me >> on the transit side there still are cost in terms of upgrades and so on. >> >> My point is that In some networks such as docsis conserving edge >> resources can be helped with multicast. >> >> >> >> Sent from my iPhone >> >> On Nov 21, 2017, at 4:12 AM, Baldur Norddahl > > wrote: >> >> Den 21. nov. 2017 00.42 <20%2017%2000%2042> skrev "Luke Guillory" < >> lguillory at reservetele.com>: >> >> Why would an ISP not want to conserve edge resources? If I’m doing iptv >> I’m >> better off doing multicast which would conserve loads of BW for something >> popular like the Super Bowl. Especially if I’m doing this over docsis. >> >> >> >> You pay for 95th percentile. If that is decided by everyone watching Game >> of Thrones one day, then using the same resources for Super Bowl the next >> day will be for free. >> >> >> >> >> Luke Guillory >> Vice President – Technology and Innovation >> >> >> [cid:imagef9b835.JPG at 242ea556.429501f5] > > >> >> Tel: 985.536.1212 >> Fax: 985.536.0300 >> Email: lguillory at reservetele.com >> Web: www.rtconline.com >> >> Reserve Telecommunications >> 100 RTC Dr >> >> Reserve, LA 70084 >> >> >> >> >> >> Disclaimer: >> The information transmitted, including attachments, is intended only for >> the person(s) or entity to which it is addressed and may contain >> confidential and/or privileged material which should not disseminate, >> distribute or be copied. Please notify Luke Guillory immediately by e-mail >> if you have received this e-mail by mistake and delete this e-mail from >> your system. E-mail transmission cannot be guaranteed to be secure or >> error-free as information could be intercepted, corrupted, lost, destroyed, >> arrive late or incomplete, or contain viruses. Luke Guillory therefore does >> not accept liability for any errors or omissions in the contents of this >> message, which arise as a result of e-mail transmission. >> >> > From cschoonover at duluthtrading.com Fri Nov 17 20:13:27 2017 From: cschoonover at duluthtrading.com (Casey Schoonover) Date: Fri, 17 Nov 2017 20:13:27 +0000 Subject: Broadcast television in an IP world In-Reply-To: References: Message-ID: Bit of background, I used to work for a mid-market commercial TV station in Illinois, both in IT/Broadcast Engineering and eventually in production. I'm not to the point in my career where I can speak intelligently about content delivery, but from a technology perspective this does sound like a solved problem. That said, I don't think this is a technology problem. The biggest issue we ran into at my former employer with new tech and new ideas was both with budget and the corporate bureaucracy. Without significant buy-in -- both corporate politics-wise and financially -- from the station parent company, something like this would be cost-prohibitive for a non-large station to undertake by themselves, if they were even allowed to. Generally speaking, where station IT was concerned we were left to fend for ourselves, from aging, non-virtualized Server 2003 domain controllers in 2012. This wasn't much better on the broadcast engineering side, as I remember our broadcast engineers running a new digital subchannel for a while off of an aging A/V router from the 90's/early aughts. I don't recall offhand exact numbers on circuit speeds or anything, but the best label I can use to describe both our WAN connectivity to our parent org and standard internet circuits would be "woefully insufficient." Definitely easier to overcome these days, as plenty of broadcast providers in the cable/satellite TV arena co-located with us a tad, which might offer an option to piggy back off of any connectivity they might have, but I'd argue a station out in the boonies might run into issues with sufficient upload speeds to serve content with. Cost of content storage is likely much less of a concern, depending on how much content you actually store and for how long, but it's also something worth considering. I suppose the biggest takeaway is that, like I mentioned, in the States you aren't just dealing with the big networks. You're also dealing with the corporate hegemony of the various station owners. While networks can force a lot of standards, policies, and procedures on the broadcast groups/stations out there as part of the contract that allows them to carry network content, the cost of implementing something will generally fall on the owners and the stations. That's not even mentioning regulatory requirements like EAS and other public obligations that come with running an OTA TV transmitter state-side. Casey Schoonover Network Engineer II Duluth Trading Company 170 Countryside Dr Belleville, WI 53508 cschoonover at duluthtrading.com -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jean-Francois Mezei Sent: Friday, November 17, 2017 1:46 PM To: Nanog at nanog.org Subject: Broadcast television in an IP world Once ISPs became able to provide sufficient speeds to end users, video over the internet became a thing. This week, the FCC approved the ATSC3 standard. What if instead of moving to ATSC3, TV stations that broadcast OTA became OTT instead? Could the Internet handle the load? Since TV stations that are OTA are "local", wouldn't this create an instant CDN service for networks such as CBS/ABC/NBS/FOX/PBS since these networks have local presence and can feed ISPs locally? And while a small ISP serving Plattsburg NY would have no problem peering with the WPTZ server in Plattsburg, would the big guys like Comcast/Verizon be amenable to peering with TV stations in small markets? Some of them would also be selling transit to the TV station (for instance, to serve its Canadian audience, WPTZ would need transit to go outside of Comcast/Frontier and reach canadian IP networks). But a local TV station whose footprint is served by the local ISPs may not need any transit. The PAY TV servives, if HBO is any indication will also move OTT, but be served in the more traditional way, with a central feed of content going to a CDN which has presence that is local to large ISPs (or inside ISPs). We the traditional BDU (canada) MVPD (USA) is abandonned by the public and TV stations , PAY TV services and SVOD services such as Netflix are all on the Internet, would this represent a huge change in load, or just incremental growth, especially if local TV stations are served locally? Just curious to see if the current OTA and Cable distribution models will/could morph into IP based services, eliminating the "cable TV" service. From m1enrage at gmail.com Mon Nov 20 16:12:25 2017 From: m1enrage at gmail.com (Tom Carter) Date: Mon, 20 Nov 2017 09:12:25 -0700 Subject: Broadcast television in an IP world In-Reply-To: References: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB381D5A@RTC-EXCH01.RESERVE.LDS> <8D89F96B7AB1B84F9E049CC7BB91BF5CFB38223A@RTC-EXCH01.RESERVE.LDS> Message-ID: As much as that would make sense, there are minimum penetration requirements in contracts, particularly for ESPN. It's going to take a lot of pain on all sides to change those contracts going forward to make Sports as an extra package entirely. On Nov 20, 2017 8:14 AM, "Matthew Black" wrote: > Right now only 25% of cable subscribers watch sports channels like ESPN. > But 100% pay up to $20 a month for ESPN et al. in their monthly > subscription fees. HBO and Showtime subscribers pay for those premium > services. It is well past time for sports enthusiasts to pay for their very > expensive content in a sports premium package. > > > -----Original Message----- > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Luke Guillory > Sent: Friday, November 17, 2017 3:02 PM > To: Jean-Francois Mezei; nanog at nanog.org > Subject: RE: Broadcast television in an IP world > > This use to be the case. > > While it might lower OPX that surely won't result in lower retrans, will > just be more profit for them. > > We're down as well on video subs, this is 99% due to rising prices. > > This is where it's heading for sure, in the end it will cost more as well > since each will be charging more than the per sub rates we're getting > charge. They'll have to in order to keep revenue the same. > > When ESPN offers an OTT product I have no doubt it will be near the $20 > per month, for 5 channels or so? > > > > Luke Guillory > Vice President – Technology and Innovation > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > ____________________________________________________________ > _____________________________________ > > Disclaimer: > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by e-mail > if you have received this e-mail by mistake and delete this e-mail from > your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Luke Guillory therefore does > not accept liability for any errors or omissions in the contents of this > message, which arise as a result of e-mail transmission. . > > From kscotthelms at gmail.com Tue Nov 21 14:23:01 2017 From: kscotthelms at gmail.com (K. Scott Helms) Date: Tue, 21 Nov 2017 09:23:01 -0500 Subject: Broadcast television in an IP world In-Reply-To: <86FFAE63-66CE-41E2-ADA3-F1124D5C4537@reservetele.com> References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> <9AE126A8-5F2F-463F-89F9-1B22DA0638EE@reservetele.com> <86FFAE63-66CE-41E2-ADA3-F1124D5C4537@reservetele.com> Message-ID: It's not helpful for saving resources in DOCSIS (nor any other) edge networks. The economics mean that, as bits get sold in the US and many other places, it won't be in the foreseeable future. Customers care about popular video sources. Popular content sources have CDNs with local nodes and/or direct (low cost) connections to their CDN. That's far more efficient than allowing multicast across WAN links. K. Scott Helms On Tue, Nov 21, 2017 at 8:58 AM, Luke Guillory wrote: > I’m not paying anything for local resources with regards to local edge > delivery, that’s capital expenditures not MRCs. > > Our edge networks aren’t unlimited or free, so while it’s not costing me > on the transit side there still are cost in terms of upgrades and so on. > > My point is that In some networks such as docsis conserving edge resources > can be helped with multicast. > > > > Sent from my iPhone > > On Nov 21, 2017, at 4:12 AM, Baldur Norddahl mailto:baldur.norddahl at gmail.com>> wrote: > > Den 21. nov. 2017 00.42 skrev "Luke Guillory" mailto:lguillory at reservetele.com>>: > > Why would an ISP not want to conserve edge resources? If I’m doing iptv I’m > better off doing multicast which would conserve loads of BW for something > popular like the Super Bowl. Especially if I’m doing this over docsis. > > > > You pay for 95th percentile. If that is decided by everyone watching Game > of Thrones one day, then using the same resources for Super Bowl the next > day will be for free. > > > > > Luke Guillory > Vice President – Technology and Innovation > > > [cid:imagef9b835.JPG at 242ea556.429501f5] > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > Web: www.rtconline.com > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > > > > > Disclaimer: > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by e-mail > if you have received this e-mail by mistake and delete this e-mail from > your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Luke Guillory therefore does > not accept liability for any errors or omissions in the contents of this > message, which arise as a result of e-mail transmission. > > From kscotthelms at gmail.com Tue Nov 21 14:58:38 2017 From: kscotthelms at gmail.com (K. Scott Helms) Date: Tue, 21 Nov 2017 09:58:38 -0500 Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> <9AE126A8-5F2F-463F-89F9-1B22DA0638EE@reservetele.com> <86FFAE63-66CE-41E2-ADA3-F1124D5C4537@reservetele.com> Message-ID: Luke, I think I understand your example but the local broadcaster won't usually (ever?) have the rights to retransmit the Super Bowl over IP. Having said that, what you're describing is exactly what happens already (without multicast) via multiple CDNs. Multicast across the internet isn't feasible (economically) today. Multicast inside of an organization certainly is and is very common. Having said that, even popular content is surprisingly sparse (when we look at flows) and even inside of edge networks (DOCSIS, FTTH, xDSL, etc) it can be surprisingly challenging to make the math work. As soon as someone wants to pause the "big game" or flips to another channel you now have to move their flow to unicast. Even when lots of people are watching the same event the economics aren't as compelling as they might appear initially. On Tue, Nov 21, 2017 at 9:29 AM, Luke Guillory wrote: > The comment I was originally replying to was the following. I’ve said edge > resources, nothing about WAN. > > The content provider (lets say local TV station that broadcasts the > > Superbowl) can just unicast to the ISP a single stream, and give the > > ISPs some pizza sized box (lets call it an "Appliance") and that box > > then provides unicast delivery to each customer watching the Superbowl. > > > > > > *Sent from my iPhone* > > On Nov 21, 2017, at 8:22 AM, K. Scott Helms wrote: > > It's not helpful for saving resources in DOCSIS (nor any other) edge > networks. The economics mean that, as bits get sold in the US and many > other places, it won't be in the foreseeable future. Customers care about > popular video sources. Popular content sources have CDNs with local nodes > and/or direct (low cost) connections to their CDN. That's far more > efficient than allowing multicast across WAN links. > > K. Scott Helms > > > > Luke Guillory > Vice President – Technology and Innovation > > > > Tel: 985.536.1212 <(985)%20536-1212> > Fax: 985.536.0300 <(985)%20536-0300> > Email: lguillory at reservetele.com > Web: www.rtconline.com > Reserve Telecommunications > 100 RTC Dr > > Reserve, LA 70084 > > > > > > > *Disclaimer:* > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by > e-mail if you have received this e-mail by mistake and delete this e-mail > from your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Luke Guillory therefore > does not accept liability for any errors or omissions in the contents of > this message, which arise as a result of e-mail transmission. > > On Tue, Nov 21, 2017 at 8:58 AM, Luke Guillory > wrote: > >> I’m not paying anything for local resources with regards to local edge >> delivery, that’s capital expenditures not MRCs. >> >> Our edge networks aren’t unlimited or free, so while it’s not costing me >> on the transit side there still are cost in terms of upgrades and so on. >> >> My point is that In some networks such as docsis conserving edge >> resources can be helped with multicast. >> >> >> >> Sent from my iPhone >> >> On Nov 21, 2017, at 4:12 AM, Baldur Norddahl > > wrote: >> >> Den 21. nov. 2017 00.42 skrev "Luke Guillory" > >: >> >> Why would an ISP not want to conserve edge resources? If I’m doing iptv >> I’m >> better off doing multicast which would conserve loads of BW for something >> popular like the Super Bowl. Especially if I’m doing this over docsis. >> >> >> >> You pay for 95th percentile. If that is decided by everyone watching Game >> of Thrones one day, then using the same resources for Super Bowl the next >> day will be for free. >> >> >> >> >> Luke Guillory >> Vice President – Technology and Innovation >> >> >> [cid:imagef9b835.JPG at 242ea556.429501f5] > > >> >> Tel: 985.536.1212 >> Fax: 985.536.0300 >> Email: lguillory at reservetele.com >> Web: www.rtconline.com >> >> Reserve Telecommunications >> 100 RTC Dr >> >> Reserve, LA 70084 >> >> >> >> >> >> Disclaimer: >> The information transmitted, including attachments, is intended only for >> the person(s) or entity to which it is addressed and may contain >> confidential and/or privileged material which should not disseminate, >> distribute or be copied. Please notify Luke Guillory immediately by e-mail >> if you have received this e-mail by mistake and delete this e-mail from >> your system. E-mail transmission cannot be guaranteed to be secure or >> error-free as information could be intercepted, corrupted, lost, destroyed, >> arrive late or incomplete, or contain viruses. Luke Guillory therefore does >> not accept liability for any errors or omissions in the contents of this >> message, which arise as a result of e-mail transmission. >> >> > From nanog at ics-il.net Tue Nov 21 15:09:06 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 21 Nov 2017 09:09:06 -0600 (CST) Subject: Broadcast television in an IP world In-Reply-To: References: <9AE126A8-5F2F-463F-89F9-1B22DA0638EE@reservetele.com> <86FFAE63-66CE-41E2-ADA3-F1124D5C4537@reservetele.com> Message-ID: <929958564.3695.1511276945863.JavaMail.mhammett@ThunderFuck> Unicasting what everyone watches live on a random evening would use significantly more bandwidth than Game of Thrones or whatever OTT drop. Magnitudes more. It wouldn't even be in the same ballpark. Not all networks are capable of unicasting all live-viewed TV content, but they do literally everything else required of them. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Baldur Norddahl" To: nanog at nanog.org Sent: Tuesday, November 21, 2017 9:00:25 AM Subject: Re: Broadcast television in an IP world The point is that you need to build the network to handle peak load of OTT streaming. If the network can handle major releases like a new season of Game of Thrones, then the network has the capacity to handle live events streamed the same way. It does not matter how you paid for that capacity. If you truly want to save a buildout at the edge, you need cache servers deeper into the network. Game of Thrones might not be as big as Super Bowl, but we will get there eventually. When we do, there is money to be saved by only managing one type of network (unicast). Den 21. nov. 2017 15.29 skrev "Luke Guillory" : > The comment I was originally replying to was the following. I’ve said edge > resources, nothing about WAN. > > The content provider (lets say local TV station that broadcasts the > > Superbowl) can just unicast to the ISP a single stream, and give the > > ISPs some pizza sized box (lets call it an "Appliance") and that box > > then provides unicast delivery to each customer watching the Superbowl. > > > > > > *Sent from my iPhone* > > On Nov 21, 2017, at 8:22 AM, K. Scott Helms wrote: > > It's not helpful for saving resources in DOCSIS (nor any other) edge > networks. The economics mean that, as bits get sold in the US and many > other places, it won't be in the foreseeable future. Customers care about > popular video sources. Popular content sources have CDNs with local nodes > and/or direct (low cost) connections to their CDN. That's far more > efficient than allowing multicast across WAN links. > > K. Scott Helms > > > > Luke Guillory > Vice President – Technology and Innovation > > > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > Web: www.rtconline.com > Reserve Telecommunications > 100 RTC Dr > > Reserve, LA 70084 > > > > > > > *Disclaimer:* > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by > e-mail if you have received this e-mail by mistake and delete this e-mail > from your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Luke Guillory therefore > does not accept liability for any errors or omissions in the contents of > this message, which arise as a result of e-mail transmission. > > On Tue, Nov 21, 2017 at 8:58 AM, Luke Guillory > wrote: > >> I’m not paying anything for local resources with regards to local edge >> delivery, that’s capital expenditures not MRCs. >> >> Our edge networks aren’t unlimited or free, so while it’s not costing me >> on the transit side there still are cost in terms of upgrades and so on. >> >> My point is that In some networks such as docsis conserving edge >> resources can be helped with multicast. >> >> >> >> Sent from my iPhone >> >> On Nov 21, 2017, at 4:12 AM, Baldur Norddahl > > wrote: >> >> Den 21. nov. 2017 00.42 <20%2017%2000%2042> skrev "Luke Guillory" < >> lguillory at reservetele.com>: >> >> Why would an ISP not want to conserve edge resources? If I’m doing iptv >> I’m >> better off doing multicast which would conserve loads of BW for something >> popular like the Super Bowl. Especially if I’m doing this over docsis. >> >> >> >> You pay for 95th percentile. If that is decided by everyone watching Game >> of Thrones one day, then using the same resources for Super Bowl the next >> day will be for free. >> >> >> >> >> Luke Guillory >> Vice President – Technology and Innovation >> >> >> [cid:imagef9b835.JPG at 242ea556.429501f5] > > >> >> Tel: 985.536.1212 >> Fax: 985.536.0300 >> Email: lguillory at reservetele.com >> Web: www.rtconline.com >> >> Reserve Telecommunications >> 100 RTC Dr >> >> Reserve, LA 70084 >> >> >> >> >> >> Disclaimer: >> The information transmitted, including attachments, is intended only for >> the person(s) or entity to which it is addressed and may contain >> confidential and/or privileged material which should not disseminate, >> distribute or be copied. Please notify Luke Guillory immediately by e-mail >> if you have received this e-mail by mistake and delete this e-mail from >> your system. E-mail transmission cannot be guaranteed to be secure or >> error-free as information could be intercepted, corrupted, lost, destroyed, >> arrive late or incomplete, or contain viruses. Luke Guillory therefore does >> not accept liability for any errors or omissions in the contents of this >> message, which arise as a result of e-mail transmission. >> >> > From lguillory at reservetele.com Tue Nov 21 15:12:18 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 21 Nov 2017 15:12:18 +0000 Subject: Broadcast television in an IP world In-Reply-To: References: <70b2840d-251f-3ad2-0c75-74b89226e584@west.net> <9AE126A8-5F2F-463F-89F9-1B22DA0638EE@reservetele.com> <86FFAE63-66CE-41E2-ADA3-F1124D5C4537@reservetele.com> Message-ID: <8D89F96B7AB1B84F9E049CC7BB91BF5CFB3897F2@RTC-EXCH01.RESERVE.LDS> Doesn’t matter how the broadcaster is transmitting, we take in which ever form that is done and convert it to match our delivery. Question on the pausing comment, I can see that being the case on nDVR setups where the local STB isn’t doing any of the storage. On a setup where there’s no nDVR the box would still be using the same multicast wouldn’t it? I think I saw a multicast vs unicast comparison on a wisp Facebook group talking about what you mention below, was there really an added benefit. Was interesting to see the numbers he had come up with in his use case. From: kscott.helms at gmail.com [mailto:kscott.helms at gmail.com] On Behalf Of K. Scott Helms Sent: Tuesday, November 21, 2017 8:59 AM To: Luke Guillory Cc: Baldur Norddahl; nanog at nanog.org Subject: Re: Broadcast television in an IP world Luke, I think I understand your example but the local broadcaster won't usually (ever?) have the rights to retransmit the Super Bowl over IP. Having said that, what you're describing is exactly what happens already (without multicast) via multiple CDNs. Multicast across the internet isn't feasible (economically) today. Multicast inside of an organization certainly is and is very common. Having said that, even popular content is surprisingly sparse (when we look at flows) and even inside of edge networks (DOCSIS, FTTH, xDSL, etc) it can be surprisingly challenging to make the math work. As soon as someone wants to pause the "big game" or flips to another channel you now have to move their flow to unicast. Even when lots of people are watching the same event the economics aren't as compelling as they might appear initially. On Tue, Nov 21, 2017 at 9:29 AM, Luke Guillory > wrote: The comment I was originally replying to was the following. I’ve said edge resources, nothing about WAN. The content provider (lets say local TV station that broadcasts the Superbowl) can just unicast to the ISP a single stream, and give the ISPs some pizza sized box (lets call it an "Appliance") and that box then provides unicast delivery to each customer watching the Superbowl. Sent from my iPhone On Nov 21, 2017, at 8:22 AM, K. Scott Helms > wrote: It's not helpful for saving resources in DOCSIS (nor any other) edge networks. The economics mean that, as bits get sold in the US and many other places, it won't be in the foreseeable future. Customers care about popular video sources. Popular content sources have CDNs with local nodes and/or direct (low cost) connections to their CDN. That's far more efficient than allowing multicast across WAN links. K. Scott Helms Luke Guillory Vice President – Technology and Innovation [cid:image001.jpg at 01D362A8.269800C0] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. On Tue, Nov 21, 2017 at 8:58 AM, Luke Guillory > wrote: I’m not paying anything for local resources with regards to local edge delivery, that’s capital expenditures not MRCs. Our edge networks aren’t unlimited or free, so while it’s not costing me on the transit side there still are cost in terms of upgrades and so on. My point is that In some networks such as docsis conserving edge resources can be helped with multicast. Sent from my iPhone On Nov 21, 2017, at 4:12 AM, Baldur Norddahl >> wrote: Den 21. nov. 2017 00.42 skrev "Luke Guillory" >>: Why would an ISP not want to conserve edge resources? If I’m doing iptv I’m better off doing multicast which would conserve loads of BW for something popular like the Super Bowl. Especially if I’m doing this over docsis. You pay for 95th percentile. If that is decided by everyone watching Game of Thrones one day, then using the same resources for Super Bowl the next day will be for free. Luke Guillory Vice President – Technology and Innovation [cid:imagef9b835.JPG at 242ea556.429501f5] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From nanog at ics-il.net Tue Nov 21 15:17:52 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 21 Nov 2017 09:17:52 -0600 (CST) Subject: Broadcast television in an IP world In-Reply-To: References: <9AE126A8-5F2F-463F-89F9-1B22DA0638EE@reservetele.com> <86FFAE63-66CE-41E2-ADA3-F1124D5C4537@reservetele.com> Message-ID: <986982405.3722.1511277467942.JavaMail.mhammett@ThunderFuck> Better STBs that cache the stream? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "K. Scott Helms" To: "Luke Guillory" Cc: nanog at nanog.org Sent: Tuesday, November 21, 2017 8:58:38 AM Subject: Re: Broadcast television in an IP world Luke, I think I understand your example but the local broadcaster won't usually (ever?) have the rights to retransmit the Super Bowl over IP. Having said that, what you're describing is exactly what happens already (without multicast) via multiple CDNs. Multicast across the internet isn't feasible (economically) today. Multicast inside of an organization certainly is and is very common. Having said that, even popular content is surprisingly sparse (when we look at flows) and even inside of edge networks (DOCSIS, FTTH, xDSL, etc) it can be surprisingly challenging to make the math work. As soon as someone wants to pause the "big game" or flips to another channel you now have to move their flow to unicast. Even when lots of people are watching the same event the economics aren't as compelling as they might appear initially. On Tue, Nov 21, 2017 at 9:29 AM, Luke Guillory wrote: > The comment I was originally replying to was the following. I’ve said edge > resources, nothing about WAN. > > The content provider (lets say local TV station that broadcasts the > > Superbowl) can just unicast to the ISP a single stream, and give the > > ISPs some pizza sized box (lets call it an "Appliance") and that box > > then provides unicast delivery to each customer watching the Superbowl. > > > > > > *Sent from my iPhone* > > On Nov 21, 2017, at 8:22 AM, K. Scott Helms wrote: > > It's not helpful for saving resources in DOCSIS (nor any other) edge > networks. The economics mean that, as bits get sold in the US and many > other places, it won't be in the foreseeable future. Customers care about > popular video sources. Popular content sources have CDNs with local nodes > and/or direct (low cost) connections to their CDN. That's far more > efficient than allowing multicast across WAN links. > > K. Scott Helms > > > > Luke Guillory > Vice President – Technology and Innovation > > > > Tel: 985.536.1212 <(985)%20536-1212> > Fax: 985.536.0300 <(985)%20536-0300> > Email: lguillory at reservetele.com > Web: www.rtconline.com > Reserve Telecommunications > 100 RTC Dr > > Reserve, LA 70084 > > > > > > > *Disclaimer:* > The information transmitted, including attachments, is intended only for > the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guillory immediately by > e-mail if you have received this e-mail by mistake and delete this e-mail > from your system. E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, destroyed, > arrive late or incomplete, or contain viruses. Luke Guillory therefore > does not accept liability for any errors or omissions in the contents of > this message, which arise as a result of e-mail transmission. > > On Tue, Nov 21, 2017 at 8:58 AM, Luke Guillory > wrote: > >> I’m not paying anything for local resources with regards to local edge >> delivery, that’s capital expenditures not MRCs. >> >> Our edge networks aren’t unlimited or free, so while it’s not costing me >> on the transit side there still are cost in terms of upgrades and so on. >> >> My point is that In some networks such as docsis conserving edge >> resources can be helped with multicast. >> >> >> >> Sent from my iPhone >> >> On Nov 21, 2017, at 4:12 AM, Baldur Norddahl > > wrote: >> >> Den 21. nov. 2017 00.42 skrev "Luke Guillory" > >: >> >> Why would an ISP not want to conserve edge resources? If I’m doing iptv >> I’m >> better off doing multicast which would conserve loads of BW for something >> popular like the Super Bowl. Especially if I’m doing this over docsis. >> >> >> >> You pay for 95th percentile. If that is decided by everyone watching Game >> of Thrones one day, then using the same resources for Super Bowl the next >> day will be for free. >> >> >> >> >> Luke Guillory >> Vice President – Technology and Innovation >> >> >> [cid:imagef9b835.JPG at 242ea556.429501f5] > > >> >> Tel: 985.536.1212 >> Fax: 985.536.0300 >> Email: lguillory at reservetele.com >> Web: www.rtconline.com >> >> Reserve Telecommunications >> 100 RTC Dr >> >> Reserve, LA 70084 >> >> >> >> >> >> Disclaimer: >> The information transmitted, including attachments, is intended only for >> the person(s) or entity to which it is addressed and may contain >> confidential and/or privileged material which should not disseminate, >> distribute or be copied. Please notify Luke Guillory immediately by e-mail >> if you have received this e-mail by mistake and delete this e-mail from >> your system. E-mail transmission cannot be guaranteed to be secure or >> error-free as information could be intercepted, corrupted, lost, destroyed, >> arrive late or incomplete, or contain viruses. Luke Guillory therefore does >> not accept liability for any errors or omissions in the contents of this >> message, which arise as a result of e-mail transmission. >> >> > From lguillory at reservetele.com Tue Nov 21 15:31:58 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Tue, 21 Nov 2017 15:31:58 +0000 Subject: Broadcast television in an IP world In-Reply-To: <986982405.3722.1511277467942.JavaMail.mhammett@ThunderFuck> References: <9AE126A8-5F2F-463F-89F9-1B22DA0638EE@reservetele.com> <86FFAE63-66CE-41E2-ADA3-F1124D5C4537@reservetele.com> , <986982405.3722.1511277467942.JavaMail.mhammett@ThunderFuck> Message-ID: <2A1BD995-847E-4715-B618-A0FCE7024FAC@reservetele.com> A local dvr caches the channel when someone hits pause, on our multi room dvrs it’ll keep 30 minutes of programming. Sent from my iPhone On Nov 21, 2017, at 9:27 AM, Mike Hammett > wrote: Better STBs that cache the stream? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com Luke Guillory Vice President – Technology and Innovation [cid:image3d0842.JPG at 83e42971.43a5f684] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ----- Original Message ----- From: "K. Scott Helms" > To: "Luke Guillory" > Cc: nanog at nanog.org Sent: Tuesday, November 21, 2017 8:58:38 AM Subject: Re: Broadcast television in an IP world Luke, I think I understand your example but the local broadcaster won't usually (ever?) have the rights to retransmit the Super Bowl over IP. Having said that, what you're describing is exactly what happens already (without multicast) via multiple CDNs. Multicast across the internet isn't feasible (economically) today. Multicast inside of an organization certainly is and is very common. Having said that, even popular content is surprisingly sparse (when we look at flows) and even inside of edge networks (DOCSIS, FTTH, xDSL, etc) it can be surprisingly challenging to make the math work. As soon as someone wants to pause the "big game" or flips to another channel you now have to move their flow to unicast. Even when lots of people are watching the same event the economics aren't as compelling as they might appear initially. On Tue, Nov 21, 2017 at 9:29 AM, Luke Guillory > wrote: The comment I was originally replying to was the following. I’ve said edge resources, nothing about WAN. The content provider (lets say local TV station that broadcasts the Superbowl) can just unicast to the ISP a single stream, and give the ISPs some pizza sized box (lets call it an "Appliance") and that box then provides unicast delivery to each customer watching the Superbowl. *Sent from my iPhone* On Nov 21, 2017, at 8:22 AM, K. Scott Helms > wrote: It's not helpful for saving resources in DOCSIS (nor any other) edge networks. The economics mean that, as bits get sold in the US and many other places, it won't be in the foreseeable future. Customers care about popular video sources. Popular content sources have CDNs with local nodes and/or direct (low cost) connections to their CDN. That's far more efficient than allowing multicast across WAN links. K. Scott Helms Luke Guillory Vice President – Technology and Innovation Tel: 985.536.1212 <(985)%20536-1212> Fax: 985.536.0300 <(985)%20536-0300> Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 *Disclaimer:* The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. On Tue, Nov 21, 2017 at 8:58 AM, Luke Guillory > wrote: I’m not paying anything for local resources with regards to local edge delivery, that’s capital expenditures not MRCs. Our edge networks aren’t unlimited or free, so while it’s not costing me on the transit side there still are cost in terms of upgrades and so on. My point is that In some networks such as docsis conserving edge resources can be helped with multicast. Sent from my iPhone On Nov 21, 2017, at 4:12 AM, Baldur Norddahl > wrote: Den 21. nov. 2017 00.42 skrev "Luke Guillory" >: Why would an ISP not want to conserve edge resources? If I’m doing iptv I’m better off doing multicast which would conserve loads of BW for something popular like the Super Bowl. Especially if I’m doing this over docsis. You pay for 95th percentile. If that is decided by everyone watching Game of Thrones one day, then using the same resources for Super Bowl the next day will be for free. Luke Guillory Vice President – Technology and Innovation [cid:imagef9b835.JPG at 242ea556.429501f5] Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From baldur.norddahl at gmail.com Tue Nov 21 16:52:09 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 21 Nov 2017 17:52:09 +0100 Subject: Broadcast television in an IP world In-Reply-To: <929958564.3695.1511276945863.JavaMail.mhammett@ThunderFuck> References: <9AE126A8-5F2F-463F-89F9-1B22DA0638EE@reservetele.com> <86FFAE63-66CE-41E2-ADA3-F1124D5C4537@reservetele.com> <929958564.3695.1511276945863.JavaMail.mhammett@ThunderFuck> Message-ID: Den 21. nov. 2017 16.20 skrev "Mike Hammett" : Unicasting what everyone watches live on a random evening would use significantly more bandwidth than Game of Thrones or whatever OTT drop. Magnitudes more. It wouldn't even be in the same ballpark. I agree as of this moment however that will change. Also note that our customers do 100% of their TV as unicast OTT because that is the only thing we offer. This does not cause nearly as much problems as you would expect. From nanog at ics-il.net Tue Nov 21 16:58:32 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 21 Nov 2017 10:58:32 -0600 (CST) Subject: Broadcast television in an IP world In-Reply-To: References: <86FFAE63-66CE-41E2-ADA3-F1124D5C4537@reservetele.com> <929958564.3695.1511276945863.JavaMail.mhammett@ThunderFuck> Message-ID: <1116986333.3779.1511283511588.JavaMail.mhammett@ThunderFuck> of the TV they use... through you. That doesn't count OTA, cable, satellite, etc. It won't change significantly any time soon. I know things are changing, but it'll still take five or ten years for those changes to significantly change traffic patterns. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Baldur Norddahl" To: nanog at nanog.org Sent: Tuesday, November 21, 2017 10:52:09 AM Subject: Re: Broadcast television in an IP world Den 21. nov. 2017 16.20 skrev "Mike Hammett" : Unicasting what everyone watches live on a random evening would use significantly more bandwidth than Game of Thrones or whatever OTT drop. Magnitudes more. It wouldn't even be in the same ballpark. I agree as of this moment however that will change. Also note that our customers do 100% of their TV as unicast OTT because that is the only thing we offer. This does not cause nearly as much problems as you would expect. From brandon at rd.bbc.co.uk Tue Nov 21 18:12:00 2017 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Tue, 21 Nov 2017 18:12:00 +0000 Subject: Broadcast television in an IP world In-Reply-To: <929958564.3695.1511276945863.JavaMail.mhammett@ThunderFuck> References: <9AE126A8-5F2F-463F-89F9-1B22DA0638EE@reservetele.com> <86FFAE63-66CE-41E2-ADA3-F1124D5C4537@reservetele.com> <929958564.3695.1511276945863.JavaMail.mhammett@ThunderFuck> Message-ID: <20171121181159.GA15975@sunf10.rd.bbc.co.uk> On Tue Nov 21, 2017 at 09:09:06AM -0600, Mike Hammett wrote: > Unicasting what everyone watches live on a random evening would > use significantly more bandwidth than Game of Thrones or whatever > OTT drop. Magnitudes more. It wouldn't even be in the same ballpark. In the UK our VoD (branded iPlayer) is approx 5% of consumption, the rest is linear broadcast channels. While we're planning for the day it is 100% IP there is quite a lot to do before we get there. One thing we've tested is the DASM extension to DASH streaming to allow clients to transparently consume unicast or multicast. Most would be unicast consumers but some networks use multicast for tv channel delivery. This allows their clients to adapt (and mix so for rewind can switch to unicast, the watch this live programme from the beginning buttton is quite popular) rather than having a different client (lots of caveats in there) Today our CDNs would not handle a popular programme with a 15M audience. They could be scaled up and some ISPs have placed CDN nodes closer to their edge to help that. Others already have internal multicast or are working on it. We'll use whatever works best. brandon From baldur.norddahl at gmail.com Tue Nov 21 18:46:43 2017 From: baldur.norddahl at gmail.com (Baldur Norddahl) Date: Tue, 21 Nov 2017 19:46:43 +0100 Subject: Broadcast television in an IP world In-Reply-To: <1116986333.3779.1511283511588.JavaMail.mhammett@ThunderFuck> References: <86FFAE63-66CE-41E2-ADA3-F1124D5C4537@reservetele.com> <929958564.3695.1511276945863.JavaMail.mhammett@ThunderFuck> <1116986333.3779.1511283511588.JavaMail.mhammett@ThunderFuck> Message-ID: I am not going to guess on a timeframe. I would like to point out that the youth ignore TV. They no longer have TVs on their rooms. It is all on smartphones or tablets these days. Even with the family in a living room, everyone might be sitting with their own device doing their own thing. We have a significant share of the customers that have no other TV than OTT streaming. Myself included. Here (Denmark) almost all TV channels are available as OTT streaming. The free national broadcast TV is also available for streaming (for free). With an Apple TV you can do all the same things that you can do with OTA, cable or satellite. Cheaper (*) and more convenient too. Far from everyone has discovered this yet, but since we cater to people that are cable cutters, a larger than usual share of our customers is doing exactly this. (*) I believe the OTT solutions are cheaper as long you do not want a lot of sport programming. If you do want sport I believe it is more expensive but you also have more options and content available. Regards, Baldur Den 21/11/2017 kl. 17.58 skrev Mike Hammett: > of the TV they use... through you. That doesn't count OTA, cable, satellite, etc. > > It won't change significantly any time soon. I know things are changing, but it'll still take five or ten years for those changes to significantly change traffic patterns. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Baldur Norddahl" > To: nanog at nanog.org > Sent: Tuesday, November 21, 2017 10:52:09 AM > Subject: Re: Broadcast television in an IP world > > Den 21. nov. 2017 16.20 skrev "Mike Hammett" : > > Unicasting what everyone watches live on a random evening would use > significantly more bandwidth than Game of Thrones or whatever OTT drop. > Magnitudes more. It wouldn't even be in the same ballpark. > > > > I agree as of this moment however that will change. Also note that our > customers do 100% of their TV as unicast OTT because that is the only thing > we offer. This does not cause nearly as much problems as you would expect. > From gjshep at gmail.com Tue Nov 21 17:31:41 2017 From: gjshep at gmail.com (Greg Shepherd) Date: Tue, 21 Nov 2017 09:31:41 -0800 Subject: Broadcast television in an IP world In-Reply-To: <1116986333.3779.1511283511588.JavaMail.mhammett@ThunderFuck> References: <86FFAE63-66CE-41E2-ADA3-F1124D5C4537@reservetele.com> <929958564.3695.1511276945863.JavaMail.mhammett@ThunderFuck> <1116986333.3779.1511283511588.JavaMail.mhammett@ThunderFuck> Message-ID: Multicast is not PIM. PIM is dead. https://datatracker.ietf.org/doc/rfc8279/ Significantly reduces the cost and complexity of network replication. Soon to be on the standards track. What can't BIER do? -shep On Tue, Nov 21, 2017 at 8:58 AM, Mike Hammett wrote: > of the TV they use... through you. That doesn't count OTA, cable, > satellite, etc. > > It won't change significantly any time soon. I know things are changing, > but it'll still take five or ten years for those changes to significantly > change traffic patterns. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Baldur Norddahl" > To: nanog at nanog.org > Sent: Tuesday, November 21, 2017 10:52:09 AM > Subject: Re: Broadcast television in an IP world > > Den 21. nov. 2017 16.20 skrev "Mike Hammett" : > > Unicasting what everyone watches live on a random evening would use > significantly more bandwidth than Game of Thrones or whatever OTT drop. > Magnitudes more. It wouldn't even be in the same ballpark. > > > > I agree as of this moment however that will change. Also note that our > customers do 100% of their TV as unicast OTT because that is the only thing > we offer. This does not cause nearly as much problems as you would expect. > > From nanog at ics-il.net Tue Nov 21 19:08:35 2017 From: nanog at ics-il.net (Mike Hammett) Date: Tue, 21 Nov 2017 13:08:35 -0600 (CST) Subject: Broadcast television in an IP world In-Reply-To: References: <929958564.3695.1511276945863.JavaMail.mhammett@ThunderFuck> <1116986333.3779.1511283511588.JavaMail.mhammett@ThunderFuck> Message-ID: <824667542.4165.1511291314159.JavaMail.mhammett@ThunderFuck> I'm not doubting OTT is popular. There's just an awful lot of people that have zero interest (or ability) to use OTT. They will continue to consume entertainment linearly, regardless of the mechanism used to deliver it. People in NANOG often forget that most people aren't like us. Heck, most people in NANOG forget that not every network is like their network. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Baldur Norddahl" To: nanog at nanog.org Sent: Tuesday, November 21, 2017 12:46:43 PM Subject: Re: Broadcast television in an IP world I am not going to guess on a timeframe. I would like to point out that the youth ignore TV. They no longer have TVs on their rooms. It is all on smartphones or tablets these days. Even with the family in a living room, everyone might be sitting with their own device doing their own thing. We have a significant share of the customers that have no other TV than OTT streaming. Myself included. Here (Denmark) almost all TV channels are available as OTT streaming. The free national broadcast TV is also available for streaming (for free). With an Apple TV you can do all the same things that you can do with OTA, cable or satellite. Cheaper (*) and more convenient too. Far from everyone has discovered this yet, but since we cater to people that are cable cutters, a larger than usual share of our customers is doing exactly this. (*) I believe the OTT solutions are cheaper as long you do not want a lot of sport programming. If you do want sport I believe it is more expensive but you also have more options and content available. Regards, Baldur Den 21/11/2017 kl. 17.58 skrev Mike Hammett: > of the TV they use... through you. That doesn't count OTA, cable, satellite, etc. > > It won't change significantly any time soon. I know things are changing, but it'll still take five or ten years for those changes to significantly change traffic patterns. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Baldur Norddahl" > To: nanog at nanog.org > Sent: Tuesday, November 21, 2017 10:52:09 AM > Subject: Re: Broadcast television in an IP world > > Den 21. nov. 2017 16.20 skrev "Mike Hammett" : > > Unicasting what everyone watches live on a random evening would use > significantly more bandwidth than Game of Thrones or whatever OTT drop. > Magnitudes more. It wouldn't even be in the same ballpark. > > > > I agree as of this moment however that will change. Also note that our > customers do 100% of their TV as unicast OTT because that is the only thing > we offer. This does not cause nearly as much problems as you would expect. > From aaron1 at gvtc.com Wed Nov 22 17:51:19 2017 From: aaron1 at gvtc.com (Aaron Gould) Date: Wed, 22 Nov 2017 11:51:19 -0600 Subject: ospf database size - affects that underlying transport mtu might have Message-ID: <002a01d363ba$80b32f90$82198eb0$@gvtc.com> This is a *single area* ospf environment, that has been stable for years.. But now suddenly is having issues with new ospf neightbor adjacencies , which are riding a 3rd party transport network Anyone ever experienced anything strange with underlying transport network mtu possibly causing ospf neighbor adjacency to be broken ? I'm asking if the underlying 3rd party transport layer 2 network has a smaller mtu than the endpoint ospf ip interface have, could this cause those ospf neighbors to not fully establish ? .and I'm also asking this if the single ospf area has grown large enough to cause some sort of initial database packet to be larger than that underlying 3rd party mtu is providing -Aaron From jay at west.net Wed Nov 22 18:26:13 2017 From: jay at west.net (Jay Hennigan) Date: Wed, 22 Nov 2017 10:26:13 -0800 Subject: ospf database size - affects that underlying transport mtu might have In-Reply-To: <002a01d363ba$80b32f90$82198eb0$@gvtc.com> References: <002a01d363ba$80b32f90$82198eb0$@gvtc.com> Message-ID: <7c97bf60-5257-b8ab-354f-a0f9381f9d83@west.net> On 11/22/17 9:51 AM, Aaron Gould wrote: > This is a *single area* ospf environment, that has been stable for years.. > But now suddenly is having issues with new ospf neightbor adjacencies , > which are riding a 3rd party transport network > > Anyone ever experienced anything strange with underlying transport network > mtu possibly causing ospf neighbor adjacency to be broken ? > I'm asking if > the underlying 3rd party transport layer 2 network has a smaller mtu than > the endpoint ospf ip interface have, could this cause those ospf neighbors > to not fully establish ? Yes. Easy to check with a ping sweeping a range of sizes and DF set. > and I'm also asking this if the single ospf area > has grown large enough to cause some sort of initial database packet to be > larger than that underlying 3rd party mtu is providing Not likely. How many routers and are things relatively stable in terms of routes changing? -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From kscotthelms at gmail.com Tue Nov 21 19:28:35 2017 From: kscotthelms at gmail.com (K. Scott Helms) Date: Tue, 21 Nov 2017 14:28:35 -0500 Subject: Broadcast television in an IP world In-Reply-To: <824667542.4165.1511291314159.JavaMail.mhammett@ThunderFuck> References: <929958564.3695.1511276945863.JavaMail.mhammett@ThunderFuck> <1116986333.3779.1511283511588.JavaMail.mhammett@ThunderFuck> <824667542.4165.1511291314159.JavaMail.mhammett@ThunderFuck> Message-ID: Mike, While that's true today it's changing rapidly. Linear viewership is, depending on your take on things, either in the beginning or the middle of it's long tail phase. You're right in that we'll have people using linear viewing habits for a long time, but that model only looks sustainable over the long term for either very large MSOs, the digital satellite operators, and OTT offerings that offer a similar experience. There's very little investing in efficiencies for linear content as this point, other than how it gets replaced. Part of the change is technical, part generational changes, and part overreach on the part of some of the content owners. Scott Helms On Tue, Nov 21, 2017 at 2:08 PM, Mike Hammett wrote: > I'm not doubting OTT is popular. There's just an awful lot of people that > have zero interest (or ability) to use OTT. They will continue to consume > entertainment linearly, regardless of the mechanism used to deliver it. > > > People in NANOG often forget that most people aren't like us. Heck, most > people in NANOG forget that not every network is like their network. > > > > > ----- > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > ----- Original Message ----- > > From: "Baldur Norddahl" > To: nanog at nanog.org > Sent: Tuesday, November 21, 2017 12:46:43 PM > Subject: Re: Broadcast television in an IP world > > I am not going to guess on a timeframe. I would like to point out that > the youth ignore TV. They no longer have TVs on their rooms. It is all > on smartphones or tablets these days. Even with the family in a living > room, everyone might be sitting with their own device doing their own > thing. > > We have a significant share of the customers that have no other TV than > OTT streaming. Myself included. Here (Denmark) almost all TV channels > are available as OTT streaming. The free national broadcast TV is also > available for streaming (for free). > > With an Apple TV you can do all the same things that you can do with > OTA, cable or satellite. Cheaper (*) and more convenient too. Far from > everyone has discovered this yet, but since we cater to people that are > cable cutters, a larger than usual share of our customers is doing > exactly this. > > (*) I believe the OTT solutions are cheaper as long you do not want a > lot of sport programming. If you do want sport I believe it is more > expensive but you also have more options and content available. > > Regards, > > Baldur > > > Den 21/11/2017 kl. 17.58 skrev Mike Hammett: > > of the TV they use... through you. That doesn't count OTA, cable, > satellite, etc. > > > > It won't change significantly any time soon. I know things are changing, > but it'll still take five or ten years for those changes to significantly > change traffic patterns. > > > > > > > > > > ----- > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > ----- Original Message ----- > > > > From: "Baldur Norddahl" > > To: nanog at nanog.org > > Sent: Tuesday, November 21, 2017 10:52:09 AM > > Subject: Re: Broadcast television in an IP world > > > > Den 21. nov. 2017 16.20 skrev "Mike Hammett" : > > > > Unicasting what everyone watches live on a random evening would use > > significantly more bandwidth than Game of Thrones or whatever OTT drop. > > Magnitudes more. It wouldn't even be in the same ballpark. > > > > > > > > I agree as of this moment however that will change. Also note that our > > customers do 100% of their TV as unicast OTT because that is the only > thing > > we offer. This does not cause nearly as much problems as you would > expect. > > > > > From adam at nectolab.io Wed Nov 22 18:25:56 2017 From: adam at nectolab.io (Adam Montgomery) Date: Wed, 22 Nov 2017 18:25:56 +0000 Subject: Amazon Streaming Department Message-ID: Jason, we had a similar issue as well. I was able to get in contact with some helpful people at Amazon who got it fixed for us. I passed your info along to them. If anyone else is having the same issue, shoot me a message and I'll pass your info along as well. Adam --------------------- Hello all, A while back I wrote in regarding an update on Netflix services / our IP addresses being blocked. I had helpful feedback in getting this resolved. Does anyone have a contact at Amazon for resolving IP blacklist issues on their Amazon Prime / streaming services? I have contacted their Customer Service, but they aren't very easy to work with. Thank you! Best Regards, Jason Canady Unlimited Net, LLC From Thomas.Edwards at fox.com Wed Nov 22 19:04:39 2017 From: Thomas.Edwards at fox.com (Thomas Edwards) Date: Wed, 22 Nov 2017 19:04:39 +0000 Subject: Broadcast television in an IP world Message-ID: <4B8F8DC6-FF3A-46DF-B805-2D5F0E01C817@contoso.com> Of potential interest to NANOG members, a key element of the new digital TV OTA standard, ATSC 3.0 (besides improved efficiency/flexibility of modulation, 4K, HEVC video coding, AC-4 immersive audio, high dynamic range/wide color gamut), is the expectation that it will be typically be viewed on an Internet connected TV, thus allowing for a composition of OTA content with interactive & personalized Internet-delivered services. This hybrid OTA/OTT concept has already been trialed in parts of Europe using the “HbbTV” (hybrid broadband-broadcast TV) standard. This URL describes some of the potential capabilities of ATSC 3.0 in this area: https://nabpilot.org/next-generation-tv-home-gateway/ ATSC 3.0 will be deployed early next year in Phoenix, AZ as a test market, with 10 stations participating, including affiliates of the four largest TV networks. At the same time, many live local television station broadcasts are already available via OTT. This can be done either directly by a network & affiliates, such as CBS All Access, or through a distributor (which we call a Digital MVPD or “DMVPD”) which now include Sling TV, Playstation Vue, DirecTV Now, YouTube TV, Hulu with Live TV, and Fubo TV. To aid in achieving the scale required for mass OTT, I’d like to point out two efforts by the Streaming Video Alliance. The first is the Open Caching initiative. As you may know, some large OTT content distributors have offered to deploy content caches in end-user ISPs (such as Google Global Cache or Netflix Open Connect), but to date they have been proprietary to that distributor. Open Caching from the SVA establishes the basic architectural guidelines for implementation of a non-proprietary, open caching system: https://www.streamingvideoalliance.org/technical-work/working-groups/open-caching/ Another effort is Multicast ABR. This is generally imagined as the use of multicast within an end-user ISP. There was recently a PoC to demonstrate live 4K streaming using the CableLabs Multicast ABR architecture based on RFC 5740 NORM (NACK-Oriented Reliable Multicast). This utilizes the home gateway to receive the live multicast stream, and “convert” the stream to unicast HTTP for last-foot delivery. https://www.streamingvideoalliance.org/2017/07/31/multicast-abr-poc/ https://apps.cablelabs.com/specification/ip-multicast-adaptive-bit-rate-architecture-technical-report -Thomas -- Thomas Edwards FOX Networks Engineering & Operations VP Engineering & Development thomas.edwards at fox.com 10201 W Pico Blvd Los Angeles, CA 90035 From jfmezei_nanog at vaxination.ca Wed Nov 22 20:35:00 2017 From: jfmezei_nanog at vaxination.ca (Jean-Francois Mezei) Date: Wed, 22 Nov 2017 15:35:00 -0500 Subject: Definition of ISP vs Transit provider Message-ID: The FCC is about to reclassify "Broadband Internet Access Service" as an information service instead of Telecommunications Service. This prombpted the following question which isn't about the FCC action per say. This is about how does one define Transit provider vs ISP ? Cogent for instance acts as a transit provider to other networks but also sells connectivity to companies. Peer1 in Canada used to sell "transit" to a then small emerging ISP, but as its sole transit provider, provided the BGP management as well as peering at Torix. Is the service to the ISP still called "transit" ? Or would ISP be defined as the organsation which assigns IPs to end users via PPPoE of DHCP ? One could argue that a network which assigns 4 or less IPs per customer would be an ISP. But what about IPv6 where the ISP could give each end user a /64 ? Just curious to see if there are agreed upon definitions from the network operators's point of view. I note that large companies tend to do everything from transit, to residential ISP, business ISP, libraries, airports etc. For Bell Canada, it is almost all under AS577. So separating what is telecom and what is information becomes more "interesting". As a point of reference this is what I *think* the FCC defines as an ISP: ## 23. Broadband Internet access service also does not include virtual private network (VPN) services, content delivery networks (CDNs), hosting or data storage services, or Internet backbone services (if those services are separate from broadband Internet access service), consistent with past Commission precedent.69 The Commission has historically distinguished these services from “mass market” services, as they do not provide the capability to transmit data to and receive data from all or substantially all Internet endpoints.70 We do not disturb that finding here. 24. Finally, we observe that to the extent that coffee shops, bookstores, airlines, private end- user networks such as libraries and universities, and other businesses acquire broadband Internet access service from a broadband provider to enable patrons to access the Internet from their respective establishments, provision of such service by the premise operator would not itself be considered a broadband Internet access service unless it was offered to patrons as a retail mass market service, as we define it here.71 Likewise, when a user employs, for example, a wireless router or a Wi-Fi hotspot to create a personal Wi-Fi network that is not intentionally offered for the benefit of others, he or she is not offering a broadband Internet access service, under our definition, because the user is not marketing and selling such service to residential customers, small business, and other end-user customers such as schools and libraries. ## The full 210 proposed FCC decision is at: https://apps.fcc.gov/edocs_public/attachmatch/DOC-347927A1.pdf From javier at advancedmachines.us Wed Nov 22 21:29:29 2017 From: javier at advancedmachines.us (Javier J) Date: Wed, 22 Nov 2017 16:29:29 -0500 Subject: Definition of ISP vs Transit provider In-Reply-To: References: Message-ID: I can't seem to find the answer for this. But I'm curious as to what exactly is proposed. On Wed, Nov 22, 2017 at 3:35 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > The FCC is about to reclassify "Broadband Internet Access Service" as an > information service instead of Telecommunications Service. This > prombpted the following question which isn't about the FCC action per say. > > This is about how does one define Transit provider vs ISP ? > > Cogent for instance acts as a transit provider to other networks but > also sells connectivity to companies. > > Peer1 in Canada used to sell "transit" to a then small emerging ISP, but > as its sole transit provider, provided the BGP management as well as > peering at Torix. Is the service to the ISP still called "transit" ? > > Or would ISP be defined as the organsation which assigns IPs to end > users via PPPoE of DHCP ? > > One could argue that a network which assigns 4 or less IPs per customer > would be an ISP. But what about IPv6 where the ISP could give each end > user a /64 ? > > Just curious to see if there are agreed upon definitions from the > network operators's point of view. > > I note that large companies tend to do everything from transit, to > residential ISP, business ISP, libraries, airports etc. For Bell Canada, > it is almost all under AS577. So separating what is telecom and what is > information becomes more "interesting". > > > > > > > > > > As a point of reference this is what I *think* the FCC defines as an ISP: > > ## > 23. Broadband Internet access service also does not include virtual > private network (VPN) services, content delivery networks (CDNs), > hosting or data storage services, or Internet backbone services (if > those services are separate from broadband Internet access service), > consistent with past Commission precedent.69 The Commission has > historically distinguished these services from “mass market” services, > as they do not provide the capability to transmit data to and receive > data from all or substantially all Internet endpoints.70 We do not > disturb that finding here. > > 24. Finally, we observe that to the extent that coffee shops, > bookstores, airlines, private end- user networks such as libraries and > universities, and other businesses acquire broadband Internet access > service from a broadband provider to enable patrons to access the > Internet from their respective establishments, provision of such service > by the premise operator would not itself be considered a broadband > Internet access service unless it was offered to patrons as a retail > mass market service, as we define it here.71 Likewise, when a user > employs, for example, a wireless router or a Wi-Fi hotspot to create a > personal Wi-Fi network that is not intentionally offered for the benefit > of others, he or she is not offering a broadband Internet access > service, under our definition, because the user is not marketing and > selling such service to residential customers, small business, and other > end-user customers such as schools and libraries. > ## > > The full 210 proposed FCC decision is at: > https://apps.fcc.gov/edocs_public/attachmatch/DOC-347927A1.pdf > > From surfer at mauigateway.com Wed Nov 22 21:43:32 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 22 Nov 2017 13:43:32 -0800 Subject: Definition of ISP vs Transit provider Message-ID: <20171122134332.30FF7D37@m0117458.ppops.net> --- jfmezei_nanog at vaxination.ca wrote: From: Jean-Francois Mezei This is about how does one define Transit provider vs ISP ? Just curious to see if there are agreed upon definitions from the network operators's point of view. -------------------------------------- Different parts of the same company? ;-) Maybe transit is transit *only* and no individual end users. Their end users are networks with business networks attached only. But, then individual end users have business networks in their home, too. So, blurry at best. scott From bill at herrin.us Wed Nov 22 21:50:49 2017 From: bill at herrin.us (William Herrin) Date: Wed, 22 Nov 2017 16:50:49 -0500 Subject: Definition of ISP vs Transit provider In-Reply-To: References: Message-ID: On Wed, Nov 22, 2017 at 3:35 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: > The FCC is about to reclassify "Broadband Internet Access Service" as an > information service instead of Telecommunications Service. This > prombpted the following question which isn't about the FCC action per say. > > This is about how does one define Transit provider vs ISP ? Corn on the cob vs. corn in a can. > Just curious to see if there are agreed upon definitions from the > network operators's point of view. No. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From Thomas.Edwards at fox.com Wed Nov 22 22:14:03 2017 From: Thomas.Edwards at fox.com (Thomas Edwards) Date: Wed, 22 Nov 2017 22:14:03 +0000 Subject: Definition of ISP vs Transit provider In-Reply-To: References: Message-ID: Regarding transit and traffic exchange, in today’s FCC Declaratory Ruling: 166. Deregulating Internet Traffic Exchange. Today, we return to the pre-Title II Order status quo by classifying broadband Internet access service as an information service, and in doing so, reverse the extension of Title II authority to Internet traffic exchange arrangements.603 There is no dispute that ISPs, backbone transit providers, and large edge providers are sophisticated, well-capitalized businesses.604 Indeed, the Title II Order acknowledged as much,605 and refused to impose “prescriptive rules” or even “draw policy conclusions concerning new paid Internet traffic arrangements.”606 Notwithstanding, the Title II Order cast a shadow on new arrangements in this sector by applying a range of common carrier requirements to Internet traffic exchange. 167. We believe that applying Title II to Internet traffic exchange arrangements was unnecessary and is likely to inhibit competition and innovation. We find that freeing Internet traffic exchange arrangements from burdensome government regulation, and allowing market forces to discipline this emerging market is the better course.607 Indeed, the cost of Internet transit fell over 99 percent on a cost-per-megabit basis from 2005 to 2015.608 168. We welcome the growth of alternative Internet traffic exchange arrangements, including direct interconnection, CDNs, and other innovative efforts. All parties appear to agree that direct interconnection has benefited consumers by reducing congestion, increasing speeds, and housing content closer to consumers, and allowed ISPs to better manage their networks.609 CDNs play a similar role.610 We believe that market dynamics, not Title II regulation, allowed these diverse arrangements to thrive.611 Our decision to reclassify broadband Internet access service as an information service, and to remove Title II utility-style regulation from Internet traffic exchange, will spur further innovation in this market.612 Returning to the pre-Title II Order light-touch framework will also eliminate the asymmetrical regulatory treatment of parties to Internet traffic exchange arrangements.613 As NTCA explains, the Title II Order imposed a one-sided interconnection duty upon last-mile ISPs—even though, especially in rural areas, “many ISPs are a tiny fraction of the size of upstream middle mile and transit networks or content and edge providers.”614 The record reflects that the asymmetric regulation reduced incentives to share costs, and we anticipate that eliminating one-sided regulation of Internet traffic exchange and restoring regulatory parity among sophisticated commercial entities will allow the parties to more efficiently allocate the costs arising from increased demands on the network.615 -Thomas -- Thomas Edwards FOX Networks Engineering & Operations VP Engineering & Development thomas.edwards at fox.com 10201 W Pico Blvd Los Angeles, CA 90035 On 11/22/17, 12:36 PM, "NANOG on behalf of Jean-Francois Mezei" wrote: The FCC is about to reclassify "Broadband Internet Access Service" as an information service instead of Telecommunications Service. This prombpted the following question which isn't about the FCC action per say. This is about how does one define Transit provider vs ISP ? Cogent for instance acts as a transit provider to other networks but also sells connectivity to companies. Peer1 in Canada used to sell "transit" to a then small emerging ISP, but as its sole transit provider, provided the BGP management as well as peering at Torix. Is the service to the ISP still called "transit" ? Or would ISP be defined as the organsation which assigns IPs to end users via PPPoE of DHCP ? One could argue that a network which assigns 4 or less IPs per customer would be an ISP. But what about IPv6 where the ISP could give each end user a /64 ? Just curious to see if there are agreed upon definitions from the network operators's point of view. I note that large companies tend to do everything from transit, to residential ISP, business ISP, libraries, airports etc. For Bell Canada, it is almost all under AS577. So separating what is telecom and what is information becomes more "interesting". As a point of reference this is what I *think* the FCC defines as an ISP: ## 23. Broadband Internet access service also does not include virtual private network (VPN) services, content delivery networks (CDNs), hosting or data storage services, or Internet backbone services (if those services are separate from broadband Internet access service), consistent with past Commission precedent.69 The Commission has historically distinguished these services from “mass market” services, as they do not provide the capability to transmit data to and receive data from all or substantially all Internet endpoints.70 We do not disturb that finding here. 24. Finally, we observe that to the extent that coffee shops, bookstores, airlines, private end- user networks such as libraries and universities, and other businesses acquire broadband Internet access service from a broadband provider to enable patrons to access the Internet from their respective establishments, provision of such service by the premise operator would not itself be considered a broadband Internet access service unless it was offered to patrons as a retail mass market service, as we define it here.71 Likewise, when a user employs, for example, a wireless router or a Wi-Fi hotspot to create a personal Wi-Fi network that is not intentionally offered for the benefit of others, he or she is not offering a broadband Internet access service, under our definition, because the user is not marketing and selling such service to residential customers, small business, and other end-user customers such as schools and libraries. ## The full 210 proposed FCC decision is at: https://urldefense.proofpoint.com/v2/url?u=https-3A__apps.fcc.gov_edocs-5Fpublic_attachmatch_DOC-2D347927A1.pdf&d=DwIDaQ&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=GHmzQ0km_bzDFxKtOEAcIzvU7zev3i1P1jY7qFGLy4k&s=4FtLgoZ1nfkDyBnfDz0h5PejWPDIromH__9WAl7s2hY&e= From mfidelman at meetinghouse.net Thu Nov 23 04:06:58 2017 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 22 Nov 2017 21:06:58 -0700 Subject: Definition of ISP vs Transit provider In-Reply-To: References: Message-ID: On 11/22/17 2:50 PM, William Herrin wrote: > On Wed, Nov 22, 2017 at 3:35 PM, Jean-Francois Mezei < > jfmezei_nanog at vaxination.ca> wrote: >> The FCC is about to reclassify "Broadband Internet Access Service" as an >> information service instead of Telecommunications Service. This >> prombpted the following question which isn't about the FCC action per say. >> >> This is about how does one define Transit provider vs ISP ? For that matter, how does one distinguish between someone delivering IP packets, vs. someone offering frame relay, or ATM - which are clearly telecom services? Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From lguillory at reservetele.com Thu Nov 23 04:24:58 2017 From: lguillory at reservetele.com (Luke Guillory) Date: Thu, 23 Nov 2017 04:24:58 +0000 Subject: Definition of ISP vs Transit provider In-Reply-To: References: , Message-ID: Those normally come with ASRs and a tariff from the regulated side of things. At least from my experience anyway. Sent from my iPad On Nov 22, 2017, at 10:08 PM, Miles Fidelman > wrote: On 11/22/17 2:50 PM, William Herrin wrote: On Wed, Nov 22, 2017 at 3:35 PM, Jean-Francois Mezei < jfmezei_nanog at vaxination.ca> wrote: The FCC is about to reclassify "Broadband Internet Access Service" as an information service instead of Telecommunications Service. This prombpted the following question which isn't about the FCC action per say. This is about how does one define Transit provider vs ISP ? For that matter, how does one distinguish between someone delivering IP packets, vs. someone offering frame relay, or ATM - which are clearly telecom services? Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra Luke Guillory Vice President – Technology and Innovation [cid:imagea31855.JPG at 9f5ca8aa.498ff694] Tel: 985.536.1212 Fax: 985.536.0300 Email: lguillory at reservetele.com Web: www.rtconline.com Reserve Telecommunications 100 RTC Dr Reserve, LA 70084 Disclaimer: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material which should not disseminate, distribute or be copied. Please notify Luke Guillory immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Luke Guillory therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. From mfidelman at meetinghouse.net Thu Nov 23 04:29:21 2017 From: mfidelman at meetinghouse.net (Miles Fidelman) Date: Wed, 22 Nov 2017 21:29:21 -0700 Subject: Definition of ISP vs Transit provider In-Reply-To: References: Message-ID: Well yes, but functionally, how is IP transport sufficiently different to make it an "information service" rather than a "telecommunications service?"  At least that's the argument I'd make against reclassifying access services. Miles On 11/22/17 9:24 PM, Luke Guillory wrote: > > Those normally come with ASRs and a tariff from the regulated side of > things. At least from my experience anyway. > > Sent from my iPad > > On Nov 22, 2017, at 10:08 PM, Miles Fidelman > > wrote: > >> On 11/22/17 2:50 PM, William Herrin wrote: >> >>> On Wed, Nov 22, 2017 at 3:35 PM, Jean-Francois Mezei < >>> jfmezei_nanog at vaxination.ca > wrote: >>>> The FCC is about to reclassify "Broadband Internet Access Service" >>>> as an >>>> information service instead of Telecommunications Service. This >>>> prombpted the following question which isn't about the FCC action >>>> per say. >>>> >>>> This is about how does one define Transit provider vs ISP ? >> For that matter, how does one distinguish between someone delivering >> IP packets, vs. someone offering frame relay, or ATM - which are >> clearly telecom services? >> >> Miles Fidelman >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is.  .... Yogi Berra >> >> > Luke Guillory > Vice President – Technology and Innovation > > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > Web: www.rtconline.com > > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > > *Disclaimer:* > The information transmitted, including attachments, is intended only > for the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guilloryimmediately by > e-mail if you have received this e-mail by mistake and delete this > e-mail from your system. E-mail transmission cannot be guaranteed to > be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or contain > viruses. Luke Guillorytherefore does not accept liability for any > errors or omissions in the contents of this message, which arise as a > result of e-mail transmission. > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From Jacques.Latour at cira.ca Thu Nov 23 16:49:09 2017 From: Jacques.Latour at cira.ca (Jacques Latour) Date: Thu, 23 Nov 2017 16:49:09 +0000 Subject: Definition of ISP vs Transit provider In-Reply-To: References: Message-ID: <9af1421f827f4433b5cfa249599ef746@cira.ca> ISP: Anybody offering services over the internet, including Transit Providers. Transit Provider: An internet service "transit" where the whole Internet can reach your advertised network addresses. :-) Jack -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Miles Fidelman Sent: November 22, 2017 11:29 PM To: Luke Guillory Cc: nanog at nanog.org Subject: Re: Definition of ISP vs Transit provider Well yes, but functionally, how is IP transport sufficiently different to make it an "information service" rather than a "telecommunications service?"  At least that's the argument I'd make against reclassifying access services. Miles On 11/22/17 9:24 PM, Luke Guillory wrote: > > Those normally come with ASRs and a tariff from the regulated side of > things. At least from my experience anyway. > > Sent from my iPad > > On Nov 22, 2017, at 10:08 PM, Miles Fidelman > > wrote: > >> On 11/22/17 2:50 PM, William Herrin wrote: >> >>> On Wed, Nov 22, 2017 at 3:35 PM, Jean-Francois Mezei < >>> jfmezei_nanog at vaxination.ca > wrote: >>>> The FCC is about to reclassify "Broadband Internet Access Service" >>>> as an >>>> information service instead of Telecommunications Service. This >>>> prombpted the following question which isn't about the FCC action >>>> per say. >>>> >>>> This is about how does one define Transit provider vs ISP ? >> For that matter, how does one distinguish between someone delivering >> IP packets, vs. someone offering frame relay, or ATM - which are >> clearly telecom services? >> >> Miles Fidelman >> >> -- >> In theory, there is no difference between theory and practice. >> In practice, there is.  .... Yogi Berra >> >> > Luke Guillory > Vice President – Technology and Innovation > > > Tel: 985.536.1212 > Fax: 985.536.0300 > Email: lguillory at reservetele.com > Web: www.rtconline.com > > > Reserve Telecommunications > 100 RTC Dr > Reserve, LA 70084 > > > *Disclaimer:* > The information transmitted, including attachments, is intended only > for the person(s) or entity to which it is addressed and may contain > confidential and/or privileged material which should not disseminate, > distribute or be copied. Please notify Luke Guilloryimmediately by > e-mail if you have received this e-mail by mistake and delete this > e-mail from your system. E-mail transmission cannot be guaranteed to > be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or contain > viruses. Luke Guillorytherefore does not accept liability for any > errors or omissions in the contents of this message, which arise as a > result of e-mail transmission. > -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From surfer at mauigateway.com Thu Nov 23 21:57:44 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 23 Nov 2017 13:57:44 -0800 Subject: Definition of ISP vs Transit provider Message-ID: <20171123135744.30FF5786@m0117458.ppops.net> --- Jacques.Latour at cira.ca wrote: From: Jacques Latour ISP: Anybody offering services over the internet, including Transit Providers. Transit Provider: An internet service "transit" where the whole Internet can reach your advertised network addresses. --------------------------------------- I deleted the smiley face, so that may have more to do with this than I expect, but the above won't work. At home I have 2 upstreams, the whole internet can reach my advertised addresses and I provide 'transit' for my neighbor via an RF signal. Which one am I? I'll add a :-) too... scott From nanog at ics-il.net Fri Nov 24 03:39:05 2017 From: nanog at ics-il.net (Mike Hammett) Date: Thu, 23 Nov 2017 21:39:05 -0600 (CST) Subject: Broadcast television in an IP world In-Reply-To: <4B8F8DC6-FF3A-46DF-B805-2D5F0E01C817@contoso.com> References: <4B8F8DC6-FF3A-46DF-B805-2D5F0E01C817@contoso.com> Message-ID: <12187933.5717.1511494741442.JavaMail.mhammett@ThunderFuck> When do we see the boxes or software for our own boxes for the Open caching solution? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Thomas Edwards" To: nanog at nanog.org Sent: Wednesday, November 22, 2017 1:04:39 PM Subject: Broadcast television in an IP world Of potential interest to NANOG members, a key element of the new digital TV OTA standard, ATSC 3.0 (besides improved efficiency/flexibility of modulation, 4K, HEVC video coding, AC-4 immersive audio, high dynamic range/wide color gamut), is the expectation that it will be typically be viewed on an Internet connected TV, thus allowing for a composition of OTA content with interactive & personalized Internet-delivered services. This hybrid OTA/OTT concept has already been trialed in parts of Europe using the “HbbTV” (hybrid broadband-broadcast TV) standard. This URL describes some of the potential capabilities of ATSC 3.0 in this area: https://nabpilot.org/next-generation-tv-home-gateway/ ATSC 3.0 will be deployed early next year in Phoenix, AZ as a test market, with 10 stations participating, including affiliates of the four largest TV networks. At the same time, many live local television station broadcasts are already available via OTT. This can be done either directly by a network & affiliates, such as CBS All Access, or through a distributor (which we call a Digital MVPD or “DMVPD”) which now include Sling TV, Playstation Vue, DirecTV Now, YouTube TV, Hulu with Live TV, and Fubo TV. To aid in achieving the scale required for mass OTT, I’d like to point out two efforts by the Streaming Video Alliance. The first is the Open Caching initiative. As you may know, some large OTT content distributors have offered to deploy content caches in end-user ISPs (such as Google Global Cache or Netflix Open Connect), but to date they have been proprietary to that distributor. Open Caching from the SVA establishes the basic architectural guidelines for implementation of a non-proprietary, open caching system: https://www.streamingvideoalliance.org/technical-work/working-groups/open-caching/ Another effort is Multicast ABR. This is generally imagined as the use of multicast within an end-user ISP. There was recently a PoC to demonstrate live 4K streaming using the CableLabs Multicast ABR architecture based on RFC 5740 NORM (NACK-Oriented Reliable Multicast). This utilizes the home gateway to receive the live multicast stream, and “convert” the stream to unicast HTTP for last-foot delivery. https://www.streamingvideoalliance.org/2017/07/31/multicast-abr-poc/ https://apps.cablelabs.com/specification/ip-multicast-adaptive-bit-rate-architecture-technical-report -Thomas -- Thomas Edwards FOX Networks Engineering & Operations VP Engineering & Development thomas.edwards at fox.com 10201 W Pico Blvd Los Angeles, CA 90035 From cscora at apnic.net Fri Nov 24 18:02:59 2017 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 25 Nov 2017 04:02:59 +1000 (AEST) Subject: Weekly Routing Table Report Message-ID: <20171124180259.EEE3EB3DB@thyme.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, SANOG, PacNOG, SAFNOG, CaribNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG, IRNOG and the RIPE Routing WG. 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 25 Nov, 2017 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 671033 Prefixes after maximum aggregation (per Origin AS): 261644 Deaggregation factor: 2.56 Unique aggregates announced (without unneeded subnets): 324996 Total ASes present in the Internet Routing Table: 59154 Prefixes per ASN: 11.34 Origin-only ASes present in the Internet Routing Table: 51075 Origin ASes announcing only one prefix: 22520 Transit ASes present in the Internet Routing Table: 8079 Transit-only ASes present in the Internet Routing Table: 236 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 34 Max AS path prepend of ASN ( 55644) 31 Prefixes from unregistered ASNs in the Routing Table: 93 Number of instances of unregistered ASNs: 93 Number of 32-bit ASNs allocated by the RIRs: 20684 Number of 32-bit ASNs visible in the Routing Table: 16548 Prefixes from 32-bit ASNs in the Routing Table: 67751 Number of bogon 32-bit ASNs visible in the Routing Table: 12 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 361 Number of addresses announced to Internet: 2860612768 Equivalent to 170 /8s, 129 /16s and 124 /24s Percentage of available address space announced: 77.3 Percentage of allocated address space announced: 77.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 98.7 Total number of prefixes smaller than registry allocations: 222029 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 184121 Total APNIC prefixes after maximum aggregation: 52958 APNIC Deaggregation factor: 3.48 Prefixes being announced from the APNIC address blocks: 183299 Unique aggregates announced from the APNIC address blocks: 76534 APNIC Region origin ASes present in the Internet Routing Table: 8500 APNIC Prefixes per ASN: 21.56 APNIC Region origin ASes announcing only one prefix: 2392 APNIC Region transit ASes present in the Internet Routing Table: 1230 Average APNIC Region AS path length visible: 4.5 Max APNIC Region AS path length visible: 34 Number of APNIC region 32-bit ASNs visible in the Routing Table: 3364 Number of APNIC addresses announced to Internet: 766844704 Equivalent to 45 /8s, 181 /16s and 31 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-137529 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: 201230 Total ARIN prefixes after maximum aggregation: 96918 ARIN Deaggregation factor: 2.08 Prefixes being announced from the ARIN address blocks: 202591 Unique aggregates announced from the ARIN address blocks: 94796 ARIN Region origin ASes present in the Internet Routing Table: 18033 ARIN Prefixes per ASN: 11.23 ARIN Region origin ASes announcing only one prefix: 6687 ARIN Region transit ASes present in the Internet Routing Table: 1780 Average ARIN Region AS path length visible: 3.8 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 2268 Number of ARIN addresses announced to Internet: 1112570912 Equivalent to 66 /8s, 80 /16s and 124 /24s 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, 62464-63487, 64198-64296, 393216-397212 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: 181159 Total RIPE prefixes after maximum aggregation: 88503 RIPE Deaggregation factor: 2.05 Prefixes being announced from the RIPE address blocks: 177056 Unique aggregates announced from the RIPE address blocks: 106800 RIPE Region origin ASes present in the Internet Routing Table: 24646 RIPE Prefixes per ASN: 7.18 RIPE Region origin ASes announcing only one prefix: 11258 RIPE Region transit ASes present in the Internet Routing Table: 3503 Average RIPE Region AS path length visible: 4.5 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 6415 Number of RIPE addresses announced to Internet: 713358720 Equivalent to 42 /8s, 132 /16s and 253 /24s 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, 61952-62463, 64396-64495 196608-207259 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: 86384 Total LACNIC prefixes after maximum aggregation: 19288 LACNIC Deaggregation factor: 4.48 Prefixes being announced from the LACNIC address blocks: 87654 Unique aggregates announced from the LACNIC address blocks: 39340 LACNIC Region origin ASes present in the Internet Routing Table: 6608 LACNIC Prefixes per ASN: 13.26 LACNIC Region origin ASes announcing only one prefix: 1824 LACNIC Region transit ASes present in the Internet Routing Table: 1224 Average LACNIC Region AS path length visible: 5.2 Max LACNIC Region AS path length visible: 29 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 4128 Number of LACNIC addresses announced to Internet: 172452320 Equivalent to 10 /8s, 71 /16s and 105 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-268700 + 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: 18044 Total AfriNIC prefixes after maximum aggregation: 3909 AfriNIC Deaggregation factor: 4.62 Prefixes being announced from the AfriNIC address blocks: 20072 Unique aggregates announced from the AfriNIC address blocks: 7236 AfriNIC Region origin ASes present in the Internet Routing Table: 1100 AfriNIC Prefixes per ASN: 18.25 AfriNIC Region origin ASes announcing only one prefix: 358 AfriNIC Region transit ASes present in the Internet Routing Table: 218 Average AfriNIC Region AS path length visible: 4.6 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 373 Number of AfriNIC addresses announced to Internet: 94937856 Equivalent to 5 /8s, 168 /16s and 163 /24s 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 4538 5279 4192 76 ERX-CERNET-BKB China Education and Rese 7545 4062 410 408 TPG-INTERNET-AP TPG Telecom Limited, AU 4766 2789 11128 758 KIXS-AS-KR Korea Telecom, KR 17974 2777 916 76 TELKOMNET-AS2-AP PT Telekomunikasi Indo 9829 2759 1499 540 BSNL-NIB National Internet Backbone, IN 45899 2369 1505 156 VNPT-AS-VN VNPT Corp, VN 7552 2296 1158 60 VIETEL-AS-AP Viettel Group, VN 9394 2169 4931 26 CTTNET China TieTong Telecommunications 4755 2083 422 212 TATACOMM-AS TATA Communications formerl 9808 2068 8699 32 CMNET-GD Guangdong Mobile Communication 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 6327 3348 1323 87 SHAW - Shaw Communications Inc., CA 22773 3308 2952 154 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 18566 2171 405 107 MEGAPATH5-US - MegaPath Corporation, US 20115 2054 2288 444 CHARTER-NET-HKY-NC - Charter Communicat 6389 2013 3671 39 BELLSOUTH-NET-BLK - BellSouth.net Inc., 16509 1943 4076 585 AMAZON-02 - Amazon.com, Inc., US 209 1929 5062 645 CENTURYLINK-US-LEGACY-QWEST - Qwest Com 30036 1855 331 259 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom 11492 1674 235 575 CABLEONE - CABLE ONE, INC., US 701 1547 10589 625 UUNET - MCI Communications Services, In 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 39891 3519 186 23 ALJAWWALSTC-AS, SA 20940 2849 851 2056 AKAMAI-ASN1, US 8551 2489 378 42 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 34984 2064 330 426 TELLCOM-AS, TR 12389 2012 1736 737 ROSTELECOM-AS, RU 12479 1917 1066 102 UNI2-AS, ES 9121 1853 1691 17 TTNET, TR 13188 1604 100 52 TRIOLAN, UA 6849 1227 355 21 UKRTELNET, UA 8402 1226 544 14 CORBINA-AS OJSC "Vimpelcom", RU 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 3553 538 297 Telmex Colombia S.A., CO 8151 3446 3425 581 Uninet S.A. de C.V., MX 11830 2645 370 66 Instituto Costarricense de Electricidad 6503 1622 437 53 Axtel, S.A.B. de C.V., MX 7303 1495 1021 196 Telecom Argentina S.A., AR 6147 1220 377 27 Telefonica del Peru S.A.A., PE 3816 1034 512 103 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 28573 999 2258 193 CLARO S.A., BR 11172 914 126 86 Alestra, S. de R.L. de C.V., MX 18881 903 1063 28 TELEF�NICA BRASIL S.A, BR 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 24863 1210 398 48 LINKdotNET-AS, EG 37611 802 91 8 Afrihost, ZA 36903 736 370 138 MT-MPLS, MA 36992 678 1383 31 ETISALAT-MISR, EG 8452 524 1730 17 TE-AS TE-AS, EG 24835 515 850 15 RAYA-AS, EG 29571 431 36 10 CITelecom-AS, CI 37492 425 367 77 ORANGE-, TN 37342 355 32 1 MOVITEL, MZ 15399 349 35 7 WANANCHI-, KE 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 4538 5279 4192 76 ERX-CERNET-BKB China Education and Rese 7545 4062 410 408 TPG-INTERNET-AP TPG Telecom Limited, AU 10620 3553 538 297 Telmex Colombia S.A., CO 39891 3519 186 23 ALJAWWALSTC-AS, SA 8151 3446 3425 581 Uninet S.A. de C.V., MX 6327 3348 1323 87 SHAW - Shaw Communications Inc., CA 22773 3308 2952 154 ASN-CXA-ALL-CCI-22773-RDC - Cox Communi 20940 2849 851 2056 AKAMAI-ASN1, US 4766 2789 11128 758 KIXS-AS-KR Korea Telecom, KR 17974 2777 916 76 TELKOMNET-AS2-AP PT Telekomunikasi Indo Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 7545 4062 3654 TPG-INTERNET-AP TPG Telecom Limited, AU 39891 3519 3496 ALJAWWALSTC-AS, SA 6327 3348 3261 SHAW - Shaw Communications Inc., CA 10620 3553 3256 Telmex Colombia S.A., CO 22773 3308 3154 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 8151 3446 2865 Uninet S.A. de C.V., MX 17974 2777 2701 TELKOMNET-AS2-AP PT Telekomunikasi Indonesia, I 11830 2645 2579 Instituto Costarricense de Electricidad y Telec 8551 2489 2447 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 7552 2296 2236 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 65501 PRIVATE 5.141.112.0/22 6828 USI, RU 65602 UNALLOCATED 8.225.192.0/24 30372 SUNESYS2 - Sunesys, LLC, US 64710 PRIVATE 39.134.26.0/23 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.134.28.0/23 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.134.30.0/24 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.134.31.0/24 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.137.20.0/23 56042 CMNET-SHANXI-AP China Mobile c 64710 PRIVATE 39.137.22.0/24 56042 CMNET-SHANXI-AP China Mobile c 65001 PRIVATE 46.237.40.0/21 13118 ASN-YARTELECOM PJSC Rostelecom 64513 PRIVATE 62.150.101.0/24 9155 QNET Kuwait, KW Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 14.128.12.0/22 55427 BROADLINK-AS-AP Broadlink Nepal, NP 14.128.14.0/23 10247 NETLINE, ZA 14.192.50.0/23 10247 NETLINE, ZA 14.192.58.0/23 10247 NETLINE, ZA 27.100.7.0/24 56096 UNKNOWN 36.255.250.0/23 10247 NETLINE, ZA 41.78.180.0/23 37265 -Reserved AS-, ZZ 43.228.144.0/22 9829 BSNL-NIB National Internet Backbone, IN 43.251.20.0/22 9381 WTT-AS-AP WTT HK Limited, HK 43.251.84.0/22 133676 PNPL-AS Precious netcom pvt ltd, IN 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:15 /9:13 /10:36 /11:106 /12:285 /13:550 /14:1060 /15:1856 /16:13336 /17:7754 /18:13617 /19:25184 /20:38959 /21:43744 /22:81587 /23:66378 /24:374339 /25:840 /26:622 /27:652 /28:35 /29:21 /30:15 /31:2 /32:27 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6327 3141 3348 SHAW - Shaw Communications Inc., CA 39891 2946 3519 ALJAWWALSTC-AS, SA 22773 2544 3308 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications 18566 2066 2171 MEGAPATH5-US - MegaPath Corporation, US 11830 1989 2645 Instituto Costarricense de Electricidad y Telec 8551 1953 2489 BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbo 30036 1622 1855 MEDIACOM-ENTERPRISE-BUSINESS - Mediacom Communi 10620 1544 3553 Telmex Colombia S.A., CO 11492 1493 1674 CABLEONE - CABLE ONE, INC., US 34984 1371 2064 TELLCOM-AS, TR Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1565 2:816 4:18 5:2598 6:38 8:1079 9:1 12:1853 13:181 14:1741 15:29 16:3 17:184 18:76 20:52 21:1 23:2407 24:1938 25:2 27:2367 31:1957 32:87 35:21 36:455 37:2431 38:1439 39:87 40:100 41:3048 42:519 43:1895 44:82 45:3307 46:2835 47:183 49:1369 50:1040 51:34 52:903 54:354 55:5 56:4 57:42 58:1573 59:994 60:367 61:1986 62:1776 63:1838 64:4596 65:2242 66:4488 67:2299 68:1193 69:3173 70:1131 71:588 72:2098 74:2681 75:389 76:415 77:1527 78:1569 79:1886 80:1442 81:1411 82:1036 83:753 84:1000 85:1960 86:481 87:1230 88:887 89:2298 90:174 91:6244 92:1029 93:2345 94:2410 95:2675 96:667 97:351 98:963 99:103 100:154 101:1482 102:1 103:16186 104:3185 105:208 106:566 107:1774 108:815 109:2942 110:1505 111:1732 112:1270 113:1353 114:1074 115:1599 116:1705 117:1642 118:2159 119:1650 120:713 121:1073 122:2408 123:1901 124:1482 125:1824 128:934 129:680 130:445 131:1544 132:600 133:193 134:895 135:227 136:442 137:464 138:1961 139:539 140:381 141:677 142:753 143:913 144:801 145:190 146:1136 147:694 148:1562 149:622 150:708 151:1003 152:729 153:302 154:952 155:740 156:731 157:752 158:599 159:1607 160:814 161:734 162:2534 163:529 164:931 165:1471 166:392 167:1349 168:3103 169:821 170:3541 171:399 172:1011 173:1893 174:826 175:774 176:1895 177:3989 178:2497 179:1160 180:2243 181:2106 182:2422 183:807 184:887 185:11535 186:3299 187:2276 188:2593 189:1894 190:8190 191:1322 192:9715 193:5862 194:4762 195:3979 196:2247 197:1423 198:5548 199:5876 200:7206 201:4867 202:10401 203:9959 204:4569 205:2871 206:3072 207:3096 208:3984 209:3879 210:3939 211:2051 212:2886 213:2586 214:850 215:65 216:5711 217:2096 218:871 219:602 220:1678 221:938 222:718 223:1202 End of report From Richard.VanderReyden at optus.com.au Wed Nov 22 22:50:37 2017 From: Richard.VanderReyden at optus.com.au (Richard Vander Reyden) Date: Wed, 22 Nov 2017 22:50:37 +0000 Subject: ospf database size - affects that underlying transport mtu might have In-Reply-To: <002a01d363ba$80b32f90$82198eb0$@gvtc.com> References: <002a01d363ba$80b32f90$82198eb0$@gvtc.com> Message-ID: <9e2165dcf3cf438780208cdb290cf3e5@E15PRDAPPW007.optus.com.au> > This is a *single area* ospf environment, that has been stable for years. > But now suddenly is having issues with new ospf neightbor adjacencies , which are riding a 3rd party transport network I have seen this in the lab before, was related to the size of the LSA. > Anyone ever experienced anything strange with underlying transport network mtu possibly causing ospf neighbor adjacency to be broken ? I'm asking if the underlying 3rd party transport layer 2 network >has a smaller mtu than the endpoint ospf ip interface have, could this cause those ospf neighbors to not fully establish ? You can check this with a ping of your mtu size set with the df bit set > .and I'm also asking this if the single ospf area has grown large enough to cause some > sort of initial database packet to be larger than that underlying 3rd party mtu is providing If you have a large amount of routers in your area the LSA size will grow, we saw a problem in testing when we injected 2000 prefixes into the area and the OSPF neighbour would not come up. On a cisco router you can set 'buffers huge' as a work around. Richard From Dave.Siegel at centurylink.com Mon Nov 27 20:24:44 2017 From: Dave.Siegel at centurylink.com (Siegel, David) Date: Mon, 27 Nov 2017 20:24:44 +0000 Subject: Definition of ISP vs Transit provider In-Reply-To: References: Message-ID: <970945E55BFD8C4EA4CAD74B647A9DC0DE736AC3@USIDCWVEMBX08.corp.global.level3.com> Though not an industry standard definition, we've defined them at a product level where I work. These have changed somewhat over the years, but pretty much fall along the following lines. IP Transit: A wholesale product that does not include IP Addresses, email address, DNS, or any other "value-added" services. When customer has filed a 499-a, collection of USF surcharges is waived. Availability is typically limited to a sub-set of the total POP footprint and generally does not include access backhaul on our network. Dedicated Internet Access: A product generally sold to businesses that includes IP addresses, recursive DNS, and 5 domain names. Available across the whole of the footprint and pricing includes backhaul on our network, but not off-net (3rd party) backhaul. USF is always assessed. (email and usenet services are defunct with our service, but I'm sure many still offer email). I can see the second product definition for DIA being a pretty good match for your ISP definition, be that consumer broadband or what have you, with minor modifications. FWIW, hope that's helpful. Dave Dave Siegel Vice President Product Management CenturyLink 1025 Eldorado Blvd Broomfield, CO 80021 p: 720.888.0953 m: 520.229.7627 e: dave.siegel at centurylink.com -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jean-Francois Mezei Sent: Wednesday, November 22, 2017 1:35 PM To: Nanog at nanog.org Subject: Definition of ISP vs Transit provider The FCC is about to reclassify "Broadband Internet Access Service" as an information service instead of Telecommunications Service. This prombpted the following question which isn't about the FCC action per say. This is about how does one define Transit provider vs ISP ? Cogent for instance acts as a transit provider to other networks but also sells connectivity to companies. Peer1 in Canada used to sell "transit" to a then small emerging ISP, but as its sole transit provider, provided the BGP management as well as peering at Torix. Is the service to the ISP still called "transit" ? Or would ISP be defined as the organsation which assigns IPs to end users via PPPoE of DHCP ? One could argue that a network which assigns 4 or less IPs per customer would be an ISP. But what about IPv6 where the ISP could give each end user a /64 ? Just curious to see if there are agreed upon definitions from the network operators's point of view. I note that large companies tend to do everything from transit, to residential ISP, business ISP, libraries, airports etc. For Bell Canada, it is almost all under AS577. So separating what is telecom and what is information becomes more "interesting". As a point of reference this is what I *think* the FCC defines as an ISP: ## 23. Broadband Internet access service also does not include virtual private network (VPN) services, content delivery networks (CDNs), hosting or data storage services, or Internet backbone services (if those services are separate from broadband Internet access service), consistent with past Commission precedent.69 The Commission has historically distinguished these services from “mass market” services, as they do not provide the capability to transmit data to and receive data from all or substantially all Internet endpoints.70 We do not disturb that finding here. 24. Finally, we observe that to the extent that coffee shops, bookstores, airlines, private end- user networks such as libraries and universities, and other businesses acquire broadband Internet access service from a broadband provider to enable patrons to access the Internet from their respective establishments, provision of such service by the premise operator would not itself be considered a broadband Internet access service unless it was offered to patrons as a retail mass market service, as we define it here.71 Likewise, when a user employs, for example, a wireless router or a Wi-Fi hotspot to create a personal Wi-Fi network that is not intentionally offered for the benefit of others, he or she is not offering a broadband Internet access service, under our definition, because the user is not marketing and selling such service to residential customers, small business, and other end-user customers such as schools and libraries. ## The full 210 proposed FCC decision is at: https://apps.fcc.gov/edocs_public/attachmatch/DOC-347927A1.pdf This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From sean at donelan.com Mon Nov 27 20:28:31 2017 From: sean at donelan.com (Sean Donelan) Date: Mon, 27 Nov 2017 15:28:31 -0500 (EST) Subject: Wireless ISPs during disasters (hurricane harvey, irma and maria) Message-ID: While some of the big companies like Facebook, Google and Microsoft got some press about their wireless experiments during the post-hurricane recovery, the FCC hasn't heard about the experience of wireless ISPs during the recovery. Were there any wireless ISPs in south-Texas, south-Florida, Puerto Rico or U.S. Virigin Islands? How did they survive, or able to speed recovery efforts? Were there resources they needed? WISPs don't normally report in the FCC DIRS or NORS disaster reporting systems, so WISPs are a blank spot. From nanog at ics-il.net Mon Nov 27 20:33:32 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 27 Nov 2017 14:33:32 -0600 (CST) Subject: Wireless ISPs during disasters (hurricane harvey, irma and maria) In-Reply-To: References: Message-ID: <414259207.1510.1511814808298.JavaMail.mhammett@ThunderFuck> I know a few of them are on this list. Here's an update today from one of them in PR. http://afmug.com/pipermail/af/2017-November/087914.html Demand for their service is huge because traditional service providers are slow to recover. Early on, the WISPs in PR couldn't get any traction anywhere, even the ones serving critical facilities. Once commercial shipments started, they were doing pretty good. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Sean Donelan" To: nanog at nanog.org Sent: Monday, November 27, 2017 2:28:31 PM Subject: Wireless ISPs during disasters (hurricane harvey, irma and maria) While some of the big companies like Facebook, Google and Microsoft got some press about their wireless experiments during the post-hurricane recovery, the FCC hasn't heard about the experience of wireless ISPs during the recovery. Were there any wireless ISPs in south-Texas, south-Florida, Puerto Rico or U.S. Virigin Islands? How did they survive, or able to speed recovery efforts? Were there resources they needed? WISPs don't normally report in the FCC DIRS or NORS disaster reporting systems, so WISPs are a blank spot. From eric.kuhnke at gmail.com Mon Nov 27 20:38:30 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Mon, 27 Nov 2017 12:38:30 -0800 Subject: Wireless ISPs during disasters (hurricane harvey, irma and maria) In-Reply-To: References: Message-ID: AeroNet is a large sized independent ISP in Puerto Rico (as compared to major US48 based national carriers, and relative to the size of the market as a whole) and makes extensive use of PTP And PtMP microwave/millimeter wave equipment, so I guess they count as a WISP. They are active on some industry specific WISP forums. https://www.google.com/search?q=aeronet+puerto+rico&oq=aeronet+puerto+rico&aqs=chrome.0.0l6.3240j0j7&sourceid=chrome&ie=UTF-8 On Mon, Nov 27, 2017 at 12:28 PM, Sean Donelan wrote: > > While some of the big companies like Facebook, Google and Microsoft got > some press about their wireless experiments during the post-hurricane > recovery, the FCC hasn't heard about the experience of wireless ISPs during > the recovery. > > Were there any wireless ISPs in south-Texas, south-Florida, Puerto Rico or > U.S. Virigin Islands? How did they survive, or able to speed recovery > efforts? Were there resources they needed? > > WISPs don't normally report in the FCC DIRS or NORS disaster reporting > systems, so WISPs are a blank spot. > > From nanog at ics-il.net Mon Nov 27 20:48:28 2017 From: nanog at ics-il.net (Mike Hammett) Date: Mon, 27 Nov 2017 14:48:28 -0600 (CST) Subject: Wireless ISPs during disasters (hurricane harvey, irma and maria) In-Reply-To: References: Message-ID: <1911397895.1527.1511815703761.JavaMail.mhammett@ThunderFuck> Here are some pictures that affected WISPs contributed. https://www.facebook.com/pg/thebrotherswisp/photos/?tab=album&album_id=1311278818997567 ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Sean Donelan" To: nanog at nanog.org Sent: Monday, November 27, 2017 2:28:31 PM Subject: Wireless ISPs during disasters (hurricane harvey, irma and maria) While some of the big companies like Facebook, Google and Microsoft got some press about their wireless experiments during the post-hurricane recovery, the FCC hasn't heard about the experience of wireless ISPs during the recovery. Were there any wireless ISPs in south-Texas, south-Florida, Puerto Rico or U.S. Virigin Islands? How did they survive, or able to speed recovery efforts? Were there resources they needed? WISPs don't normally report in the FCC DIRS or NORS disaster reporting systems, so WISPs are a blank spot. From surfer at mauigateway.com Mon Nov 27 22:51:48 2017 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 27 Nov 2017 14:51:48 -0800 Subject: ospf database size - affects that underlying transport mtu might have Message-ID: <20171127145148.30FCDE1C@m0117457.ppops.net> --- nanog at nanog.org wrote: From: Richard Vander Reyden via NANOG > This is a *single area* ospf environment, that has been > stable for years. But now suddenly is having issues with > new ospf neightbor adjacencies , which are riding a 3rd > party transport network >> I have seen this in the lab before, was related to the >> size of the LSA. --------------------------------------------------- Wouldn't this show in some SNMP OID that can be monitored? If nothing else, fragmentation (see below). Also, how big was the LSA? It should be able to be pretty big. According to: https://supportforums.cisco.com/t5/service-providers-documents/ospf-and-mtu/ta-p/3118885 "RFC 2328 (OSPF version 2 specification) says...If necessary, the length of OSPF packets can be up to 65,535 bytes (including the IP header). The OSPF packet types that are likely to be large (Database Description Packets, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into several separate protocol packets, without loss of functionality. This is recommended; IP fragmentation should be avoided whenever possible." scott From rganascim at gmail.com Tue Nov 28 00:47:00 2017 From: rganascim at gmail.com (Rafael Ganascim) Date: Mon, 27 Nov 2017 22:47:00 -0200 Subject: ospf database size - affects that underlying transport mtu might have In-Reply-To: <002a01d363ba$80b32f90$82198eb0$@gvtc.com> References: <002a01d363ba$80b32f90$82198eb0$@gvtc.com> Message-ID: Em 22 de nov de 2017 3:53 PM, "Aaron Gould" escreveu: This is a *single area* ospf environment, that has been stable for years.. But now suddenly is having issues with new ospf neightbor adjacencies , which are riding a 3rd party transport network Anyone ever experienced anything strange with underlying transport network mtu possibly causing ospf neighbor adjacency to be broken ? Yes, the neighbor state will loop between init/Exchange and it will never become Full. As others said, you need to test the MTU size without fragmentation and adjust in your L3 interface (ping with DF-bit). I'm asking if the underlying 3rd party transport layer 2 network has a smaller mtu than the endpoint ospf ip interface have, could this cause those ospf neighbors to not fully establish ? IMHO, Your transport network must support your Full 1500 bytes MTU. No one want to deal with fragmentation. They need to activate jumbo frames to sell L2 circuits. .and I'm also asking this if the single ospf area has grown large enough to cause some sort of initial database packet to be larger than that underlying 3rd party mtu is providing Its normal to have a LSADB bigger than MTU could support, and with correct MTU this is not a problem. Regards, Rafael From list at satchell.net Thu Nov 23 16:56:26 2017 From: list at satchell.net (Stephen Satchell) Date: Thu, 23 Nov 2017 08:56:26 -0800 Subject: Contact at AT&T? Message-ID: I'm trying to resolve an issue with their network blocking Secure IMAP, port 993/TCP. Is there any contact available? From satch89502 at gmail.com Tue Nov 28 03:23:58 2017 From: satch89502 at gmail.com (Stephen Satchell) Date: Mon, 27 Nov 2017 19:23:58 -0800 Subject: Contact at AT&T? -- Never mind Message-ID: <3cafdc33-18f0-a4eb-342f-c5d8b87ba4b6@satchell.net> > I'm trying to resolve an issue with their network blocking Secure IMAP, port 993/TCP. Is there any contact available? Problem resolved. If anyone wants the gruesome details, ask off-list. From bob at FiberInternetCenter.com Wed Nov 29 01:01:02 2017 From: bob at FiberInternetCenter.com (Bob Evans) Date: Tue, 28 Nov 2017 17:01:02 -0800 Subject: Any one from Akamai here ? Got a problem. Message-ID: We do not know why we are being blocked....at www.costco.com Name: e6025.a.akamaiedge.net Address: 104.96.118.20 Appears only via Los Angeles. Other paths , via San Jose , Palo Alto - via other transits all work fine....to this IP address. Here is the error reported to several sites all on Akamai. Access Denied You don't have permission to access "http://www.costco.com/" on this server. Reference #18.c60ad717.1511897450.524468b7 Access Denied You don't have permission to access "http://www.costco.com/services.html" on this server. Reference #18.c60ad717.1511898193.52508dce Access Denied You don't have permission to access "http://www.loopnet.com/index.html" on this server. Reference #18.940ad717.1511898022.2f14cff8 Thank You Bob Evans CTO From schecter at gmail.com Wed Nov 29 01:21:45 2017 From: schecter at gmail.com (Steven Schecter) Date: Tue, 28 Nov 2017 20:21:45 -0500 Subject: Any one from Akamai here ? Got a problem. In-Reply-To: References: Message-ID: Hi Bob, We are investigating and will communicate with you off list. /sjs On Tue, Nov 28, 2017 at 8:01 PM, Bob Evans wrote: > We do not know why we are being blocked....at www.costco.com > Name: e6025.a.akamaiedge.net > Address: 104.96.118.20 > > Appears only via Los Angeles. Other paths , via San Jose , Palo Alto - via > other transits all work fine....to this IP address. > > Here is the error reported to several sites all on Akamai. > > Access Denied > > You don't have permission to access "http://www.costco.com/" on this > server. > Reference #18.c60ad717.1511897450.524468b7 > > Access Denied > > You don't have permission to access "http://www.costco.com/services.html" > on this server. > Reference #18.c60ad717.1511898193.52508dce > > > Access Denied > > You don't have permission to access "http://www.loopnet.com/index.html" on > this server. > Reference #18.940ad717.1511898022.2f14cff8 > > > Thank You > Bob Evans > CTO > > > > > > > -- Steven J. Schecter (m) 917.676.1646 From zhuifeng0426 at gmail.com Tue Nov 28 20:48:59 2017 From: zhuifeng0426 at gmail.com (Yifeng Zhou) Date: Tue, 28 Nov 2017 12:48:59 -0800 Subject: tracking TCP session hop by hop Message-ID: Hi Experts, Is there any way that we can track TCP session hop by hop? Say we have 10 ECMP between A and Z point, what's the easiest way to track specific session is using which path? How we can check between servers(Linux/Unix) and between Routers(Cisco/Juniper etc)? Thanks -Yifeng From sryan at arbor.net Wed Nov 29 14:54:25 2017 From: sryan at arbor.net (Ryan, Spencer) Date: Wed, 29 Nov 2017 14:54:25 +0000 Subject: ATT AVPN BGP Communities Message-ID: Hey All, Does anyone know if AVPN lets end users set/add their own communities to routes? I see that they stamp several on the routes we originate (Community: 13979:2741 13979:2943 13979:5000 13979:6551) and curious if anyone had luck adding their own before I go start mucking around. Thanks! Spencer Ryan | Senior Systems Administrator | sryan at arbor.net Arbor Networks | The security division of NETSCOUT +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com From jbarrant at akamai.com Wed Nov 29 01:06:57 2017 From: jbarrant at akamai.com (Barrantes, Jorge) Date: Wed, 29 Nov 2017 01:06:57 +0000 Subject: Any one from Akamai here ? Got a problem. In-Reply-To: References: Message-ID: <0F2C025E-53C3-4AF3-A4C4-FC99BEBA390F@akamai.com> Hi Bob, I’ll forward this to our network team to check the regions on those locations. Jorge Barrantes Senior Solutions Engineer – Enterprise & Carrier Akamai Technologies, Costa Rica Connect with Us: On 11/28/17, 7:02 PM, "Bob Evans" wrote: We do not know why we are being blocked....at www.costco.com Name: e6025.a.akamaiedge.net Address: 104.96.118.20 Appears only via Los Angeles. Other paths , via San Jose , Palo Alto - via other transits all work fine....to this IP address. Here is the error reported to several sites all on Akamai. Access Denied You don't have permission to access "http://www.costco.com/" on this server. Reference #18.c60ad717.1511897450.524468b7 Access Denied You don't have permission to access "http://www.costco.com/services.html" on this server. Reference #18.c60ad717.1511898193.52508dce Access Denied You don't have permission to access "http://www.loopnet.com/index.html" on this server. Reference #18.940ad717.1511898022.2f14cff8 Thank You Bob Evans CTO From gfocaccio at cari.net Tue Nov 28 22:59:00 2017 From: gfocaccio at cari.net (Gregorio Focaccio) Date: Tue, 28 Nov 2017 22:59:00 +0000 Subject: Packet Loss through Level 3 in Southern California? Message-ID: Hi All, We are an MSP in San Diego that also offers multi-datacenter Colo and Cloud hosting. We are multi-homed with Level 3 and Cogent. A physical server client reported newly slow FTP transfers, so we started a network investigation. Our data (see below) seem to show packet loss through Level 3 with associated slow TCP based data transfers. Is anyone else seeing packet loss and consequent slow TCP based transfers when going through Level 3 in (LosAngeles1) Southern California? Thanks, Greg Focaccio CARI.net Testing Data: ********** Internal tests - OK ********** FTP transfers from client server to another server 3 hops away in our adjacent datacenter was normal ********** Level 3 data - packet loss ********** External tests via Level 3 - 12% Packet Loss - see data below UDP IPERF testing from our data center (through Level 3 and Microsoft - trace below) to an Azure server showed repeatable packet loss TCP based testing - such as FTP or SCP transfers - the rate was very slow about 4Mbps [root at raynor ~]# iperf3 -c 40.80.156.2 -b 10000m Connecting to host 40.80.156.2, port 5201 [ 4] local 71.6.220.101 port 55684 connected to 40.80.156.2 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 1001 KBytes 8.20 Mbits/sec 34 9.76 KBytes [ 4] 1.00-2.00 sec 503 KBytes 4.12 Mbits/sec 12 11.2 KBytes [ 4] 2.00-3.00 sec 502 KBytes 4.11 Mbits/sec 3 25.1 KBytes [ 4] 3.00-4.00 sec 502 KBytes 4.11 Mbits/sec 12 11.2 KBytes [ 4] 4.00-5.00 sec 377 KBytes 3.08 Mbits/sec 9 15.3 KBytes [ 4] 5.00-6.00 sec 502 KBytes 4.11 Mbits/sec 10 19.5 KBytes [ 4] 6.00-7.00 sec 377 KBytes 3.09 Mbits/sec 13 6.97 KBytes [ 4] 7.00-8.00 sec 251 KBytes 2.06 Mbits/sec 9 5.58 KBytes [ 4] 8.00-9.00 sec 251 KBytes 2.06 Mbits/sec 6 9.76 KBytes [ 4] 9.00-10.00 sec 251 KBytes 2.06 Mbits/sec 10 12.6 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 4.41 MBytes 3.70 Mbits/sec 118 sender [ 4] 0.00-10.00 sec 4.24 MBytes 3.56 Mbits/sec receiver iperf Done. [root at raynor ~]# iperf3 -u -c 40.80.156.2 -b 10000m Connecting to host 40.80.156.2, port 5201 [ 4] local 71.6.220.101 port 39221 connected to 40.80.156.2 port 5201 [ ID] Interval Transfer Bandwidth Total Datagrams [ 4] 0.00-1.00 sec 85.0 MBytes 712 Mbits/sec 62402 [ 4] 1.00-2.00 sec 94.0 MBytes 789 Mbits/sec 69043 [ 4] 2.00-3.00 sec 92.6 MBytes 777 Mbits/sec 68030 [ 4] 3.00-4.00 sec 76.5 MBytes 641 Mbits/sec 56153 [ 4] 4.00-5.00 sec 94.9 MBytes 796 Mbits/sec 69662 [ 4] 5.00-6.00 sec 97.7 MBytes 819 Mbits/sec 71713 [ 4] 6.00-7.00 sec 98.5 MBytes 826 Mbits/sec 72347 [ 4] 7.00-8.00 sec 92.7 MBytes 778 Mbits/sec 68085 [ 4] 8.00-9.00 sec 91.3 MBytes 765 Mbits/sec 67045 [ 4] 9.00-10.00 sec 59.3 MBytes 498 Mbits/sec 43551 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.00-10.00 sec 883 MBytes 740 Mbits/sec 0.014 ms 75647/647955 (12%) [ 4] Sent 647955 datagrams iperf Done. [root at raynor ~]# traceroute 40.80.156.2 traceroute to 40.80.156.2 (40.80.156.2), 30 hops max, 60 byte packets 1 gateway (71.6.220.97) 6.170 ms 7.827 ms 10.718 ms 2 209.126.134.65 (209.126.134.65) 0.426 ms 0.420 ms 0.543 ms 3 216.98.153.21 (216.98.153.21) 159.936 ms 160.215 ms 160.209 ms 4 gi1-2.gw65-50.c5.sdcix.net (216.98.153.89) 170.977 ms 170.972 ms 170.964 ms 5 xe-8-3-3.bar1.SanDiego1.Level3.net (4.16.105.93) 0.547 ms 0.586 ms 0.533 ms 6 * * * 7 * * * 8 Microsoft-level3-20G.LosAngeles1.Level3.net (4.68.111.122) 17.296 ms 18.026 ms 20.200 ms 9 be-61-0.ibr01.lax03.ntwk.msn.net (104.44.8.104) 30.108 ms 32.300 ms 32.283 ms 10 be-4-0.ibr01.by2.ntwk.msn.net (104.44.4.3) 30.364 ms 30.961 ms 28.960 ms 11 104.44.7.198 (104.44.7.198) 31.870 ms 30.120 ms 29.636 ms 12 ae100-0.icr01.by21.ntwk.msn.net (104.44.11.194) 27.828 ms ae101-0.icr01.by4.ntwk.msn.net (104.44.11.193) 29.611 ms ae100-0.icr01.by21.ntwk.msn.net (104.44.11.194) 27.710 ms 13 * * * [root at raynor ~]# scp ubuntu-14.04.5-desktop-amd64.iso carinet at 40.80.156.2:/home/carinet/ubuntunew11.iso ubuntu-14.04.5-desktop-amd64.iso 100% 1053MB 730.8KB/s 24:35 LEVEL3 - summary CARIcloud to Azure 2 Mbits/s TCP iperf 800 Mbits/s UDP iperf 24m and 35s 1053 MB upload to Azure through SCP ********** Cogent data - OK ********** External tests via Cogent - OK - No significant loss - see IPERF and trace data below [root at raynor ~]# iperf3 -c 40.80.156.2 -b 10000m Connecting to host 40.80.156.2, port 5201 [ 4] local 71.6.220.101 port 45076 connected to 40.80.156.2 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 149 MBytes 1.25 Gbits/sec 0 4.58 MBytes [ 4] 1.00-2.00 sec 180 MBytes 1.51 Gbits/sec 0 4.58 MBytes [ 4] 2.00-3.00 sec 178 MBytes 1.50 Gbits/sec 0 4.58 MBytes [ 4] 3.00-4.00 sec 180 MBytes 1.51 Gbits/sec 0 4.58 MBytes [ 4] 4.00-5.00 sec 180 MBytes 1.51 Gbits/sec 0 4.58 MBytes [ 4] 5.00-6.00 sec 180 MBytes 1.51 Gbits/sec 0 4.58 MBytes [ 4] 6.00-7.00 sec 179 MBytes 1.50 Gbits/sec 0 4.58 MBytes [ 4] 7.00-8.00 sec 180 MBytes 1.51 Gbits/sec 0 4.58 MBytes [ 4] 8.00-9.00 sec 181 MBytes 1.52 Gbits/sec 0 4.58 MBytes [ 4] 9.00-10.00 sec 180 MBytes 1.51 Gbits/sec 0 4.58 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.73 GBytes 1.48 Gbits/sec 0 sender [ 4] 0.00-10.00 sec 1.73 GBytes 1.48 Gbits/sec receiver iperf Done. [root at raynor ~]# iperf3 -u -c 40.80.156.2 -b 10000m Connecting to host 40.80.156.2, port 5201 [ 4] local 71.6.220.101 port 39130 connected to 40.80.156.2 port 5201 [ ID] Interval Transfer Bandwidth Total Datagrams [ 4] 0.00-1.00 sec 101 MBytes 844 Mbits/sec 73869 [ 4] 1.00-2.00 sec 103 MBytes 861 Mbits/sec 75344 [ 4] 2.00-3.00 sec 99.0 MBytes 830 Mbits/sec 72700 [ 4] 3.00-4.00 sec 97.9 MBytes 821 Mbits/sec 71885 [ 4] 4.00-5.00 sec 98.0 MBytes 822 Mbits/sec 71979 [ 4] 5.00-6.00 sec 100 MBytes 841 Mbits/sec 73640 [ 4] 6.00-7.00 sec 69.8 MBytes 585 Mbits/sec 51237 [ 4] 7.00-8.00 sec 94.9 MBytes 796 Mbits/sec 69650 [ 4] 8.00-9.00 sec 102 MBytes 855 Mbits/sec 74804 [ 4] 9.00-10.00 sec 100 MBytes 839 Mbits/sec 73407 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.00-10.00 sec 965 MBytes 809 Mbits/sec 0.004 ms 3194/708505 (0.45%) [ 4] Sent 708505 datagrams iperf Done. [root at raynor ~]# traceroute 40.80.156.2 traceroute to 40.80.156.2 (40.80.156.2), 30 hops max, 60 byte packets 1 gateway (71.6.220.97) 9.892 ms 10.883 ms 15.574 ms 2 209.126.134.65 (209.126.134.65) 1.541 ms 1.966 ms 1.959 ms 3 216.98.153.21 (216.98.153.21) 0.523 ms 0.517 ms 0.511 ms 4 216.98.153.114 (216.98.153.114) 0.589 ms 0.480 ms 0.687 ms 5 te0-0-1-0.nr11.b005949-0.san01.atlas.cogentco.com (38.104.122.61) 1.045 ms 1.039 ms 1.072 ms 6 te0-0-0-3.agr11.san01.atlas.cogentco.com (154.24.32.53) 1.023 ms 0.823 ms te0-0-0-3.agr12.san01.atlas.cogentco.com (154.24.32.65) 1.359 ms 7 te0-0-1-3.rcr11.san01.atlas.cogentco.com (154.24.31.21) 0.919 ms te0-0-1-3.rcr12.san01.atlas.cogentco.com (154.24.31.37) 0.834 ms 0.874 ms 8 be2936.rcr11.sna02.atlas.cogentco.com (154.54.45.166) 3.947 ms 3.726 ms be2937.rcr12.sna02.atlas.cogentco.com (154.54.45.173) 3.221 ms 9 be2463.agr22.lax01.atlas.cogentco.com (154.54.80.61) 4.095 ms 3.960 ms 4.087 ms 10 be2584.ccr41.lax01.atlas.cogentco.com (154.54.29.33) 4.364 ms 3.961 ms be2586.ccr41.lax01.atlas.cogentco.com (154.54.29.245) 4.290 ms 11 be3360.ccr41.lax04.atlas.cogentco.com (154.54.25.150) 4.283 ms be3271.ccr41.lax04.atlas.cogentco.com (154.54.42.102) 4.020 ms 4.003 ms 12 38.142.33.250 (38.142.33.250) 3.828 ms 3.818 ms 3.481 ms 13 be-61-0.ibr01.lax03.ntwk.msn.net (104.44.8.104) 15.565 ms 15.291 ms 15.173 ms 14 be-4-0.ibr01.by2.ntwk.msn.net (104.44.4.3) 14.290 ms 13.903 ms 16.168 ms 15 104.44.7.198 (104.44.7.198) 15.445 ms 14.098 ms 13.866 ms 16 ae102-0.icr02.by21.ntwk.msn.net (104.44.11.198) 13.752 ms ae100-0.icr01.by21.ntwk.msn.net (104.44.11.194) 14.378 ms ae101-0.icr01.by4.ntwk.msn.net (104.44.11.193) 13.813 ms [root at raynor ~]# scp ubuntu-14.04.5-desktop-amd64.iso carinet at 40.80.156.2:/home/carinet/ubuntunew10.iso ubuntu-14.04.5-desktop-amd64.iso 100% 1053MB 111.5MB/s 00:09 COGENT - summary CARIcloud to Azure 1.5 Gbits/s TCP iperf 850 Mbits/s UDP iperf 9s 1053 MB upload to Azure through SCP From SNaslund at medline.com Wed Nov 29 15:59:32 2017 From: SNaslund at medline.com (Naslund, Steve) Date: Wed, 29 Nov 2017 15:59:32 +0000 Subject: ATT AVPN BGP Communities In-Reply-To: References: Message-ID: <9578293AE169674F9A048B2BC9A081B4027313A6E0@MUNPRDMBXA1.medline.com> Ask your AT&T rep to get you the AVPN routing guide. That have a whole list of functions that can be manipulated by changing community information you send with a route. It is very useful and you would never figure it all out by just messing with it. I would send it to you but I don't have access at the moment. Steven Naslund Chicago IL -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Ryan, Spencer Sent: Wednesday, November 29, 2017 8:54 AM To: nanog at nanog.org Subject: ATT AVPN BGP Communities Hey All, Does anyone know if AVPN lets end users set/add their own communities to routes? I see that they stamp several on the routes we originate (Community: 13979:2741 13979:2943 13979:5000 13979:6551) and curious if anyone had luck adding their own before I go start mucking around. Thanks! Spencer Ryan | Senior Systems Administrator | sryan at arbor.net Arbor Networks | The security division of NETSCOUT +1.734.794.5033 (d) | +1.734.846.2053 (m) www.arbornetworks.com From ruairi.carroll at gmail.com Wed Nov 29 16:02:36 2017 From: ruairi.carroll at gmail.com (Ruairi Carroll) Date: Wed, 29 Nov 2017 16:02:36 +0000 Subject: tracking TCP session hop by hop In-Reply-To: References: Message-ID: Have a look at tcptraceroute: https://github.com/mct/tcptraceroute/blob/master/examples.txt On 28 November 2017 at 20:48, Yifeng Zhou wrote: > Hi Experts, > > Is there any way that we can track TCP session hop by hop? > > Say we have 10 ECMP between A and Z point, what's the easiest way to track > specific session is using which path? How we can check between > servers(Linux/Unix) and between Routers(Cisco/Juniper etc)? > > Thanks > > -Yifeng > From jrex at CS.Princeton.EDU Wed Nov 29 16:07:38 2017 From: jrex at CS.Princeton.EDU (Jennifer Rexford) Date: Wed, 29 Nov 2017 11:07:38 -0500 Subject: tracking TCP session hop by hop In-Reply-To: References: Message-ID: <556CB843-4AB1-4933-987A-BFB5E947B559@cs.princeton.edu> https://paris-traceroute.net/ > On Nov 28, 2017, at 3:48 PM, Yifeng Zhou wrote: > > Hi Experts, > > Is there any way that we can track TCP session hop by hop? > > Say we have 10 ECMP between A and Z point, what's the easiest way to track > specific session is using which path? How we can check between > servers(Linux/Unix) and between Routers(Cisco/Juniper etc)? > > Thanks > > -Yifeng From applebaumt at ochin.org Wed Nov 29 16:17:28 2017 From: applebaumt at ochin.org (Tyler Applebaum) Date: Wed, 29 Nov 2017 16:17:28 +0000 Subject: tracking TCP session hop by hop In-Reply-To: <556CB843-4AB1-4933-987A-BFB5E947B559@cs.princeton.edu> References: <556CB843-4AB1-4933-987A-BFB5E947B559@cs.princeton.edu> Message-ID: Somebody needs to renew their Let's Encrypt SSL cert. -----Original Message----- From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Jennifer Rexford Sent: Wednesday, November 29, 2017 8:08 AM To: Yifeng Zhou Cc: nanog at nanog.org Subject: Re: tracking TCP session hop by hop https://paris-traceroute.net/ > On Nov 28, 2017, at 3:48 PM, Yifeng Zhou wrote: > > Hi Experts, > > Is there any way that we can track TCP session hop by hop? > > Say we have 10 ECMP between A and Z point, what's the easiest way to > track specific session is using which path? How we can check between > servers(Linux/Unix) and between Routers(Cisco/Juniper etc)? > > Thanks > > -Yifeng Attention: Information contained in this message and or attachments is intended only for the recipient(s) named above and may contain confidential and or privileged material that is protected under State or Federal law. If you are not the intended recipient, any disclosure, copying, distribution or action taken on it is prohibited. If you believe you have received this email in error, please contact the sender with a copy to compliance at ochin.org, delete this email and destroy all copies. From amitchell at isipp.com Wed Nov 29 16:27:16 2017 From: amitchell at isipp.com (Anne P. Mitchell Esq.) Date: Wed, 29 Nov 2017 09:27:16 -0700 Subject: Anyone from Earthlink here? Message-ID: If anybody is here from Earthlink - or knows anyone at Earthlink, could you pretty please connect with me? Thank you! Anne Anne P. Mitchell, Attorney at Law Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law) Legislative Consultant CEO/President, Institute for Social Internet Public Policy Legal Counsel: The CyberGreen Institute Member, Cal. Bar Cyberspace Law Committee Member, Colorado Cyber Committee Member, Elevations Credit Union Member Council Member, Board of Directors, Asilomar Microcomputer Workshop Ret. Professor of Law, Lincoln Law School of San Jose Ret. Chair, Asilomar Microcomputer Workshop From eric.kuhnke at gmail.com Wed Nov 29 17:03:41 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 29 Nov 2017 09:03:41 -0800 Subject: Incoming SMTP in the year 2017 and absence of DKIM Message-ID: For those who operate public facing SMTPd that receive a large volume of incoming traffic, and accordingly, a lot of spam... How much weight do you put on an incoming message, in terms of adding additional score towards a possible value of spam, for total absence of DKIM signature? From bill at herrin.us Wed Nov 29 17:06:57 2017 From: bill at herrin.us (William Herrin) Date: Wed, 29 Nov 2017 12:06:57 -0500 Subject: tracking TCP session hop by hop In-Reply-To: References: Message-ID: On Tue, Nov 28, 2017 at 3:48 PM, Yifeng Zhou wrote: > Is there any way that we can track TCP session hop by hop? > > Say we have 10 ECMP between A and Z point, what's the easiest way to track > specific session is using which path? How we can check between > servers(Linux/Unix) and between Routers(Cisco/Juniper etc)? > A TCP connection is uniquely identified by the combination of four numbers: The source IP address, the source port, the destination IP address and the destination port. You used the word session, but sessions happen above TCP in the stack and may use more than one TCP connection. Every packet in the connection contains all four numbers and no packet from any other connection contains the same four numbers. If you want to track the connections, you capture the packets at each point in the path (router products have vendor-specific ways of doing this) and see which unique sets of the four numbers went through which router and router interface. If you want to -test- which path a TCP connection -would- take, Ruairi's afore-mentioned tcptraceroute is the way to go. The regular traceroute with modern Linux servers also supports the "-T" flag which does the same thing. It works just like regular traceroute but uses synthetic TCP SYN packets instead of ICMP or UDP packets, allowing the packets to pass firewalls which would otherwise block the trace. Bear in mind that in each case you will likely only see the path taken at the IP level. Underlying transits at the Ethernet or MPLS level are intentionally invisible to the endpoints. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From bill at herrin.us Wed Nov 29 17:09:29 2017 From: bill at herrin.us (William Herrin) Date: Wed, 29 Nov 2017 12:09:29 -0500 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: References: Message-ID: On Wed, Nov 29, 2017 at 12:03 PM, Eric Kuhnke wrote: > For those who operate public facing SMTPd that receive a large volume of > incoming traffic, and accordingly, a lot of spam... > > How much weight do you put on an incoming message, in terms of adding > additional score towards a possible value of spam, for total absence of > DKIM signature? > Zero. DKIM for mailing lists is a horribly broken design and legitimate mailing lists are second only to spam in quantity of SMTP transactions. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From sfrost at snowman.net Wed Nov 29 17:17:27 2017 From: sfrost at snowman.net (Stephen Frost) Date: Wed, 29 Nov 2017 12:17:27 -0500 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: References: Message-ID: <20171129171727.GQ4628@tamriel.snowman.net> Greetings, * William Herrin (bill at herrin.us) wrote: > On Wed, Nov 29, 2017 at 12:03 PM, Eric Kuhnke wrote: > > > For those who operate public facing SMTPd that receive a large volume of > > incoming traffic, and accordingly, a lot of spam... > > > > How much weight do you put on an incoming message, in terms of adding > > additional score towards a possible value of spam, for total absence of > > DKIM signature? > > Zero. DKIM for mailing lists is a horribly broken design and legitimate > mailing lists are second only to spam in quantity of SMTP transactions. Eh, that's really not accurate, imv, and some folks who run mailing lists have put in serious effort to make sure to *not* break DKIM signatures (which is certainly possible to do). The combination of making DKIM signatures work and DMARC allows messages to go through that would otherwise end up getting bounced, from what I've seen. What's annoying are the systems that appear to assume a DMARC policy that says "bounce it if it's not from a server in our SPF list" when there's no DMARC policy in place, but there is an SPF list. Not everyone really wants to put in the effort to set up DKIM, but they're fine putting up an SPF record, but there seem to be a number of servers out there that bounce mailing list traffic in those cases (seems to specifically be MS Exchange systems, from the google'ing that I've done). Thanks! Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From bill at herrin.us Wed Nov 29 17:24:55 2017 From: bill at herrin.us (William Herrin) Date: Wed, 29 Nov 2017 12:24:55 -0500 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <20171129171727.GQ4628@tamriel.snowman.net> References: <20171129171727.GQ4628@tamriel.snowman.net> Message-ID: On Wed, Nov 29, 2017 at 12:17 PM, Stephen Frost wrote: > * William Herrin (bill at herrin.us) wrote: > > On Wed, Nov 29, 2017 at 12:03 PM, Eric Kuhnke > wrote: > > > How much weight do you put on an incoming message, in terms of adding > > > additional score towards a possible value of spam, for total absence of > > > DKIM signature? > > > > Zero. DKIM for mailing lists is a horribly broken design and legitimate > > mailing lists are second only to spam in quantity of SMTP transactions. > > Eh, that's really not accurate, imv, and some folks who run mailing > lists have put in serious effort to make sure to *not* break DKIM > signatures (which is certainly possible to do). Alright, so "horribly broken design" overstates the case but there are enough problems that weighting the absence of DKIM at something other than zero will surely do more harm than good. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From mike at mtcc.com Wed Nov 29 17:32:27 2017 From: mike at mtcc.com (Michael Thomas) Date: Wed, 29 Nov 2017 09:32:27 -0800 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: References: <20171129171727.GQ4628@tamriel.snowman.net> Message-ID: On 11/29/2017 09:24 AM, William Herrin wrote: > On Wed, Nov 29, 2017 at 12:17 PM, Stephen Frost wrote: > >> * William Herrin (bill at herrin.us) wrote: >>> On Wed, Nov 29, 2017 at 12:03 PM, Eric Kuhnke >> wrote: >>>> How much weight do you put on an incoming message, in terms of adding >>>> additional score towards a possible value of spam, for total absence of >>>> DKIM signature? >>> Zero. DKIM for mailing lists is a horribly broken design and legitimate >>> mailing lists are second only to spam in quantity of SMTP transactions. >> Eh, that's really not accurate, imv, and some folks who run mailing >> lists have put in serious effort to make sure to *not* break DKIM >> signatures (which is certainly possible to do). > > Alright, so "horribly broken design" overstates the case but there are > enough problems that weighting the absence of DKIM at something other than > zero will surely do more harm than good. > There are quite a few things you can do to get the mailing list traversal rate > 90%, iirc. For average mailman-like lists like nanog it's very high. Of course while a "badly" behaving mailing list can trivially defeat any DKIM signature, it doesn't really take too much effort to not behave "badly". Whether that false positive rate is too high is another question. Mike From ken at wemonitoremail.com Wed Nov 29 18:02:53 2017 From: ken at wemonitoremail.com (Ken O'Driscoll) Date: Wed, 29 Nov 2017 18:02:53 +0000 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: References: <20171129171727.GQ4628@tamriel.snowman.net> Message-ID: <1511978573.2592.17.camel@wemonitoremail.com> On Wed, 2017-11-29 at 12:24 -0500, William Herrin wrote: > Alright, so "horribly broken design" overstates the case but there are > enough problems that weighting the absence of DKIM at something other > than zero will surely do more harm than good. +1. A DKIM signature by itself means nothing more than someone had the ability to configure DKIM on an email server. The signing domain (d=) is what matters as the signer needs access to the zone in order to be able to publish the key, which may be interpreted as an indication of trust. DMARC requires the signing domain to be either exactly the same or share the same organisational unit with the From address for this reason. Even without DMARC, a receiver *could*, depending on the signing domain, choose to interpret it as a positive signal. This is marginally better than treating any DKIM signature or the absence thereof as a signal of any kind. Personally, unless an author domain is publishing a DMARC policy of reject or quarantine, I don't think recipients should be scoring based on DKIM at all, perhaps with the exception of signing with a revoked key. Ken. --  Ken O'Driscoll / We Monitor Email t: +353 1 254 9400 | w: www.wemonitoremail.com Need to understand deliverability? Now there's a book: www.wemonitoremail.com/book From valdis.kletnieks at vt.edu Wed Nov 29 18:03:31 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 29 Nov 2017 13:03:31 -0500 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: References: <20171129171727.GQ4628@tamriel.snowman.net> Message-ID: <216085.1511978611@turing-police.cc.vt.edu> On Wed, 29 Nov 2017 09:32:27 -0800, Michael Thomas said: > There are quite a few things you can do to get the mailing list > traversal rate > 90%, iirc. Only 90% should be considered horribly broken. Anything that makes it difficult to run a simple mailing list with less that at least 2 or 3 9's is unacceptable. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From mike at mtcc.com Wed Nov 29 18:12:05 2017 From: mike at mtcc.com (Michael Thomas) Date: Wed, 29 Nov 2017 10:12:05 -0800 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <216085.1511978611@turing-police.cc.vt.edu> References: <20171129171727.GQ4628@tamriel.snowman.net> <216085.1511978611@turing-police.cc.vt.edu> Message-ID: <1d458e76-ab61-db28-79cb-6aabcab4ff3b@mtcc.com> On 11/29/2017 10:03 AM, valdis.kletnieks at vt.edu wrote: > On Wed, 29 Nov 2017 09:32:27 -0800, Michael Thomas said: > >> There are quite a few things you can do to get the mailing list >> traversal rate > 90%, iirc. > Only 90% should be considered horribly broken. Anything that makes > it difficult to run a simple mailing list with less that at least 2 or 3 9's > is unacceptable. I've been saying for years that it should be possible to create the concept of DKIM-friendly mailing lists. In such a case, you could have your nines. Until then, the best you can hope for is the list re-signing the mail and blaming the list owner instead. Mike From eric.kuhnke at gmail.com Wed Nov 29 18:18:31 2017 From: eric.kuhnke at gmail.com (Eric Kuhnke) Date: Wed, 29 Nov 2017 10:18:31 -0800 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <1d458e76-ab61-db28-79cb-6aabcab4ff3b@mtcc.com> References: <20171129171727.GQ4628@tamriel.snowman.net> <216085.1511978611@turing-police.cc.vt.edu> <1d458e76-ab61-db28-79cb-6aabcab4ff3b@mtcc.com> Message-ID: Anecdotal experience. I'm subscribed to a lot of mailing lists. Some pass through DKIM correctly. Others re-sign the message with DKIM from their own server. >98% of the spam that gets through my filters, which comes from an IP not in any of the major RBLs, has no DKIM signature for the domain. My theory is that it does introduce somewhat of a barrier to spam senders because they are frequently not in control of the mail server (which may be some ignorant third party's open relay), nor do they have access to the zonefile for the domain the mail server belongs to for the purpose of adding any sort of DKIM record. On Wed, Nov 29, 2017 at 10:12 AM, Michael Thomas wrote: > On 11/29/2017 10:03 AM, valdis.kletnieks at vt.edu wrote: > >> On Wed, 29 Nov 2017 09:32:27 -0800, Michael Thomas said: >> >> There are quite a few things you can do to get the mailing list >>> traversal rate > 90%, iirc. >>> >> Only 90% should be considered horribly broken. Anything that makes >> it difficult to run a simple mailing list with less that at least 2 or 3 >> 9's >> is unacceptable. >> > > I've been saying for years that it should be possible to create the > concept of DKIM-friendly mailing lists. In such > a case, you could have your nines. Until then, the best you can hope for > is the list re-signing the mail and blaming > the list owner instead. > > Mike > > From mike at mtcc.com Wed Nov 29 18:33:00 2017 From: mike at mtcc.com (Michael Thomas) Date: Wed, 29 Nov 2017 10:33:00 -0800 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: References: <20171129171727.GQ4628@tamriel.snowman.net> <216085.1511978611@turing-police.cc.vt.edu> <1d458e76-ab61-db28-79cb-6aabcab4ff3b@mtcc.com> Message-ID: <5544b6ca-5d84-1c0e-1614-c839b68138e0@mtcc.com> A broken DKIM signature is indistinguishable from a lack of a signature header. It's possible that as a heuristic you might be able to divine something from lack of signature and the existence of selectors for a domain, but afaik there isn't an easy way to query for all of the dkim selectors for a domain, and even if there were it would be a pretty sketchy heuristic, is my bet. Mike On 11/29/2017 10:18 AM, Eric Kuhnke wrote: > Anecdotal experience. I'm subscribed to a lot of mailing lists. Some pass > through DKIM correctly. Others re-sign the message with DKIM from their own > server. > >> 98% of the spam that gets through my filters, which comes from an IP not > in any of the major RBLs, has no DKIM signature for the domain. My theory > is that it does introduce somewhat of a barrier to spam senders because > they are frequently not in control of the mail server (which may be some > ignorant third party's open relay), nor do they have access to the zonefile > for the domain the mail server belongs to for the purpose of adding any > sort of DKIM record. > > > > On Wed, Nov 29, 2017 at 10:12 AM, Michael Thomas wrote: > >> On 11/29/2017 10:03 AM, valdis.kletnieks at vt.edu wrote: >> >>> On Wed, 29 Nov 2017 09:32:27 -0800, Michael Thomas said: >>> >>> There are quite a few things you can do to get the mailing list >>>> traversal rate > 90%, iirc. >>>> >>> Only 90% should be considered horribly broken. Anything that makes >>> it difficult to run a simple mailing list with less that at least 2 or 3 >>> 9's >>> is unacceptable. >>> >> I've been saying for years that it should be possible to create the >> concept of DKIM-friendly mailing lists. In such >> a case, you could have your nines. Until then, the best you can hope for >> is the list re-signing the mail and blaming >> the list owner instead. >> >> Mike >> >> From peter.phaal at gmail.com Wed Nov 29 19:34:24 2017 From: peter.phaal at gmail.com (Peter Phaal) Date: Wed, 29 Nov 2017 11:34:24 -0800 Subject: tracking TCP session hop by hop In-Reply-To: References: Message-ID: On Wed, Nov 29, 2017 at 9:06 AM, William Herrin wrote: > On Tue, Nov 28, 2017 at 3:48 PM, Yifeng Zhou > wrote: > > > Is there any way that we can track TCP session hop by hop? > > > > Say we have 10 ECMP between A and Z point, what's the easiest way to > track > > specific session is using which path? How we can check between > > servers(Linux/Unix) and between Routers(Cisco/Juniper etc)? > > > > A TCP connection is uniquely identified by the combination of four numbers: > The source IP address, the source port, the destination IP address and the > destination port. You used the word session, but sessions happen above TCP > in the stack and may use more than one TCP connection. Every packet in the > connection contains all four numbers and no packet from any other > connection contains the same four numbers. > > If you want to track the connections, you capture the packets at each point > in the path (router products have vendor-specific ways of doing this) and > see which unique sets of the four numbers went through which router and > router interface. > > > If you want to -test- which path a TCP connection -would- take, Ruairi's > afore-mentioned tcptraceroute is the way to go. The regular traceroute with > modern Linux servers also supports the "-T" flag which does the same thing. > It works just like regular traceroute but uses synthetic TCP SYN packets > instead of ICMP or UDP packets, allowing the packets to pass firewalls > which would otherwise block the trace. > > Bear in mind that in each case you will likely only see the path taken at > the IP level. Underlying transits at the Ethernet or MPLS level are > intentionally invisible to the endpoints. > > In the data center context, enabling sFlow continuously captures packets from all paths and can be used to trace multi-path packet flows, whether layer 2 (MLAG/LAG), or layer 3 (ECMP). sFlow reports physical switch ports and captures Ethernet packet headers, so you can relate paths to MPLS labels, Ethernet headers, IP headers, TCP/UDP headers, VxLAN tunnels, etc. The following article provides an example: http://blog.sflow.com/2017/09/troubleshooting-connectivity-problems.html From gtaylor at tnetconsulting.net Wed Nov 29 19:53:01 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Nov 2017 12:53:01 -0700 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <5544b6ca-5d84-1c0e-1614-c839b68138e0@mtcc.com> References: <20171129171727.GQ4628@tamriel.snowman.net> <216085.1511978611@turing-police.cc.vt.edu> <1d458e76-ab61-db28-79cb-6aabcab4ff3b@mtcc.com> <5544b6ca-5d84-1c0e-1614-c839b68138e0@mtcc.com> Message-ID: On 11/29/2017 11:33 AM, Michael Thomas wrote: > A broken DKIM signature is indistinguishable from a lack of a signature > header. I'll argue that it's possible to distinguish between the two. *However* the DKIM standard states that you should treat a broken DKIM signature the same as no DKIM signature. I've come to understand DKIM to be proof /positive/, as in trust something when there is a DKIM signature -and- it validates. Everything else defaults to neutral, NOT /negative/. > It's possible that as a heuristic you might be able to divine something > from lack of signature and the existence of selectors for a domain, but > afaik there isn't an easy way to query for all of the dkim selectors for > a domain, and even if there were it would be a pretty sketchy heuristic, > is my bet. Not being able to tell if DKIM is in use has been a long standing annoyance of mine. That being said, I think it could be trivial to query for DMARC records and deduce things from the existence of the "adkim" option. If it's there and set to reject, then there really should be DKIM-Signature header for the message. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Wed Nov 29 19:55:27 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Nov 2017 12:55:27 -0700 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <216085.1511978611@turing-police.cc.vt.edu> References: <20171129171727.GQ4628@tamriel.snowman.net> <216085.1511978611@turing-police.cc.vt.edu> Message-ID: <88a1ae22-a5c1-dc46-caa7-cca813109e99@tnetconsulting.net> On 11/29/2017 11:03 AM, valdis.kletnieks at vt.edu wrote: > Only 90% should be considered horribly broken. Anything that makes it > difficult to run a simple mailing list with less that at least 2 or 3 > 9's is unacceptable. There have been a number of things that fall into that category, two of which immediately come to mind are: - Requiring Reverse DNS - SPF I'm not commenting about the viability of these things, just that they are fairly well accepted and that they can trivially break mailing lists. IMHO, DKIM and DMARC are just the recent additions to that list. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From mike at mtcc.com Wed Nov 29 20:17:57 2017 From: mike at mtcc.com (Michael Thomas) Date: Wed, 29 Nov 2017 12:17:57 -0800 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: References: <20171129171727.GQ4628@tamriel.snowman.net> <216085.1511978611@turing-police.cc.vt.edu> <1d458e76-ab61-db28-79cb-6aabcab4ff3b@mtcc.com> <5544b6ca-5d84-1c0e-1614-c839b68138e0@mtcc.com> Message-ID: <85393a12-a51f-6722-4171-118919fcc2d0@mtcc.com> On 11/29/2017 11:53 AM, Grant Taylor via NANOG wrote: > On 11/29/2017 11:33 AM, Michael Thomas wrote: >> A broken DKIM signature is indistinguishable from a lack of a >> signature header. > > I'll argue that it's possible to distinguish between the two. > *However* the DKIM standard states that you should treat a broken DKIM > signature the same as no DKIM signature. Remember: if you treat a broken signature better than lack of signature, spammers will just insert phony signatures to game you. So they really are the same. > Not being able to tell if DKIM is in use has been a long standing > annoyance of mine. > > That being said, I think it could be trivial to query for DMARC > records and deduce things from the existence of the "adkim" option. > If it's there and set to reject, then there really should be > DKIM-Signature header for the message. I haven't really kept up with dmarc, but its progenitor ssp could give you that indication, iirc. The real problem with large enterprise that we found, however, is that it was really hard to track down every 25 year old 386 sitting in dusty corners that was sending mail directly instead of through corpro servers to make certain that everything was signed that should be signed. Maybe that's gotten better in the last 15 years, but I'm not too hopeful. Mike From blake at ispn.net Wed Nov 29 20:35:12 2017 From: blake at ispn.net (Blake Hudson) Date: Wed, 29 Nov 2017 14:35:12 -0600 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: References: Message-ID: Eric Kuhnke wrote on 11/29/2017 11:03 AM: > For those who operate public facing SMTPd that receive a large volume of > incoming traffic, and accordingly, a lot of spam... > > How much weight do you put on an incoming message, in terms of adding > additional score towards a possible value of spam, for total absence of > DKIM signature? Spammers can:     A) Establish domains that use SPF and DKIM as well as anyone else     B) Use the stolen credentials of legitimate accounts on legitimate servers to relay SPAM messages. So the presence of SPF/DKIM does not reliably indicate whether the message is spam or not - only that the sender is "authenticated". The lack of optional tech like SPF and DKIM might be used as a heuristic, but it's not reliable enough to use in practice in my opinion. I wouldn't quarantine or reject messages that are missing these optional technology because the take rate isn't high enough. Where DKIM/SPF really help is when there's a failure that indicates a message has been spoofed. This is a good indication of phishing and is a justified reason to reject or quarantine a message in the interest of your employees or subscribers. Sometimes these will be config errors, but I feel confident telling the sender to take config issues up with their service provider. From cra at WPI.EDU Wed Nov 29 20:38:29 2017 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 29 Nov 2017 15:38:29 -0500 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <85393a12-a51f-6722-4171-118919fcc2d0@mtcc.com> References: <20171129171727.GQ4628@tamriel.snowman.net> <216085.1511978611@turing-police.cc.vt.edu> <1d458e76-ab61-db28-79cb-6aabcab4ff3b@mtcc.com> <5544b6ca-5d84-1c0e-1614-c839b68138e0@mtcc.com> <85393a12-a51f-6722-4171-118919fcc2d0@mtcc.com> Message-ID: <20171129203829.GJ13113@angus.ind.wpi.edu> On Wed, Nov 29, 2017 at 12:17:57PM -0800, Michael Thomas wrote: > The real problem with large enterprise that we found, however, is > that it was really hard to track down every 25 year > old 386 sitting in dusty corners that was sending mail directly > instead of through corpro servers to make certain > that everything was signed that should be signed. Maybe that's > gotten better in the last 15 years, but I'm not too hopeful. 15 years ago we blocked outbound port 25 except from our campus mail servers. That should be SOP by now. It is fairly easy to look at firewall logs to find these. From gtaylor at tnetconsulting.net Wed Nov 29 20:44:23 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Nov 2017 13:44:23 -0700 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <85393a12-a51f-6722-4171-118919fcc2d0@mtcc.com> References: <20171129171727.GQ4628@tamriel.snowman.net> <216085.1511978611@turing-police.cc.vt.edu> <1d458e76-ab61-db28-79cb-6aabcab4ff3b@mtcc.com> <5544b6ca-5d84-1c0e-1614-c839b68138e0@mtcc.com> <85393a12-a51f-6722-4171-118919fcc2d0@mtcc.com> Message-ID: On 11/29/2017 01:17 PM, Michael Thomas wrote: > Remember: if you treat a broken signature better than lack of signature, > spammers will just insert phony signatures to game you. > > So they really are the same. Yes, they are /effectively/ the same. However it is possible to distinguish between a broken DKIM signature and the lack of a DKIM signature. What you do with that information is up to you. - Guidelines suggest that you treat them the same. (Thus them being /effectively/ the same.) > The real problem with large enterprise that we found, however, is that > it was really hard to track down every 25 year > old 386 sitting in dusty corners that was sending mail directly instead > of through corpro servers to make certain > that everything was signed that should be signed. Maybe that's gotten > better in the last 15 years, but I'm not too hopeful. I hear you, and I don't disagree with your sentiments about the difficult of the matter. However, I find it highly suspect that such systems ancient are still in use. There may very well be replacements for said systems that are < 20 years old. Either way, they would still run afoul of things like SPF (unless you allow your entire IP space to send email). There are other security / vulnerability implications of such infrastructures. - I'd argue that they are motivation enough to wrangle these rogue systems. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From gtaylor at tnetconsulting.net Wed Nov 29 20:48:25 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Nov 2017 13:48:25 -0700 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: References: Message-ID: On 11/29/2017 01:35 PM, Blake Hudson wrote: > Where DKIM/SPF really help is when there's a failure that indicates a > message has been spoofed. There are other legitimate things that can break DKIM signatures. I have personally seen changes in content type encoding break a DKIM signature. The message was perfectly valid, and only failed DKIM signature validation. > This is a good indication of phishing and is a > justified reason to reject or quarantine a message in the interest of > your employees or subscribers. As much as I would like to be able to safely reject on DKIM Signature validation failure, I don't think that it is safe to do so. > Sometimes these will be config errors, > but I feel confident telling the sender to take config issues up with > their service provider. Hopefully this will bring the perceived problem to someone's attention who can hypothetically do something to correct it. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From kmedcalf at dessus.com Wed Nov 29 20:58:53 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 29 Nov 2017 13:58:53 -0700 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: Message-ID: <64331e6793dff6459f0c2acd55febefb@mail.dessus.com> In which case neither will they be RFC compliant. (1) The "inaddr-arpa" ptr from the incoming connection, when resolved, MUST result in a set of IP Addresses which includes the original IP Address. (2) The "name" specified in the HELO/EHLO MUST resolve to an MTA that meets the above reverse/forward resolution requirement. (3) The domain name specified in the envelope-from MUST be resolvable to an MTA that meets the above requirement (1) or be empty. (4) The SPF checking, if done, MUST NOT fail. (5) The connecting MTA MUST NOT speak when not spoken to (that is, it MUST NOT not violate the SMTP chat protocol). If you dump all connections that are do not meet these requirements, you will have eliminated 99% or more of all spam. DKIM signatures do not really add much at all except prove that the message was sent through a server that could calculate a DKIM signature. It says nothing about whether the message is SPAM or not. 99% (or more) of all spam will have violated one or more of rules (1) through (5) long before the message contents are accepted so that the signature can be verified. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Eric Kuhnke >Sent: Wednesday, 29 November, 2017 11:19 >To: nanog at nanog.org list >Subject: Re: Incoming SMTP in the year 2017 and absence of DKIM > >Anecdotal experience. I'm subscribed to a lot of mailing lists. Some >pass >through DKIM correctly. Others re-sign the message with DKIM from >their own >server. > >>98% of the spam that gets through my filters, which comes from an IP >not >in any of the major RBLs, has no DKIM signature for the domain. My >theory >is that it does introduce somewhat of a barrier to spam senders >because >they are frequently not in control of the mail server (which may be >some >ignorant third party's open relay), nor do they have access to the >zonefile >for the domain the mail server belongs to for the purpose of adding >any >sort of DKIM record. > > > >On Wed, Nov 29, 2017 at 10:12 AM, Michael Thomas >wrote: > >> On 11/29/2017 10:03 AM, valdis.kletnieks at vt.edu wrote: >> >>> On Wed, 29 Nov 2017 09:32:27 -0800, Michael Thomas said: >>> >>> There are quite a few things you can do to get the mailing list >>>> traversal rate > 90%, iirc. >>>> >>> Only 90% should be considered horribly broken. Anything that >makes >>> it difficult to run a simple mailing list with less that at least >2 or 3 >>> 9's >>> is unacceptable. >>> >> >> I've been saying for years that it should be possible to create the >> concept of DKIM-friendly mailing lists. In such >> a case, you could have your nines. Until then, the best you can >hope for >> is the list re-signing the mail and blaming >> the list owner instead. >> >> Mike >> >> From Brian at ampr.org Wed Nov 29 18:35:35 2017 From: Brian at ampr.org (Brian Kantor) Date: Wed, 29 Nov 2017 10:35:35 -0800 Subject: Incoming SMTP in the year 2017 and absence of DKIM Message-ID: <20171129183535.GB18534@UCSD.Edu> As I see it, the problem isn't with DKIM, it's with the implementation of DMARC and other such filters. Almost all of them TEST THE WRONG FROM ADDRESS. They compare the Author's address (the header From: line) instead of the Sender's address, (the SMTP Mail From: transaction or Sender: header line). For personal mail, these are almost always the same, but for properly-functioning mailing lists, the Author address is the email address of the person submitting the posting to the mailing list, and the Sender address is the error-return ("bounce") address of the mailing list. If the filter checked the Sender address of mail instead of the Author address, mailing lists wouldn't be broken! - Brian On Wed, Nov 29, 2017 at 10:12:05AM -0800, Michael Thomas wrote: > I've been saying for years that it should be possible to create the concept > of DKIM-friendly mailing lists. In such > a case, you could have your nines. Until then, the best you can hope for is > the list re-signing the mail and blaming > the list owner instead. > > Mike From zhuifeng0426 at gmail.com Wed Nov 29 18:41:13 2017 From: zhuifeng0426 at gmail.com (Yifeng Zhou) Date: Wed, 29 Nov 2017 10:41:13 -0800 Subject: tracking TCP session hop by hop In-Reply-To: References: Message-ID: Thank you all for the reply! I think traceroute/tcptraceroute is a good way to track tcp session as we can use same 5 tuple as normal TCP does. Bill brought up an interesting point about MPLS and Ethernet, I give it a bit of think and here's what i can tell, please correct me if i'm wrong for MPLS, everything should be the same prior enter MPLS cloud. At ingress router, it will push MPLS label (also entropy label if enabled), but it should be the same for traceroute traffic and actual TCP traffic(we have same 4 tuple, or 5, including incoming interface on router), so the label/entropy label should be same. Inside MPLS cloud, normally router will use mpls label, src, dst ip, port number(or entropy label if enabled) as hash seed(depends on configuration) to calculate which ECMP path it will use. Choose member link inside lAG might be another story for non-entropy enabled MPLS cloud, but we don't really care as they belong to same IP(layer-3) path, but I think they should be same as well? Thanks 2017-11-29 9:06 GMT-08:00 William Herrin : > On Tue, Nov 28, 2017 at 3:48 PM, Yifeng Zhou > wrote: > >> Is there any way that we can track TCP session hop by hop? >> >> Say we have 10 ECMP between A and Z point, what's the easiest way to track >> specific session is using which path? How we can check between >> servers(Linux/Unix) and between Routers(Cisco/Juniper etc)? >> > > A TCP connection is uniquely identified by the combination of four > numbers: The source IP address, the source port, the destination IP address > and the destination port. You used the word session, but sessions happen > above TCP in the stack and may use more than one TCP connection. Every > packet in the connection contains all four numbers and no packet from any > other connection contains the same four numbers. > > If you want to track the connections, you capture the packets at each > point in the path (router products have vendor-specific ways of doing this) > and see which unique sets of the four numbers went through which router and > router interface. > > > If you want to -test- which path a TCP connection -would- take, Ruairi's > afore-mentioned tcptraceroute is the way to go. The regular traceroute with > modern Linux servers also supports the "-T" flag which does the same thing. > It works just like regular traceroute but uses synthetic TCP SYN packets > instead of ICMP or UDP packets, allowing the packets to pass firewalls > which would otherwise block the trace. > > Bear in mind that in each case you will likely only see the path taken at > the IP level. Underlying transits at the Ethernet or MPLS level are > intentionally invisible to the endpoints. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From johnl at iecc.com Wed Nov 29 21:11:18 2017 From: johnl at iecc.com (John Levine) Date: 29 Nov 2017 21:11:18 -0000 Subject: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <1d458e76-ab61-db28-79cb-6aabcab4ff3b@mtcc.com> Message-ID: <20171129211118.22256.qmail@ary.lan> In article <1d458e76-ab61-db28-79cb-6aabcab4ff3b at mtcc.com> you write: >I've been saying for years that it should be possible to create the >concept of DKIM-friendly mailing lists. ... I suppose, if your users are OK with no subject tags, message footers, or any of the other cruft that list users have taken for granted for the past 30 years. The people who brought us DMARC have a new anti-DMARC thing called ARC that is intended to help recipients guess whether a message with a broken signature came through a mailing list. It's a kludge, but since it's a kludge that Gmail has already implemented, you'll be seeing more of it. Returning to the original question, if a message has no DKIM signature, that doesn't say anything particularly bad, but it does mean that the sending IP is your main bit of info to decide whether it's mail you want, which has issues of its own. R's, John PS: details here https://dmarc.org/resources/specification/ PPS: Please spare us pontification about why ARC can't possibly work unless you're prepared to cite section numbers in the ARC spec supporting your argument. From johnl at iecc.com Wed Nov 29 21:13:27 2017 From: johnl at iecc.com (John Levine) Date: 29 Nov 2017 21:13:27 -0000 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <88a1ae22-a5c1-dc46-caa7-cca813109e99@tnetconsulting.net> Message-ID: <20171129211327.22279.qmail@ary.lan> In article <88a1ae22-a5c1-dc46-caa7-cca813109e99 at tnetconsulting.net> you write: > - Requiring Reverse DNS > - SPF > >I'm not commenting about the viability of these things, just that they >are fairly well accepted and that they can trivially break mailing lists. A mailing list sending with bad rDNS or bad SPF is a pretty cruddy mailing list. Normal lists put their own bounce address in the envelope so they can handle the bounces, so their own SPF applies. No idea why you think rDNS for a list's MTA is any harder than anyone else's MTA. R's, John From johnl at iecc.com Wed Nov 29 21:24:07 2017 From: johnl at iecc.com (John Levine) Date: 29 Nov 2017 21:24:07 -0000 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <85393a12-a51f-6722-4171-118919fcc2d0@mtcc.com> Message-ID: <20171129212407.22339.qmail@ary.lan> In article <85393a12-a51f-6722-4171-118919fcc2d0 at mtcc.com> you write: >The real problem with large enterprise that we found, however, is that >it was really hard to track down every 25 year >old 386 sitting in dusty corners that was sending mail directly instead >of through corpro servers to make certain >that everything was signed that should be signed. Maybe that's gotten >better in the last 15 years, but I'm not too hopeful. No kidding. That's why you publish a DMARC policy record that says don't treat my mail any differently, but please send me summary reports about it. This lets you see where mail with your From: domain is coming from, to track down all those dusty servers. Once you've found them all, then you can decide whether publishing a policy is likely make things better or worse. You'll also find a whole lot of Chinese botnets that send out spam with random return addresses including yours, but they're not hard to tell apart. R's, John From gtaylor at tnetconsulting.net Wed Nov 29 21:27:28 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Nov 2017 14:27:28 -0700 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <20171129183535.GB18534@UCSD.Edu> References: <20171129183535.GB18534@UCSD.Edu> Message-ID: On 11/29/2017 11:35 AM, Brian Kantor wrote: > As I see it, the problem isn't with DKIM, I don't think DKIM is (the source of) /the/ problem per say. Rather I think it's a complication of other things (DMARC) that interact with DKIM. > it's with the > implementation of DMARC and other such filters. Almost all > of them TEST THE WRONG FROM ADDRESS. They compare the Author's > address (the header From: line) instead of the Sender's address, > (the SMTP Mail From: transaction or Sender: header line). I believe it's more than just the implementation. The DMARC specification specifically calls out the RFC 5322 From: header. Further, RFC 7489, Appendix A, § 3 speaks directly to this. > If the filter checked the Sender address of mail instead of the > Author address, mailing lists wouldn't be broken! Perhaps. However I fear we would be facing an entirely new type of spam that used spoofed From: headers and perfectly legitimate Sender: headers (that also match the RFC 5321 SMTP FROM address.) See RFC 7489 § A.3.1 -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From johnl at iecc.com Wed Nov 29 21:27:39 2017 From: johnl at iecc.com (John Levine) Date: 29 Nov 2017 21:27:39 -0000 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <20171129183535.GB18534@UCSD.Edu> Message-ID: <20171129212739.22365.qmail@ary.lan> In article <20171129183535.GB18534 at UCSD.Edu> you write: >As I see it, the problem isn't with DKIM, it's with the >implementation of DMARC and other such filters. Almost all >of them TEST THE WRONG FROM ADDRESS. They compare the Author's >address (the header From: line) instead of the Sender's address, Sigh. I have my differences with the people who designed DMARC but they are not stupid and they really do understand the relevant RFCs. Some of them even wrote some of those RFCs. The reason they look at the From: line is that's the one recipients see. The Sender: header was a nice idea but in practice, it's not useful. R's, John From gtaylor at tnetconsulting.net Wed Nov 29 21:35:43 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Nov 2017 14:35:43 -0700 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <20171129211327.22279.qmail@ary.lan> References: <20171129211327.22279.qmail@ary.lan> Message-ID: <3677d101-3874-b8e4-87b3-37e4dd870325@tnetconsulting.net> On 11/29/2017 02:13 PM, John Levine wrote: > A mailing list sending with bad rDNS or bad SPF is a pretty cruddy > mailing list. s/mailing list sending/sending server/ Agreed. > Normal lists put their own bounce address in the > envelope so they can handle the bounces, so their own SPF applies. Yep. V.E.R.P. is a very powerful thing. (B.A.T.V. is an interesting alternative, but I never messed with it.) > No idea why you think rDNS for a list's MTA is any harder than anyone > else's MTA. I don't. I'm saying that I've heard arguments over the last 15 years from people that (FC)rDNS and SPF (independently) are things that will break some portion of email. - I believe that these are simply technologies that the email industry has adopted and now considers to be Best Practice, if not actual requirements that MUST be done. IMHO, Mailing List Managers are simply a different form of MUA that utilizes the same email infrastructure (MTAs.) Thus, MLMs are subject tot he same requirements as "individual email" (as referred to earlier.) -- Grant. . . . unix || die P.S. I'm strongly of the opinion that if a MLM alters the message in ANY capacity, that it is actually generating a new message. Thus the MLM is the new author. It's just using content strongly based on emails that came into it. - But that's a different discussion that lasted days on the mailman mailing list. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From kmedcalf at dessus.com Wed Nov 29 22:09:40 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Wed, 29 Nov 2017 15:09:40 -0700 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <20171129212739.22365.qmail@ary.lan> Message-ID: <11e9c18dac053c4bb91b95a4993c116f@mail.dessus.com> Not old enough to have had an Executive Secretary processing your incoming snail-mail before it gets to you? The "envelope" in which a letter arrived is just as important as the letter itself and contains valuable information that is duplicated in e-mail -- the postmark (received headers), the return address (mail from); and, the delivery address (mail to). It was an offense to discard the envelope in which correspondence arrived since it is used to determine the validity of the snail mail. Current e-mail clients are comparable to having a secretary that throws out the envelope and snips off most of the inside addressing information and delivers only the heavily redacted letter so that no determination of its validity is possible. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of John Levine >Sent: Wednesday, 29 November, 2017 14:28 >To: nanog at nanog.org >Subject: Re: Incoming SMTP in the year 2017 and absence of DKIM > >In article <20171129183535.GB18534 at UCSD.Edu> you write: >>As I see it, the problem isn't with DKIM, it's with the >>implementation of DMARC and other such filters. Almost all >>of them TEST THE WRONG FROM ADDRESS. They compare the Author's >>address (the header From: line) instead of the Sender's address, > >Sigh. I have my differences with the people who designed DMARC but >they are not stupid and they really do understand the relevant RFCs. >Some of them even wrote some of those RFCs. > >The reason they look at the From: line is that's the one recipients >see. The Sender: header was a nice idea but in practice, it's not >useful. > >R's, >John From mike at mtcc.com Wed Nov 29 22:24:01 2017 From: mike at mtcc.com (Michael Thomas) Date: Wed, 29 Nov 2017 14:24:01 -0800 Subject: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <20171129211118.22256.qmail@ary.lan> References: <20171129211118.22256.qmail@ary.lan> Message-ID: <3d3eff60-71ad-8866-37ed-8564429cb010@mtcc.com> On 11/29/2017 01:11 PM, John Levine wrote: > In article <1d458e76-ab61-db28-79cb-6aabcab4ff3b at mtcc.com> you write: >> I've been saying for years that it should be possible to create the >> concept of DKIM-friendly mailing lists. ... > I suppose, if your users are OK with no subject tags, message footers, > or any of the other cruft that list users have taken for granted for > the past 30 years. > Message footers and subject lines can be dealt with. That's already been proven within the current DKIM spec. Mike From gtaylor at tnetconsulting.net Wed Nov 29 22:40:24 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Nov 2017 15:40:24 -0700 Subject: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <3d3eff60-71ad-8866-37ed-8564429cb010@mtcc.com> References: <20171129211118.22256.qmail@ary.lan> <3d3eff60-71ad-8866-37ed-8564429cb010@mtcc.com> Message-ID: On 11/29/2017 03:24 PM, Michael Thomas wrote: > Message footers and subject lines can be dealt with. That's already been > proven within the current DKIM spec. Please humor my ignorance and explain how a subject line (which is (over)signed) can be dealt with in the current DKIM spec? I get how footers can be dealt with, read appended. At least as long as DKIM only signs a given amount of the (original) body. (Though HTML (read: MIME structures) can complicate this.) - Or are you referring to something else? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From mike at mtcc.com Wed Nov 29 22:46:27 2017 From: mike at mtcc.com (Michael Thomas) Date: Wed, 29 Nov 2017 14:46:27 -0800 Subject: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: References: <20171129211118.22256.qmail@ary.lan> <3d3eff60-71ad-8866-37ed-8564429cb010@mtcc.com> Message-ID: <31c0bf91-f097-69e4-c8d2-7b649e460525@mtcc.com> On 11/29/2017 02:40 PM, Grant Taylor via NANOG wrote: > On 11/29/2017 03:24 PM, Michael Thomas wrote: >> Message footers and subject lines can be dealt with. That's already >> been proven within the current DKIM spec. > > Please humor my ignorance and explain how a subject line (which is > (over)signed) can be dealt with in the current DKIM spec? > > I get how footers can be dealt with, read appended. At least as long > as DKIM only signs a given amount of the (original) body. (Though HTML > (read: MIME structures) can complicate this.) - Or are you referring > to something else? > > > You know what the original header was via the signature. You can take the delta of the current subject line and remove any additions and validate the signature. Whether you're happy with the additions is a different concern, If I were constructing a spam filter out of it, I'd give a lot of prejudice to anything added, but that's outside of what you can do within the bounds of the spec. Mike From johnl at iecc.com Wed Nov 29 22:50:16 2017 From: johnl at iecc.com (John Levine) Date: 29 Nov 2017 22:50:16 -0000 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <3677d101-3874-b8e4-87b3-37e4dd870325@tnetconsulting.net> Message-ID: <20171129225016.22679.qmail@ary.lan> In article <3677d101-3874-b8e4-87b3-37e4dd870325 at tnetconsulting.net> you write: >> Normal lists put their own bounce address in the >> envelope so they can handle the bounces, so their own SPF applies. > >Yep. V.E.R.P. is a very powerful thing. (B.A.T.V. is an interesting >alternative, but I never messed with it.) VERP helps identify the bouncing party, but list bounce handling works fine without it. What matters is that it's the list's address in the envelope, not the message author. BATV works OK (I should know, I invented it) but it has its false positives. >I'm saying that I've heard arguments over the last 15 years from people >that (FC)rDNS and SPF (independently) are things that will break some >portion of email. Broken rDNS is just broken, since there's approximately no reason ever to send from a host that doesn't know its own name. Broken SPF may or may not be an issue since there are lots of legit ways to send mail that SPF can't describe. R's, John >P.S. I'm strongly of the opinion that if a MLM alters the message in >ANY capacity, that it is actually generating a new message. Thus the >MLM is the new author. It's just using content strongly based on emails >that came into it. - But that's a different discussion that lasted >days on the mailman mailing list. It's an interesting theological argument but it makes little practical difference. From johnl at iecc.com Wed Nov 29 22:52:45 2017 From: johnl at iecc.com (John Levine) Date: 29 Nov 2017 22:52:45 -0000 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <11e9c18dac053c4bb91b95a4993c116f@mail.dessus.com> Message-ID: <20171129225245.22715.qmail@ary.lan> In article <11e9c18dac053c4bb91b95a4993c116f at mail.dessus.com> you write: > >Not old enough to have had an Executive Secretary processing your incoming snail-mail before it gets to you? Probably about the same age as you, but I hope that after 50 years of e-mail we have figured out that the parallels with paper mail are imperfect. The e-mail envelope is a metaphor, you know. R's, John From gtaylor at tnetconsulting.net Wed Nov 29 23:00:26 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Nov 2017 16:00:26 -0700 Subject: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <31c0bf91-f097-69e4-c8d2-7b649e460525@mtcc.com> References: <20171129211118.22256.qmail@ary.lan> <3d3eff60-71ad-8866-37ed-8564429cb010@mtcc.com> <31c0bf91-f097-69e4-c8d2-7b649e460525@mtcc.com> Message-ID: <97368a94-d79a-e95e-a4ff-e791693b1c7f@tnetconsulting.net> On 11/29/2017 03:46 PM, Michael Thomas wrote: > You know what the original header was via the signature. You can take > the delta of the current subject line and > remove any additions and validate the signature. Whether you're happy > with the additions is a different concern, Are you referring to the optional z DKIM-Signature tag? Or are you referring to brute forcing what the subject was in order to derive the delta of the current subject? This would be compounded by any number of other changes to (over)singed headers / body portion. > If I were constructing a spam filter out of it, I'd give a lot of > prejudice to anything added, but that's outside of > what you can do within the bounds of the spec. *If* the z tag was included in the DKIM-Signature header, I can see how this would work and I agree with your distrust of said additions / alterations. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From mike at mtcc.com Wed Nov 29 23:03:17 2017 From: mike at mtcc.com (Michael Thomas) Date: Wed, 29 Nov 2017 15:03:17 -0800 Subject: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <97368a94-d79a-e95e-a4ff-e791693b1c7f@tnetconsulting.net> References: <20171129211118.22256.qmail@ary.lan> <3d3eff60-71ad-8866-37ed-8564429cb010@mtcc.com> <31c0bf91-f097-69e4-c8d2-7b649e460525@mtcc.com> <97368a94-d79a-e95e-a4ff-e791693b1c7f@tnetconsulting.net> Message-ID: <5debbe49-bcfd-1715-ea1f-1b93d7321007@mtcc.com> On 11/29/2017 03:00 PM, Grant Taylor via NANOG wrote: > On 11/29/2017 03:46 PM, Michael Thomas wrote: >> You know what the original header was via the signature. You can take >> the delta of the current subject line and remove any additions and >> validate the signature. Whether you're happy with the additions is a >> different concern, > > Are you referring to the optional z DKIM-Signature tag? > > Or are you referring to brute forcing what the subject was in order to > derive the delta of the current subject? This would be compounded by > any number of other changes to (over)singed headers / body portion. > >> If I were constructing a spam filter out of it, I'd give a lot of >> prejudice to anything added, but that's outside of >> what you can do within the bounds of the spec. > > *If* the z tag was included in the DKIM-Signature header, I can see > how this would work and I agree with your distrust of said additions / > alterations. > Yes, with the z= Mike From brock at bmwl.co Thu Nov 30 00:23:30 2017 From: brock at bmwl.co (Brock Tice) Date: Wed, 29 Nov 2017 17:23:30 -0700 Subject: Subnet being blocked by Level3 due to prior owner's misuse Message-ID: <9d844f51-e300-be48-e791-9c8fa80c663f@bmwl.co> We have a subnet that used to belong to someone else. One of our business customers that was recently moved to that subnet is being blocked from accessing one of their supplier's web site that's hosted by Level3. Our attempts to work through the supplier to resolve the issue have not worked as they are not aware of what's happening at that level. Our other attempts to resolve this have not worked. Would someone from Level3 be able to help resolve this off-list, or does someone have the appropriate contact information? Thanks, --Brock From mike at mtcc.com Wed Nov 29 21:46:05 2017 From: mike at mtcc.com (Michael Thomas) Date: Wed, 29 Nov 2017 13:46:05 -0800 Subject: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <20171129211118.22256.qmail@ary.lan> References: <20171129211118.22256.qmail@ary.lan> Message-ID: <44d4e8e6-58a3-ef39-dc55-950888ea6c76@mtcc.com> On 11/29/2017 01:11 PM, John Levine wrote: > > PPS: Please spare us pontification about why ARC can't possibly work > unless you're prepared to cite section numbers in the ARC spec > supporting your argument. Apparently the levine unit is hearing things again because nobody -- least of all me -- has said anything about arc. Mike From valdis.kletnieks at vt.edu Thu Nov 30 00:41:56 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Wed, 29 Nov 2017 19:41:56 -0500 Subject: lists and DMARC and ARC, was Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <44d4e8e6-58a3-ef39-dc55-950888ea6c76@mtcc.com> References: <20171129211118.22256.qmail@ary.lan> <44d4e8e6-58a3-ef39-dc55-950888ea6c76@mtcc.com> Message-ID: <149000.1512002516@turing-police.cc.vt.edu> On Wed, 29 Nov 2017 13:46:05 -0800, Michael Thomas said: > Apparently the levine unit is hearing things again because nobody -- > least of all me -- has > said anything about arc. I believe it was a pre-emptive statement. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From bill at herrin.us Thu Nov 30 02:16:43 2017 From: bill at herrin.us (William Herrin) Date: Wed, 29 Nov 2017 21:16:43 -0500 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <20171129225016.22679.qmail@ary.lan> References: <3677d101-3874-b8e4-87b3-37e4dd870325@tnetconsulting.net> <20171129225016.22679.qmail@ary.lan> Message-ID: On Wed, Nov 29, 2017 at 5:50 PM, John Levine wrote: > > In article <3677d101-3874-b8e4-87b3-37e4dd870325 at tnetconsulting.net> you write: > >> Normal lists put their own bounce address in the > >> envelope so they can handle the bounces, so their own SPF applies. > > > >Yep. V.E.R.P. is a very powerful thing. (B.A.T.V. is an interesting > >alternative, but I never messed with it.) > > VERP helps identify the bouncing party, but list bounce handling works > fine without it. Not so much, no. There's no "must" standard for the format of bounce message, deferred bounces are still a thing and mail gets auto-forwarded to addresses which bounce (that is, bounce from an address different than the one you sent to). Without something like VERP to encode the original recipient in the return address, the percentage of bounces your list successfully processes each month will slowly but steadily decline. Broken rDNS is just broken, since there's approximately no reason ever > to send from a host that doesn't know its own name. Broken SPF may or > may not be an issue since there are lots of legit ways to send mail > that SPF can't describe. > +1 >P.S. I'm strongly of the opinion that if a MLM alters the message in > >ANY capacity, that it is actually generating a new message. Thus the > >MLM is the new author. It's just using content strongly based on emails > >that came into it. - But that's a different discussion that lasted > >days on the mailman mailing list. > > It's an interesting theological argument but it makes little practical > difference. > I could not disagree with you more. It's relatively easy to design and implement a system which allows the originating MUA and MTA to offer proof of authority to act on behalf of a given email address. Though possible, systems which would allow intermediate mail handlers to generate proof of authority to handle a message alleged to originate from a particular address don't especially exist and would be much more complex. Systemic and computational complexity is a very practical difference between the two situations. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From gtaylor at tnetconsulting.net Thu Nov 30 03:23:49 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 29 Nov 2017 20:23:49 -0700 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: References: <3677d101-3874-b8e4-87b3-37e4dd870325@tnetconsulting.net> <20171129225016.22679.qmail@ary.lan> Message-ID: On 11/29/2017 07:16 PM, William Herrin wrote: > There's no "must" standard for the format of bounce message, deferred > bounces are still a thing and mail gets auto-forwarded to addresses which > bounce (that is, bounce from an address different than the one you sent to). Agreed. I wish that more software would use the well defined Delivery Status Notification and Message Disposition Notifications. (RFC 6553) > Without something like VERP to encode the original recipient in the return > address, the percentage of bounces your list successfully processes each > month will slowly but steadily decline. I think it's entirely possible to teach MLMs about the most common forms of bounces (DSNs). But it will quickly get into a game of diminishing returns. Especially if the bounce (because it's not going to be the well known DNS format) goes out of it's way to hide something. In that case, the only thing that you could count on (that I'm aware of) is something like VERP. I wonder if SMTP's ORCPT parameter to the RCPT command would cross forwarders. (I'm not holding my breath.) Aside: I'm quite interested in discussing the the following reply, but I suspect it's going to be a bit of a rabbit whole. Is such a discussion appropriate for NANOG? (I'll assume that a lack of reply indicates that the discussion is better had elsewhere.) > I could not disagree with you more. It's relatively easy to design and > implement a system which allows the originating MUA and MTA to offer proof > of authority to act on behalf of a given email address. Though possible, > systems which would allow intermediate mail handlers to generate proof of > authority to handle a message alleged to originate from a particular > address don't especially exist and would be much more complex. Systemic and > computational complexity is a very practical difference between the two > situations. I feel like SPF & DKIM (at least partially) address the former scenario. - I think that SPF and DKIM-ATPS can (at least partially) address the latter. With the latter assuming some sort of established business relationship between the originating and intermediary parties. -- Grant. . . . unix || die From ramy.ihashish at gmail.com Thu Nov 30 04:34:19 2017 From: ramy.ihashish at gmail.com (Ramy Hashish) Date: Thu, 30 Nov 2017 06:34:19 +0200 Subject: WiFi - login page redirection not working Message-ID: Good day all, A lot have been said on this topic, however I want to make sure I am not missing something. Two points with this problem: 1)Is there a "non client" solution to the problem of the WiFi login notification not showing up on the clients after connecting to the WiFi network? Second, anything to be done from the AP to show the landing page even if the page requested is HTTPs? Thanks, Ramy From mysidia at gmail.com Thu Nov 30 07:02:54 2017 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 30 Nov 2017 01:02:54 -0600 Subject: WiFi - login page redirection not working In-Reply-To: References: Message-ID: On Wed, Nov 29, 2017 at 10:34 PM, Ramy Hashish wrote: > Two points with this problem: 1)Is there a "non client" solution to the > problem of the WiFi login notification not showing up on the clients after > connecting to the WiFi network? > A Captive portal embedding WispR XML data for connections from browsers/OSes that request a test page upon network access. https://stackoverflow.com/questions/3615147/how-to-create-wifi-popup-login-page However if WPA2 authentication is not method used for access, then network traffic is vulnerable and not secured. AP solutions that are non-standard being a "Non client" solution and using "Open Wireless" mode SSIDs are likely so deficient in security as to be an unreasonable risk for users to actually connect to. > Second, anything to be done from the AP to show the landing page even if > the page requested is HTTPs? > If TLS would somehow allow you to redirect or create a HTTPS connection from a domain name that is not yours, then this could obviously be exploited for attacks..... -- -JH From benoit.panizzon at imp.ch Thu Nov 30 08:53:26 2017 From: benoit.panizzon at imp.ch (Benoit Panizzon) Date: Thu, 30 Nov 2017 09:53:26 +0100 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: References: Message-ID: <20171130095326.4be93450@go.imp.ch> Hi > For those who operate public facing SMTPd that receive a large volume > of incoming traffic, and accordingly, a lot of spam... > > How much weight do you put on an incoming message, in terms of adding > additional score towards a possible value of spam, for total absence > of DKIM signature? No DKIM = not scored. DKIM is not widely used and DKIM does break a lot of mailinglists and sometimes also SRS compliant forwarding. We do score some points if a DKIM header with invalid signature is present. -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ From bjorn at mork.no Thu Nov 30 09:22:40 2017 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 30 Nov 2017 10:22:40 +0100 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <20171129225016.22679.qmail@ary.lan> (John Levine's message of "29 Nov 2017 22:50:16 -0000") References: <20171129225016.22679.qmail@ary.lan> Message-ID: <871skg9l3z.fsf@miraculix.mork.no> "John Levine" writes: > Broken rDNS is just broken, since there's approximately no reason ever > to send from a host that doesn't know its own name. rDNS is not a host attribute, and will therefore tell you exactly nothing about the host. Bjørn From josh at imaginenetworksllc.com Thu Nov 30 16:20:25 2017 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 30 Nov 2017 11:20:25 -0500 Subject: WiFi - login page redirection not working In-Reply-To: References: Message-ID: >If TLS would somehow allow you to redirect... No but it would be nice to have a solution that redirects the user instead of "this page can't load" creating confusion. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Nov 30, 2017 at 2:02 AM, Jimmy Hess wrote: > On Wed, Nov 29, 2017 at 10:34 PM, Ramy Hashish > wrote: > > > > Two points with this problem: 1)Is there a "non client" solution to the > > problem of the WiFi login notification not showing up on the clients > after > > connecting to the WiFi network? > > > > A Captive portal embedding WispR XML data > for connections from browsers/OSes that request a test page upon network > access. > https://stackoverflow.com/questions/3615147/how-to- > create-wifi-popup-login-page > > However if WPA2 authentication is not method used for access, then network > traffic is > vulnerable and not secured. > > AP solutions that are non-standard being a "Non client" solution and using > "Open Wireless" mode SSIDs are likely so deficient in security as to be > an unreasonable risk for users to actually connect to. > > > > Second, anything to be done from the AP to show the landing page even if > > the page requested is HTTPs? > > > > If TLS would somehow allow you to redirect or create a HTTPS connection > from > a domain name that is not yours, then this could obviously be exploited for > attacks..... > > -- > -JH > From steve at blighty.com Thu Nov 30 17:03:24 2017 From: steve at blighty.com (Steve Atkins) Date: Thu, 30 Nov 2017 09:03:24 -0800 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <871skg9l3z.fsf@miraculix.mork.no> References: <20171129225016.22679.qmail@ary.lan> <871skg9l3z.fsf@miraculix.mork.no> Message-ID: <148663DD-F150-4881-B960-0F46201ADD2C@blighty.com> > On Nov 30, 2017, at 1:22 AM, Bjørn Mork wrote: > > "John Levine" writes: > >> Broken rDNS is just broken, since there's approximately no reason ever >> to send from a host that doesn't know its own name. > > rDNS is not a host attribute, and will therefore tell you exactly > nothing about the host. It tells you something about the competence of the operator and whether the host is intended by the owners to send email. Or, for a more empirical way to look at it, there's reasonable correlation between having missing, generic or incorrect reverse DNS and the host being a source of unwanted or malicious email. Cheers, Steve From bjorn at mork.no Thu Nov 30 17:55:18 2017 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 30 Nov 2017 18:55:18 +0100 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <148663DD-F150-4881-B960-0F46201ADD2C@blighty.com> (Steve Atkins's message of "Thu, 30 Nov 2017 09:03:24 -0800") References: <20171129225016.22679.qmail@ary.lan> <871skg9l3z.fsf@miraculix.mork.no> <148663DD-F150-4881-B960-0F46201ADD2C@blighty.com> Message-ID: <87po7z7it5.fsf@miraculix.mork.no> Steve Atkins writes: >> On Nov 30, 2017, at 1:22 AM, Bjørn Mork wrote: >> >> "John Levine" writes: >> >>> Broken rDNS is just broken, since there's approximately no reason ever >>> to send from a host that doesn't know its own name. >> >> rDNS is not a host attribute, and will therefore tell you exactly >> nothing about the host. > > It tells you something about the competence of the operator and > whether the host is intended by the owners to send email. No. It only tells you something about the administrative split between IP address management and host management. There is no way my laptop is going to be able to update the rDNS for all addresses it will use in different networks. This does in no way affect its MTA configuration. > Or, for a more empirical way to look at it, there's reasonable correlation > between having missing, generic or incorrect reverse DNS and the host > being a source of unwanted or malicious email. Really? Where did you get those numbers? This is a myth. Spam sources are average Internet hosts. The split between working and non-working rDNS is mostly between IPv4 and IPv6, not between ham and spam. And if there is some correlation there, then I'd say that an IPv4 host is more likely to be a spam source than a dual stack or IPv6 only host. Bjørn From owen at delong.com Thu Nov 30 17:57:56 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 30 Nov 2017 09:57:56 -0800 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <148663DD-F150-4881-B960-0F46201ADD2C@blighty.com> References: <20171129225016.22679.qmail@ary.lan> <871skg9l3z.fsf@miraculix.mork.no> <148663DD-F150-4881-B960-0F46201ADD2C@blighty.com> Message-ID: > On Nov 30, 2017, at 09:03 , Steve Atkins wrote: > > >> On Nov 30, 2017, at 1:22 AM, Bjørn Mork wrote: >> >> "John Levine" writes: >> >>> Broken rDNS is just broken, since there's approximately no reason ever >>> to send from a host that doesn't know its own name. >> >> rDNS is not a host attribute, and will therefore tell you exactly >> nothing about the host. > > It tells you something about the competence of the operator and > whether the host is intended by the owners to send email. > > Or, for a more empirical way to look at it, there's reasonable correlation > between having missing, generic or incorrect reverse DNS and the host > being a source of unwanted or malicious email. I’m not so sure about that. Lots of hosts that send unwanted/malicious email have missing, generic, or obviously incorrect rDNS. Lots of hosts that send unwanted/malicious email have valid non-generic possibly correct rDNS. I don’t accept email from the former, but I still get plenty of SPAM from the latter. Unfortunately, until we get widespread deployment of something better than IP reputation based systems, SPAM continues to be a low-cost to the sender side with a high burden on the delivery side and therefore remains a very profitable industry. DKIM certainly could help (though I’m not convinced it’s a 100% effective solution, nor am I particularly convinced we’ve found any particularly effective solutions as yet. Perhaps this is simply the inherent cost of maintaining an open communications infrastructure with a low barrier to entry and the potential for anonymous communications which I believe has value to society and should be preserved. Perhaps someone smarter than I will some day develop a better solution. Owen From owen at delong.com Thu Nov 30 18:01:32 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 30 Nov 2017 10:01:32 -0800 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <87po7z7it5.fsf@miraculix.mork.no> References: <20171129225016.22679.qmail@ary.lan> <871skg9l3z.fsf@miraculix.mork.no> <148663DD-F150-4881-B960-0F46201ADD2C@blighty.com> <87po7z7it5.fsf@miraculix.mork.no> Message-ID: > On Nov 30, 2017, at 09:55 , Bjørn Mork wrote: > > Steve Atkins writes: > >>> On Nov 30, 2017, at 1:22 AM, Bjørn Mork wrote: >>> >>> "John Levine" writes: >>> >>>> Broken rDNS is just broken, since there's approximately no reason ever >>>> to send from a host that doesn't know its own name. >>> >>> rDNS is not a host attribute, and will therefore tell you exactly >>> nothing about the host. >> >> It tells you something about the competence of the operator and >> whether the host is intended by the owners to send email. > > No. It only tells you something about the administrative split between > IP address management and host management. > > There is no way my laptop is going to be able to update the rDNS for all > addresses it will use in different networks. This does in no way affect > its MTA configuration. Perhaps a better way to word it is “It tells us something about whether the machine is likely to possess properties which make it generally undesirable for us to accept messages from it directly.” I, for one, have no interest in accepting messages into my mail server directly from your laptop, even if they are legitimately from you to me. I’m perfectly happy to insist that you go via an MTA hosted in a more permanent location on your side first in order to avoid receiving messages directly from the much larger quantity of incompetently administered mailservers, many of which I suspect are not intended by their owners (distinct from their pwn3rs) to be mail servers at all. >> Or, for a more empirical way to look at it, there's reasonable correlation >> between having missing, generic or incorrect reverse DNS and the host >> being a source of unwanted or malicious email. > > Really? Where did you get those numbers? This is a myth. Spam sources > are average Internet hosts. The split between working and non-working > rDNS is mostly between IPv4 and IPv6, not between ham and spam. And if > there is some correlation there, then I'd say that an IPv4 host is more > likely to be a spam source than a dual stack or IPv6 only host. Really? Most of my hosts have working rDNS for both v4 and v6. As to an IPv4 host being a more likely source of SPAM, I’m not convinced about that, either given the amount of SPAM that hits my mailserver via IPv6. Owen From owen at delong.com Thu Nov 30 18:08:44 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 30 Nov 2017 10:08:44 -0800 Subject: WiFi - login page redirection not working In-Reply-To: References: Message-ID: <997F6AD0-BAE9-45C8-BA55-98AD9E560640@delong.com> > On Nov 30, 2017, at 08:20 , Josh Luthman wrote: > >> If TLS would somehow allow you to redirect... > > No but it would be nice to have a solution that redirects the user instead > of "this page can't load" creating confusion. A well-known non-SSL (non-HSTS) URL that users could use for this purpose would serve the same purpose without producing the security problems mentioned. Owen > > > Josh Luthman > Office: 937-552-2340 > Direct: 937-552-2343 > 1100 Wayne St > Suite 1337 > Troy, OH 45373 > > On Thu, Nov 30, 2017 at 2:02 AM, Jimmy Hess wrote: > >> On Wed, Nov 29, 2017 at 10:34 PM, Ramy Hashish >> wrote: >> >> >>> Two points with this problem: 1)Is there a "non client" solution to the >>> problem of the WiFi login notification not showing up on the clients >> after >>> connecting to the WiFi network? >>> >> >> A Captive portal embedding WispR XML data >> for connections from browsers/OSes that request a test page upon network >> access. >> https://stackoverflow.com/questions/3615147/how-to- >> create-wifi-popup-login-page >> >> However if WPA2 authentication is not method used for access, then network >> traffic is >> vulnerable and not secured. >> >> AP solutions that are non-standard being a "Non client" solution and using >> "Open Wireless" mode SSIDs are likely so deficient in security as to be >> an unreasonable risk for users to actually connect to. >> >> >>> Second, anything to be done from the AP to show the landing page even if >>> the page requested is HTTPs? >>> >> >> If TLS would somehow allow you to redirect or create a HTTPS connection >> from >> a domain name that is not yours, then this could obviously be exploited for >> attacks..... >> >> -- >> -JH >> From bill at herrin.us Thu Nov 30 18:15:41 2017 From: bill at herrin.us (William Herrin) Date: Thu, 30 Nov 2017 13:15:41 -0500 Subject: WiFi - login page redirection not working In-Reply-To: <997F6AD0-BAE9-45C8-BA55-98AD9E560640@delong.com> References: <997F6AD0-BAE9-45C8-BA55-98AD9E560640@delong.com> Message-ID: On Thu, Nov 30, 2017 at 1:08 PM, Owen DeLong wrote > > On Nov 30, 2017, at 08:20 , Josh Luthman > wrote: > > > >> If TLS would somehow allow you to redirect... > > > > No but it would be nice to have a solution that redirects the user > instead > > of "this page can't load" creating confusion. > > A well-known non-SSL (non-HSTS) URL that users could use for this purpose > would > serve the same purpose without producing the security problems mentioned. A well known SSL certificate that if it appears during negotiation means the application should "check for captive portal." -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: From Romeo.Czumbil at tierpoint.com Thu Nov 30 18:36:47 2017 From: Romeo.Czumbil at tierpoint.com (Romeo Czumbil) Date: Thu, 30 Nov 2017 18:36:47 +0000 Subject: Arista Layer3 Message-ID: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> So I've been using Arista as layer2 for quite some time, and I'm pretty happy with them. Kicking the idea around to turn on some Layer3 features but I've been hearing some negative feedback. The people that I did hear negative feedback don't use Arista themselves. (they just heard....) So do we have any Arista L3 people out here that can share some negatives or positives? Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP Maybe 20k routes (no full internet routes) 7050 Series 7280 Series -Romeo From gtaylor at tnetconsulting.net Thu Nov 30 18:44:27 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 30 Nov 2017 11:44:27 -0700 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <20171130095326.4be93450@go.imp.ch> References: <20171130095326.4be93450@go.imp.ch> Message-ID: <8e34d60b-aee0-e9c5-a9ac-0ab1c4deebde@tnetconsulting.net> On 11/30/2017 01:53 AM, Benoit Panizzon wrote: > DKIM is not widely used and DKIM does break a lot of mailinglists and > sometimes also SRS compliant forwarding. How does DKIM break SRS compliant forwarding? (Assuming that only the message envelope is modified.) Or are you referring to DMARC's interactions there in? -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From tyler at tgconrad.com Thu Nov 30 18:45:09 2017 From: tyler at tgconrad.com (Tyler Conrad) Date: Thu, 30 Nov 2017 10:45:09 -0800 Subject: Arista Layer3 In-Reply-To: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> Message-ID: For Enterprise/DC, it works great. For service provider, they're not 100% yet. The main issue is going to be around VRFs, as there's no interaction between them (at least in the code version I'm on, that may have changed recently or be changing soon). They'll work great as a P-Router, but if you need a PE with route leaking I'd look at another vendor. I use a couple pairs of 7280SRs as edge routers/border leaves. Multiple full table feeds without any issue. On Thu, Nov 30, 2017 at 10:36 AM, Romeo Czumbil wrote: > So I've been using Arista as layer2 for quite some time, and I'm pretty > happy with them. > Kicking the idea around to turn on some Layer3 features but I've been > hearing some negative feedback. > The people that I did hear negative feedback don't use Arista themselves. > (they just heard....) > > So do we have any Arista L3 people out here that can share some negatives > or positives? > > Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP > Maybe 20k routes (no full internet routes) > 7050 Series > 7280 Series > > -Romeo > From johnl at iecc.com Thu Nov 30 18:28:01 2017 From: johnl at iecc.com (John Levine) Date: 30 Nov 2017 18:28:01 -0000 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: Message-ID: <20171130182801.24688.qmail@ary.lan> In article you write: >> Or, for a more empirical way to look at it, there's reasonable correlation >> between having missing, generic or incorrect reverse DNS and the host >> being a source of unwanted or malicious email. > >I’m not so sure about that. It's a one way correlation. If the rDNS is busted, you can be pretty sure you don't want the mail. If the rDNS is OK, you need more clues. >Unfortunately, until we get widespread deployment of something better than IP reputation based >systems, ... You might take a look at how current spam filters work. Spamassassin is as good an example as any. It does dynamic weigthted scoring of a lot of factors, of which IP reputation is only one. I find that I can use conservatively run IP blacklists as a cheap prepass to avoid sending the mail to spamassassin at all, but there's a lot more than IP by the time the mail does or does not get delivered. DKIM is useful if have opinions about the reputations of the signing domains, not purely by whether there's a signature. >Perhaps this is simply the inherent cost of maintaining an open communications infrastructure with >a low barrier to entry and the potential for anonymous communications which I believe has value >to society and should be preserved. Perhaps someone smarter than I will some day develop a better >solution. It seems to be an axiom that any community large enough to be interesting is large enough to contain people who are malicious, so even requiring that people be identified won't help. R's, John From johnl at iecc.com Thu Nov 30 18:30:41 2017 From: johnl at iecc.com (John Levine) Date: 30 Nov 2017 18:30:41 -0000 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: Message-ID: <20171130183041.24718.qmail@ary.lan> In article you write: >> Without something like VERP to encode the original recipient in the return >> address, the percentage of bounces your list successfully processes each >> month will slowly but steadily decline. > >I think it's entirely possible to teach MLMs about the most common forms >of bounces (DSNs). But it will quickly get into a game of diminishing >returns. Especially if the bounce (because it's not going to be the >well known DNS format) goes out of it's way to hide something. In that >case, the only thing that you could count on (that I'm aware of) is >something like VERP. If you look at the bounce handling in packages like sympa and mailman, they have lots of heuristics to try to figure out what bounces mean. They work OK but I agree they are far from perfect. > - I think that SPF and DKIM-ATPS can (at least partially) address the >latter. With the latter assuming some sort of established business >relationship between the originating and intermediary parties. It's a rathole, it doesn't scale, and it is not a bug that you can send mail to people who you don't already know. If identities were a magic bullet, we'd all be signing with S/MIME. R's, John From owen at delong.com Thu Nov 30 19:07:09 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 30 Nov 2017 11:07:09 -0800 Subject: WiFi - login page redirection not working In-Reply-To: References: <997F6AD0-BAE9-45C8-BA55-98AD9E560640@delong.com> Message-ID: <52353203-3C4C-42C9-97E7-AC13A8ABE146@delong.com> > On Nov 30, 2017, at 10:15 , William Herrin wrote: > > On Thu, Nov 30, 2017 at 1:08 PM, Owen DeLong > wrote > > On Nov 30, 2017, at 08:20 , Josh Luthman > wrote: > > > >> If TLS would somehow allow you to redirect... > > > > No but it would be nice to have a solution that redirects the user instead > > of "this page can't load" creating confusion. > > A well-known non-SSL (non-HSTS) URL that users could use for this purpose would > serve the same purpose without producing the security problems mentioned. > > A well known SSL certificate that if it appears during negotiation means the application should "check for captive portal.” This would require modification of all clients and I see no advantage to it vs. a well known locally resolvable URL for captive portals that “MUST NOT” indicate HSTS. Please explain. Owen From owen at delong.com Thu Nov 30 19:16:09 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 30 Nov 2017 11:16:09 -0800 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <20171130182801.24688.qmail@ary.lan> References: <20171130182801.24688.qmail@ary.lan> Message-ID: <612F06E8-7FC2-4A83-B95E-28A1E41F6115@delong.com> > On Nov 30, 2017, at 10:28 , John Levine wrote: > > In article you write: >>> Or, for a more empirical way to look at it, there's reasonable correlation >>> between having missing, generic or incorrect reverse DNS and the host >>> being a source of unwanted or malicious email. >> >> I’m not so sure about that. > > It's a one way correlation. If the rDNS is busted, you can be pretty > sure you don't want the mail. If the rDNS is OK, you need more clues. Pretty sure, but far from certain. Even this one-way correlation is rather tenuous. It’s mostly harmless because everyone knows that mail servers are filtering on this basis and legitimate senders therefore force themselves into workarounds. In an ideal world, I wouldn’t mind accepting email from Bj0rn’s laptop directly, but today, the price of doing so in SPAM is just too high, so I don’t. Fortunately for everyone’s sake, Bj0rn, while he may not like it, seems to find a way to send his email via some mechanism that allows me to receive it from a host that has working rDNS. >> Unfortunately, until we get widespread deployment of something better than IP reputation based >> systems, ... > > You might take a look at how current spam filters work. Spamassassin > is as good an example as any. It does dynamic weigthted scoring of a > lot of factors, of which IP reputation is only one. I find that I can > use conservatively run IP blacklists as a cheap prepass to avoid > sending the mail to spamassassin at all, but there's a lot more than > IP by the time the mail does or does not get delivered. DKIM is > useful if have opinions about the reputations of the signing domains, > not purely by whether there's a signature. Spamassassin is as good an example as any and while it can be effective if you’ve got the cycles to keep it constantly updated and fed with new information and…, it’s a rather large PITA for a small site with an admin that needs to count on most things running on autopilot most of the time in order to survive. So, while it might be a higher-quality solution, I’d argue that it’s not completely “better” in that any autopilotable configuration of it involves a high degree of false negatives or an unacceptable level of false positives. >> Perhaps this is simply the inherent cost of maintaining an open communications infrastructure with >> a low barrier to entry and the potential for anonymous communications which I believe has value >> to society and should be preserved. Perhaps someone smarter than I will some day develop a better >> solution. > > It seems to be an axiom that any community large enough to be > interesting is large enough to contain people who are malicious, so > even requiring that people be identified won't help. People who want to be malicious are usually less willing to do so if they know that they will be identified, so actually, it does help. i.e. rarely to bank robbers sign their names to the robbery note. Owen From math at sizone.org Thu Nov 30 19:17:50 2017 From: math at sizone.org (Ken Chase) Date: Thu, 30 Nov 2017 14:17:50 -0500 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> Message-ID: <20171130191750.GB32439@sizone.org> Back to this discussion! :) Arista as a viable full-table PE router. Was hoping for better experience reports since last mention. To make the Q bit more general, are there any PE routers yet that can handle 3-8 full feeds and use an amp and 1U or so instead of 5 and 4U? Or we're ito whitebox/ open routers still for that (bird/openbgp?) or microtiks? /kc On Thu, Nov 30, 2017 at 10:45:09AM -0800, Tyler Conrad said: >For Enterprise/DC, it works great. For service provider, they're not 100% >yet. The main issue is going to be around VRFs, as there's no interaction >between them (at least in the code version I'm on, that may have changed >recently or be changing soon). They'll work great as a P-Router, but if you >need a PE with route leaking I'd look at another vendor. > >I use a couple pairs of 7280SRs as edge routers/border leaves. Multiple >full table feeds without any issue. > >On Thu, Nov 30, 2017 at 10:36 AM, Romeo Czumbil > wrote: > >> So I've been using Arista as layer2 for quite some time, and I'm pretty >> happy with them. >> Kicking the idea around to turn on some Layer3 features but I've been >> hearing some negative feedback. >> The people that I did hear negative feedback don't use Arista themselves. >> (they just heard....) >> >> So do we have any Arista L3 people out here that can share some negatives >> or positives? >> >> Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP >> Maybe 20k routes (no full internet routes) >> 7050 Series >> 7280 Series >> >> -Romeo >> -- Ken Chase - math at sizone.org Guelph Canada From jared at puck.nether.net Thu Nov 30 19:32:14 2017 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 30 Nov 2017 14:32:14 -0500 Subject: Arista Layer3 In-Reply-To: <20171130191750.GB32439@sizone.org> References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> Message-ID: > On Nov 30, 2017, at 2:17 PM, Ken Chase wrote: > > Back to this discussion! :) Arista as a viable full-table PE router. Was hoping > for better experience reports since last mention. > > To make the Q bit more general, are there any PE routers yet that can handle 3-8 > full feeds and use an amp and 1U or so instead of 5 and 4U? Or we're ito whitebox/ > open routers still for that (bird/openbgp?) or microtiks? The 7280 is likely what you’re looking at. Lots of folks also use MikroTik as well if the traffic is in the 1G range or so. I for one use Arista for Layer3 for FTTH purposes as it gives me good software/hardware support for my features. - Jared From hugge at nordu.net Thu Nov 30 19:38:48 2017 From: hugge at nordu.net (=?UTF-8?Q?Fredrik_Korsb=c3=a4ck?=) Date: Thu, 30 Nov 2017 20:38:48 +0100 Subject: Arista Layer3 In-Reply-To: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> Message-ID: <536682f5-079d-1d3b-054b-9a0cd769c5fe@nordu.net> On 2017-11-30 19:36, Romeo Czumbil wrote: > So I've been using Arista as layer2 for quite some time, and I'm pretty happy with them. > Kicking the idea around to turn on some Layer3 features but I've been hearing some negative feedback. > The people that I did hear negative feedback don't use Arista themselves. (they just heard....) > > So do we have any Arista L3 people out here that can share some negatives or positives? > > Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP > Maybe 20k routes (no full internet routes) > 7050 Series > 7280 Series > > -Romeo > I have a whole bunch of 7280SR in production, acting as peering-aggregators to easy be able to scale out PNIs to the CDN/Clouds (where you sometimes needs to add 10G of capacity per PoP per month) They work just fine. Simple PE-functions, a few hundred BGP-peers in each, full tables, as-path filtering (150k lines of config), route-maps and sub-route maps. It is certainly not as flexible and easy to work with as for example a MX-router. But on the other hand you get 1Tbit worth of ports for the same price as a 16x10G MX-card. L3VPN, RSVP-TE which could be major things you need is coming to EOS "soon", february i think. The boxes that is coming out here in Q1 (some even out) with Jericho+ and Jericho2 chipsets should be even better with even more tables that should suffice for quite some time, the 1mil limit on 7280SR can be borderline especially when you mix in L3VPN whenever thats coming. Huawei (ce6870) and Cisco (ncs5500) is also selling the same boxes and rumours on the streets are that Juniper will also release a jericho-based PE-box. Also Juniper has picked up alot of slack recently with the release of MX204, which seems for whats its worth be a really good contender in the "small but modern router" market which has been grossly overlooked by many vendors for quite some time. Not sure where cisco really is with the 9901, which atleast looked really good on the CLUS presentations. -- hugge -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: OpenPGP digital signature URL: From math at sizone.org Thu Nov 30 19:41:03 2017 From: math at sizone.org (Ken Chase) Date: Thu, 30 Nov 2017 14:41:03 -0500 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> Message-ID: <20171130194102.GE32439@sizone.org> Thx. Rather steer clear of microtik for now however. Guess I shoulda mentioned a baseline 10G capability at least on 4 sfp+ ports (I know there's some 2port Microtiks too). Everyone's got gig-to-the-home now, I can't see how anyone plans 1G PE builds anymore. They'll be obsolete by the time they're plugged in (10G for any medium sized op is almost obsolete already.) /kc On Thu, Nov 30, 2017 at 02:32:14PM -0500, Jared Mauch said: > > >> On Nov 30, 2017, at 2:17 PM, Ken Chase wrote: >> >> Back to this discussion! :) Arista as a viable full-table PE router. Was hoping >> for better experience reports since last mention. >> >> To make the Q bit more general, are there any PE routers yet that can handle 3-8 >> full feeds and use an amp and 1U or so instead of 5 and 4U? Or we're ito whitebox/ >> open routers still for that (bird/openbgp?) or microtiks? > >The 7280 is likely what you???re looking at. Lots of folks also use MikroTik as well if >the traffic is in the 1G range or so. > >I for one use Arista for Layer3 for FTTH purposes as it gives me good software/hardware >support for my features. > >- Jared From joelja at bogus.com Thu Nov 30 19:47:45 2017 From: joelja at bogus.com (joel jaeggli) Date: Thu, 30 Nov 2017 11:47:45 -0800 Subject: Arista Layer3 In-Reply-To: <20171130191750.GB32439@sizone.org> References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> Message-ID: On 11/30/17 11:17, Ken Chase wrote: > Back to this discussion! :) Arista as a viable full-table PE router. Was hoping > for better experience reports since last mention. > > To make the Q bit more general, are there any PE routers yet that can handle 3-8 > full feeds and use an amp and 1U or so instead of 5 and 4U? Or we're ito whitebox/ > open routers still for that (bird/openbgp?) or microtiks? Arista DCS-7280SRA-48C6 is a 1ru box.  Has a nominally million route fib, Jericho+ 8GB of packet buffer. control-plane is 8GB of ram andAMD GX-424CC SOC which is 4 core 2.4ghz. We do direct fib injection with bird rather than the arista bgpd but the control-plane is capable of managing quite a few bgp sessions. the 1/2ru 7280CR2K-30 and 60 are 2m route fib boxes with still heftier control planes but they're a different class of box being all 100G and requiring multi-chip/internal fabrics. > /kc > > On Thu, Nov 30, 2017 at 10:45:09AM -0800, Tyler Conrad said: > >For Enterprise/DC, it works great. For service provider, they're not 100% > >yet. The main issue is going to be around VRFs, as there's no interaction > >between them (at least in the code version I'm on, that may have changed > >recently or be changing soon). They'll work great as a P-Router, but if you > >need a PE with route leaking I'd look at another vendor. > > > >I use a couple pairs of 7280SRs as edge routers/border leaves. Multiple > >full table feeds without any issue. > > > >On Thu, Nov 30, 2017 at 10:36 AM, Romeo Czumbil >> wrote: > > > >> So I've been using Arista as layer2 for quite some time, and I'm pretty > >> happy with them. > >> Kicking the idea around to turn on some Layer3 features but I've been > >> hearing some negative feedback. > >> The people that I did hear negative feedback don't use Arista themselves. > >> (they just heard....) > >> > >> So do we have any Arista L3 people out here that can share some negatives > >> or positives? > >> > >> Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP > >> Maybe 20k routes (no full internet routes) > >> 7050 Series > >> 7280 Series > >> > >> -Romeo > >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: OpenPGP digital signature URL: From rsk at gsp.org Thu Nov 30 20:05:31 2017 From: rsk at gsp.org (Rich Kulawiec) Date: Thu, 30 Nov 2017 15:05:31 -0500 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <871skg9l3z.fsf@miraculix.mork.no> References: <20171129225016.22679.qmail@ary.lan> <871skg9l3z.fsf@miraculix.mork.no> Message-ID: <20171130200531.GA22329@gsp.org> On Thu, Nov 30, 2017 at 10:22:40AM +0100, Bj??rn Mork wrote: > rDNS is not a host attribute, and will therefore tell you exactly > nothing about the host. The lack of rDNS disqualifies a system from being a legitimate mail host. The lack of FCrDNS does the same. (Note that it's usually prudent to tempfail some of these cases in order to allow for the circumstance that something is temporarily wonky with DNS. Well-run mail services that are experiencing transient issues will correct those, DNS will once again be working, and queued mail will eventually make it through.) The content of rDNS provides additional information, and some of it's enormously useful: e.g., blah.dynamic.example.com is not a valid mailhost, and immediate rejection is highly advisable. Same for blah.dsl.example.com and blah.unassigned.example.com and many other patterns. And of course depending on the expected mix of spam/nonspam traffic at a particular mail server, there may be no need to accept any mail traffic from blah.example.TLD for many values of "TLD". [1] I just checked on a particular mail server that I'm working on, and in November 2017, 62% of all messages that were rejected were disposed of thusly because they failed rDNS/DNS-related checks. (Which includes things like the above as well as checking HELO, MX validity, etc.) That means that roughly 2/3 of the messages didn't need to be checked against a DNSBL or anything else, reducing the load on valuable shared resources. rDNS/DNS checks are an efficient, reliable, scalable, first-line MTA defense -- and they're quite robust in the face of attempts to game them. ---rsk [1] Or, alternatively, to only accept it at certain MX's designated for the task -- ones which presumably apply higher scrutiny to such traffic than would otherwise be employed. This works for various geoblocking tactics as well. From job at ntt.net Thu Nov 30 20:07:49 2017 From: job at ntt.net (Job Snijders) Date: Thu, 30 Nov 2017 20:07:49 +0000 Subject: aggregate6 - a fast versatile prefix list compressor Message-ID: <20171130200748.GC42601@vurt.meerval.net> Dear NANOG, I re-implemented the venerable 'aggregate' tool (by Joe Abley & co) in python under the name of 'aggregate6'. The 'aggregate6' tool is faster and also has IPv6 support. https://github.com/job/aggregate6 Installation is can be done through 'pip', or your operating system's package manager (if they carry the 'aggregate6' tool). $ pip install aggregate6 Example use: $ echo 10.0.0.0/16 10.0.0.0/24 2000::/4 3000::/4 | aggregate6 10.0.0.0/16 2000::/3 Note that 'aggregate6' can also be imported as module in your own python project: >>> import from aggregate6 import aggregate >>> aggregate(["10.0.0.0/8", "10.0.0.0/24"]) ['10.0.0.0/8'] >>> Related to the above example, NTT uses 'aggregate6' as library in their network automation toolchain to help compress firewall rules. When using a dump from the IPv4 Default-Free Zone, it appears that 'aggregate6' can deaggregate that list ~ 50 times faster than 'aggregate'. However the tradeoff is that 'aggregate6' uses a bit more memory. Aggregate6 has been tested with pypy, python2 and python3; and can be used both from the command line or as python module. Aggregate6 is published under the 2-Clause BSD license. Kind regards, Job From valdis.kletnieks at vt.edu Thu Nov 30 20:11:49 2017 From: valdis.kletnieks at vt.edu (valdis.kletnieks at vt.edu) Date: Thu, 30 Nov 2017 15:11:49 -0500 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <612F06E8-7FC2-4A83-B95E-28A1E41F6115@delong.com> References: <20171130182801.24688.qmail@ary.lan> <612F06E8-7FC2-4A83-B95E-28A1E41F6115@delong.com> Message-ID: <41007.1512072709@turing-police.cc.vt.edu> On Thu, 30 Nov 2017 11:16:09 -0800, Owen DeLong said: > i.e. rarely to bank robbers sign their names to the robbery note. An amazing number of them use a deposit slip with their name on it for the note. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 486 bytes Desc: not available URL: From job at ntt.net Thu Nov 30 20:27:34 2017 From: job at ntt.net (Job Snijders) Date: Thu, 30 Nov 2017 20:27:34 +0000 Subject: aggregate6 - a fast versatile prefix list compressor In-Reply-To: <20171130200748.GC42601@vurt.meerval.net> References: <20171130200748.GC42601@vurt.meerval.net> Message-ID: <20171130202734.GA95926@vurt.meerval.net> Someone suggested I should clarify what 'aggregate6' actually does :-) aggregate6 takes a list of IPv4 and/or IPv6 prefixes in conventional format, and performs two optimisations to attempt to reduce the length of the prefix list. The first optimisation is to remove any supplied prefixes which are superfluous because they are already included in another supplied prefix. For example, 2001:67c:208c:10::/64 would be removed if 2001:67c:208c::/48 was also supplied. The second optimisation identifies adjacent prefixes that can be combined under a single, shorter-length prefix. For example, 2001:67c:208c::/48 and 2001:67c:208d::/48 can be combined into the single prefix 2001:67c:208c::/47. As an IPv4 exampl: 10.0.0.0/24 and 10.0.1.0/24 can be joined into 10.0.0.0/23. The above two optimalisations are useful in context of firewall rule generation or generation of BGP prefix-list filters. Kind regards, Job From gtaylor at tnetconsulting.net Thu Nov 30 20:32:48 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 30 Nov 2017 13:32:48 -0700 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <20171130183041.24718.qmail@ary.lan> References: <20171130183041.24718.qmail@ary.lan> Message-ID: <3d84c686-aa5f-8180-8a37-be77fef949a8@tnetconsulting.net> On 11/30/2017 11:30 AM, John Levine wrote: > If you look at the bounce handling in packages like sympa and mailman, > they have lots of heuristics to try to figure out what bounces mean. > They work OK but I agree they are far from perfect. I never have. Further, I think I'd like to not go insane. I naively would expect that one would look for the most common bounce format (likely standard DSN), then the next most common, ... rinse, lather, repeat. I'd bet that between three and eight formats in, you would have a VERY LARGE portion of bounces covered. I would also configure MLMs to forward unknown bounces to the -owner. Hopefully the -owner would then feed (a sanitized copy of) the unknown bounce type the MLM maintainer(s) to improve said MLM. > It's a rathole, it doesn't scale, and it is not a bug that you can > send mail to people who you don't already know. I wasn't aware that DKIM-ATPS necessitated needing to know who you were going to send to. I thought DKIM-ATPS was meant to allow a 3rd party that you contract to be an "Authorized Third (party) Sender" of email for your domain. Though, that doesn't do anything for recipients forwarding to their new mailbox. > If identities were a magic bullet, we'd all be signing with S/MIME. I am (and have been for years) a proponent of S/MIME. Though I don't think that it really does anything to help with this paradigm. Unless you are able to filter incoming messages with the intention that all incoming messages MUST be signed and reject (or otherwise filter) unsigned messages. (I think we're still talking about how can an intermediate mail server be authorized to be part of the SMTP end-to-end mail delivery chain. Even if said intermediate mail server is downstream of the sender.) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From kmedcalf at dessus.com Thu Nov 30 20:47:56 2017 From: kmedcalf at dessus.com (Keith Medcalf) Date: Thu, 30 Nov 2017 13:47:56 -0700 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <87po7z7it5.fsf@miraculix.mork.no> Message-ID: On Thursday, 30 November, 2017 10:55, Bjørn Mork , wrote: >Steve Atkins writes: >>> On Nov 30, 2017, at 1:22 AM, Bjørn Mork wrote: >>> "John Levine" writes: >> It tells you something about the competence of the operator and >> whether the host is intended by the owners to send email. >No. It only tells you something about the administrative split >between IP address management and host management. >There is no way my laptop is going to be able to update the rDNS for >all addresses it will use in different networks. This does in no way >affect its MTA configuration. Your Laptop should not be an MTA. Perhaps it is a authenticated submission agent sending to MTA, but without properly configured forward/reverse DNS it is not an MTA. Many systems will not accept SMTP from it unless it can authenticate. >> Or, for a more empirical way to look at it, there's reasonable >> correlation between having missing, generic or incorrect reverse >> DNS and the host being a source of unwanted or malicious email. >Really? Where did you get those numbers? This is a myth. Spam >sources are average Internet hosts. The split between working and non- >working rDNS is mostly between IPv4 and IPv6, not between ham and spam. You are incorrect. If DNS is not configured correctly then the spam to ham ratio is pretty much 100% spam with no ham. >And if there is some correlation there, then I'd say that an IPv4 host is >more likely to be a spam source than a dual stack or IPv6 only host. Actually, you are incorrect again. In order of "Spaminess" (most spammy first) you have the following order: IPv4 with incorrectly configured DNS. IPv6 without regard for DNS configuration. IPv4 with correctly configured DNS. From math at sizone.org Thu Nov 30 21:00:22 2017 From: math at sizone.org (Ken Chase) Date: Thu, 30 Nov 2017 16:00:22 -0500 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> Message-ID: <20171130210022.GF32439@sizone.org> >Arista DCS-7280SRA-48C6 is a 1ru box.?? > >Has a nominally million route fib, Jericho+ 8GB of packet buffer. >control-plane is 8GB of ram andAMD GX-424CC SOC which is 4 core 2.4ghz. >We do direct fib injection with bird rather than the arista bgpd but the >control-plane is capable of managing quite a few bgp sessions. > >the 1/2ru 7280CR2K-30 and 60 are 2m route fib boxes with still heftier >control planes but they're a different class of box being all 100G and >requiring multi-chip/internal fabrics. Sounds pretty good - hows your power draw on that thing? Why'd you pick Bird in this case? /kc >> /kc >> >> On Thu, Nov 30, 2017 at 10:45:09AM -0800, Tyler Conrad said: >> >For Enterprise/DC, it works great. For service provider, they're not 100% >> >yet. The main issue is going to be around VRFs, as there's no interaction >> >between them (at least in the code version I'm on, that may have changed >> >recently or be changing soon). They'll work great as a P-Router, but if you >> >need a PE with route leaking I'd look at another vendor. >> > >> >I use a couple pairs of 7280SRs as edge routers/border leaves. Multiple >> >full table feeds without any issue. >> > >> >On Thu, Nov 30, 2017 at 10:36 AM, Romeo Czumbil > >> wrote: >> > >> >> So I've been using Arista as layer2 for quite some time, and I'm pretty >> >> happy with them. >> >> Kicking the idea around to turn on some Layer3 features but I've been >> >> hearing some negative feedback. >> >> The people that I did hear negative feedback don't use Arista themselves. >> >> (they just heard....) >> >> >> >> So do we have any Arista L3 people out here that can share some negatives >> >> or positives? >> >> >> >> Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP >> >> Maybe 20k routes (no full internet routes) >> >> 7050 Series >> >> 7280 Series >> >> >> >> -Romeo >> >> >> > > From owen at delong.com Thu Nov 30 21:03:27 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 30 Nov 2017 13:03:27 -0800 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <41007.1512072709@turing-police.cc.vt.edu> References: <20171130182801.24688.qmail@ary.lan> <612F06E8-7FC2-4A83-B95E-28A1E41F6115@delong.com> <41007.1512072709@turing-police.cc.vt.edu> Message-ID: > On Nov 30, 2017, at 12:11 , valdis.kletnieks at vt.edu wrote: > > On Thu, 30 Nov 2017 11:16:09 -0800, Owen DeLong said: >> i.e. rarely to bank robbers sign their names to the robbery note. > > An amazing number of them use a deposit slip with their name on it for the note. I’m guessing that the ones that do so only do so once. Owen From gtaylor at tnetconsulting.net Thu Nov 30 21:07:33 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 30 Nov 2017 14:07:33 -0700 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <612F06E8-7FC2-4A83-B95E-28A1E41F6115@delong.com> References: <20171130182801.24688.qmail@ary.lan> <612F06E8-7FC2-4A83-B95E-28A1E41F6115@delong.com> Message-ID: <0c15e77b-6d2b-868c-b402-62062232e89f@tnetconsulting.net> On 11/30/2017 12:16 PM, Owen DeLong wrote: > it’s a rather large PITA for a small site with an admin that needs to count on > most things running on autopilot most of the time in order to survive. I have to disagree with that. I've been running SpamAssassin for > 15 years and have found it to be mostly trouble free. - I have cron jobs update it's files and rely on milters to accept / tag / reject messages. - I spend very little time caring for / feeding SpamAssassin. Probably < 5 minutes a month.) Sure, I occasionally fiddle with things, but that's because I want to, not because I need to. > So, while it might be a higher-quality solution, I’d argue that it’s not completely > “better” in that any autopilotable configuration of it involves a high degree of > false negatives or an unacceptable level of false positives. I've had fairly good luck with autopilot. I also don't see many false negatives. Nor do people report false positives to me. (Granted, I tag at 5 and reject at 15.) > People who want to be malicious are usually less willing to do so if they know that > they will be identified, so actually, it does help. Agreed. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From josh at imaginenetworksllc.com Thu Nov 30 21:24:00 2017 From: josh at imaginenetworksllc.com (Josh Luthman) Date: Thu, 30 Nov 2017 16:24:00 -0500 Subject: WiFi - login page redirection not working In-Reply-To: <997F6AD0-BAE9-45C8-BA55-98AD9E560640@delong.com> References: <997F6AD0-BAE9-45C8-BA55-98AD9E560640@delong.com> Message-ID: non-SSL requests are not the issue. SSL requests are. For example, Google cache's their 301 redirect from http://www.google.com to https://www.google.com which means clients that had access while that browser ps stays active will still attempt https instead of http, regardless of what you actually type. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Nov 30, 2017 at 1:08 PM, Owen DeLong wrote: > > > On Nov 30, 2017, at 08:20 , Josh Luthman > wrote: > > > >> If TLS would somehow allow you to redirect... > > > > No but it would be nice to have a solution that redirects the user > instead > > of "this page can't load" creating confusion. > > A well-known non-SSL (non-HSTS) URL that users could use for this purpose > would > serve the same purpose without producing the security problems mentioned. > > Owen > > > > > > > Josh Luthman > > Office: 937-552-2340 > > Direct: 937-552-2343 > > 1100 Wayne St > > Suite 1337 > > Troy, OH 45373 > > > > On Thu, Nov 30, 2017 at 2:02 AM, Jimmy Hess wrote: > > > >> On Wed, Nov 29, 2017 at 10:34 PM, Ramy Hashish > > >> wrote: > >> > >> > >>> Two points with this problem: 1)Is there a "non client" solution to the > >>> problem of the WiFi login notification not showing up on the clients > >> after > >>> connecting to the WiFi network? > >>> > >> > >> A Captive portal embedding WispR XML data > >> for connections from browsers/OSes that request a test page upon network > >> access. > >> https://stackoverflow.com/questions/3615147/how-to- > >> create-wifi-popup-login-page > >> > >> However if WPA2 authentication is not method used for access, then > network > >> traffic is > >> vulnerable and not secured. > >> > >> AP solutions that are non-standard being a "Non client" solution and > using > >> "Open Wireless" mode SSIDs are likely so deficient in security as to be > >> an unreasonable risk for users to actually connect to. > >> > >> > >>> Second, anything to be done from the AP to show the landing page even > if > >>> the page requested is HTTPs? > >>> > >> > >> If TLS would somehow allow you to redirect or create a HTTPS connection > >> from > >> a domain name that is not yours, then this could obviously be exploited > for > >> attacks..... > >> > >> -- > >> -JH > >> > > From johnl at iecc.com Thu Nov 30 21:48:28 2017 From: johnl at iecc.com (John R. Levine) Date: 30 Nov 2017 16:48:28 -0500 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <612F06E8-7FC2-4A83-B95E-28A1E41F6115@delong.com> References: <20171130182801.24688.qmail@ary.lan> <612F06E8-7FC2-4A83-B95E-28A1E41F6115@delong.com> Message-ID: >> It's a one way correlation. If the rDNS is busted, you can be pretty >> sure you don't want the mail. If the rDNS is OK, you need more clues. > > Pretty sure, but far from certain. > > Even this one-way correlation is rather tenuous. It’s mostly harmless because > everyone knows that mail servers are filtering on this basis and legitimate > senders therefore force themselves into workarounds. Having talked to a lot of people who run large mail systems, it's much simpler than that. If you want people to accept your mail, you better have your DNS under control. If it's not important enough to you to make your DNS work, it's not important enough to me to look at what you might try to send. > Fortunately for everyone’s sake, Bj0rn, while he may not like it, seems to find > a way to send his email via some mechanism that allows me to receive it from > a host that has working rDNS. Yeah, funny about that. > Spamassassin is as good an example as any and while it can be effective if you’ve > got the cycles to keep it constantly updated and fed with new information and…, > it’s a rather large PITA for a small site with an admin that needs to count on > most things running on autopilot most of the time in order to survive. That would be me, a daily cron job to install updates does the trick. It's not perfect but it's good enough. > People who want to be malicious are usually less willing to do so if they know that > they will be identified, so actually, it does help. > > i.e. rarely to bank robbers sign their names to the robbery note. Of course not. What it means is that now they attack the authentication systems. They do so in many ways, from stealing grandma's credentials on botted computers to buying SIMs in bulk to defeat schemes that want to tie a unique phone number to each account. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From bzs at theworld.com Thu Nov 30 22:28:10 2017 From: bzs at theworld.com (bzs at theworld.com) Date: Thu, 30 Nov 2017 17:28:10 -0500 Subject: Incoming SMTP in the year 2017 and absence of DKIM In-Reply-To: <41007.1512072709@turing-police.cc.vt.edu> References: <20171130182801.24688.qmail@ary.lan> <612F06E8-7FC2-4A83-B95E-28A1E41F6115@delong.com> <41007.1512072709@turing-police.cc.vt.edu> Message-ID: <23072.34298.962148.207188@gargle.gargle.HOWL> I'd love to hear, not here particularly, from someone very knowledgeable about the history of postal fraud and abuse. I suspect there are more than a few parallels and we'd find out how much of our efforts amount to reinventing wheels once one peels away the technical abstractions and jargon. Basically authentication for starters. (And if someone is about to explain the difference between paper and electronic mail, per piece cost and all that, please spare us.) -- -Barry Shein Software Tool & Die | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* From nick at foobar.org Thu Nov 30 22:38:53 2017 From: nick at foobar.org (Nick Hilliard) Date: Thu, 30 Nov 2017 22:38:53 +0000 Subject: Arista Layer3 In-Reply-To: References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> Message-ID: <5A20887D.7020105@foobar.org> Jared Mauch wrote: > Lots of folks also use MikroTik as well if the traffic is in the 1G > range or so. mikrotik support for ipv6 is still dodgy: recursive next-hop is not supported in bgp/ipv6: https://forum.mikrotik.com/viewtopic.php?t=123964#p610239 ... and OSPFv3 routes with the local-address flag set are dropped: https://forum.mikrotik.com/viewtopic.php?t=51124#p319794 Between the two of these feature deficits, ipv6 isn't a runner on this platform in a SP environment. Both problems are due to be resolved in routeros v7, but the release date for this is elusive. Also, the bgp stack is single-threaded and the individual core speeds are relatively low, so operating these devices in the ipv4 dfz can be troublesome. Nick From job at instituut.net Thu Nov 30 22:43:34 2017 From: job at instituut.net (Job Snijders) Date: Thu, 30 Nov 2017 22:43:34 +0000 Subject: Arista Layer3 In-Reply-To: <5A20887D.7020105@foobar.org> References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <5A20887D.7020105@foobar.org> Message-ID: <20171130224334.GN95926@vurt.meerval.net> On Thu, Nov 30, 2017 at 10:38:53PM +0000, Nick Hilliard wrote: > Jared Mauch wrote: > > Lots of folks also use MikroTik as well if the traffic is in the 1G > > range or so. > > mikrotik support for ipv6 is still dodgy: recursive next-hop is not > supported in bgp/ipv6: > > https://forum.mikrotik.com/viewtopic.php?t=123964#p610239 > > ... and OSPFv3 routes with the local-address flag set are dropped: > > https://forum.mikrotik.com/viewtopic.php?t=51124#p319794 > > Between the two of these feature deficits, ipv6 isn't a runner on this > platform in a SP environment. Both problems are due to be resolved in > routeros v7, but the release date for this is elusive. > > Also, the bgp stack is single-threaded and the individual core speeds > are relatively low, so operating these devices in the ipv4 dfz can be > troublesome. And still no support for BGP Large Communities! :( http://largebgpcommunities.net/implementations/ Kind regards, Job From nick at foobar.org Thu Nov 30 22:56:53 2017 From: nick at foobar.org (Nick Hilliard) Date: Thu, 30 Nov 2017 22:56:53 +0000 Subject: Arista Layer3 In-Reply-To: <20171130210022.GF32439@sizone.org> References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> Message-ID: <5A208CB5.7040905@foobar.org> Ken Chase wrote: > Sounds pretty good - hows your power draw on that thing? Why'd you pick Bird > in this case? this is a 7280SR pushing ~130G-140G of traffic in/out with about 75% of the ports lit: > Router#show env power > Power Input Output Output > Supply Model Capacity Current Current Power Status > ------- -------------------- --------- -------- -------- -------- ------------- > 1 PWR-500AC-F 500W 0.37A 5.89A 70.6W Ok > 2 PWR-500AC-F 500W 0.39A 6.30A 75.6W Ok > Total -- 1000W -- -- 146.2W -- > Router# Also: > To make the Q bit more general, are there any PE routers yet that can handle 3-8 > full feeds and use an amp and 1U or so instead of 5 and 4U? juniper claims that the mx204 has a typical power draw of ~250W. Nick From joelja at bogus.com Thu Nov 30 23:16:41 2017 From: joelja at bogus.com (joel jaeggli) Date: Thu, 30 Nov 2017 15:16:41 -0800 Subject: Arista Layer3 In-Reply-To: <20171130210022.GF32439@sizone.org> References: <12a241a9d5c24d79983e5db8e0b51cef@hwt01-ex02.tierpoint.net> <20171130191750.GB32439@sizone.org> <20171130210022.GF32439@sizone.org> Message-ID: <0c4a81cd-ad54-b5c8-abb0-adaf10949090@bogus.com> On 11/30/17 13:00, Ken Chase wrote: > >Arista DCS-7280SRA-48C6 is a 1ru box.?? > > > >Has a nominally million route fib, Jericho+ 8GB of packet buffer. > >control-plane is 8GB of ram andAMD GX-424CC SOC which is 4 core 2.4ghz. > >We do direct fib injection with bird rather than the arista bgpd but the > >control-plane is capable of managing quite a few bgp sessions. > > > >the 1/2ru 7280CR2K-30 and 60 are 2m route fib boxes with still heftier > >control planes but they're a different class of box being all 100G and > >requiring multi-chip/internal fabrics. > > Sounds pretty good - hows your power draw on that thing? Why'd you pick Bird > in this case? this a standard sr that's moderately busy but not exactly slammed, I'm be impressed if you could triple that at full tilt. #show environment power Power                                  Input    Output   Output Supply  Model                Capacity  Current  Current  Power    Status ------- -------------------- --------- -------- -------- -------- ------------- 1       PWR-500AC-R               500W    0.35A    5.27A    62.8W Ok 2       PWR-500AC-R               500W    0.32A    4.81A    56.4W Ok Total   --                       1000W       --       --   119.1W -- bird had memory footprint going with it as well as some local modification and we hacked addpath into it a few years ago. filtering poilcy is something we programmatically generate and interact with via agents so a traditional style monolithic config isn't that useful. > /kc > > > >> /kc > >> > >> On Thu, Nov 30, 2017 at 10:45:09AM -0800, Tyler Conrad said: > >> >For Enterprise/DC, it works great. For service provider, they're not 100% > >> >yet. The main issue is going to be around VRFs, as there's no interaction > >> >between them (at least in the code version I'm on, that may have changed > >> >recently or be changing soon). They'll work great as a P-Router, but if you > >> >need a PE with route leaking I'd look at another vendor. > >> > > >> >I use a couple pairs of 7280SRs as edge routers/border leaves. Multiple > >> >full table feeds without any issue. > >> > > >> >On Thu, Nov 30, 2017 at 10:36 AM, Romeo Czumbil >> >> wrote: > >> > > >> >> So I've been using Arista as layer2 for quite some time, and I'm pretty > >> >> happy with them. > >> >> Kicking the idea around to turn on some Layer3 features but I've been > >> >> hearing some negative feedback. > >> >> The people that I did hear negative feedback don't use Arista themselves. > >> >> (they just heard....) > >> >> > >> >> So do we have any Arista L3 people out here that can share some negatives > >> >> or positives? > >> >> > >> >> Use case: Just some MPLS IPv4/IPv6 routing, l2vpn OSPF/BGP > >> >> Maybe 20k routes (no full internet routes) > >> >> 7050 Series > >> >> 7280 Series > >> >> > >> >> -Romeo > >> >> > >> > > > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: OpenPGP digital signature URL: